Locking down gitlab branch creation

This is a proposal to lock down new branch creation in the ASOS repos by using a * regex for proteced branches and force everyone to fork the repo and send merge requests.

We could then only have the following branches in each git repo:

  • asos-develop or something more suitable: the ongoing development branch used in unpinned manifests
  • releases/v*.x: stable release branches used in pinned release manifests

Things to clarify:

  • I believe that CI can run on forks, so this shouldn’t impact developer workflow, but it would be good to clarify.
  • Does gitlab provides a single place to enforce these settings for all new git trees? Otherwise, this will need to be be added to a checklist somewhere.

Currently, I see lots of stray branches. e.g. this is in meta-ohos:

  m/develop -> ohos/develop

This is in meta-zephyr:

  m/develop -> ohos/ostc/master

Re meta-zephyr.

This is not stale of course, but our fork of upstream master + our patches:

These come from automatic upstream sync. Ideally we want to get upstream master but gitlab pulls all branches. I’ll try if this can be avoided by mirroring restrictions to protected branches only.

These can be safely removed, so I’ll do it in a second.

This one is Stefan’s, so I don’t touch it for now and will let him decide.

Only if the fork is coming from a project maintainer. I’m using this workflow in SysOTA but it has its drawbacks. CI does run on forks in general, as forks are just repositories, but based on specific CI settings (there are too many for me to comfortably understand) some things only happen if the fork comes from a maintainer.

I don’t know any. I believe this is something we will need to garden or script.

On closer look, any global setting would just be meaningless. We would be unable to push to a fork as that would be equally prevented.

Well, if we could do it for, say, OSTC group, that wouldn’t affect personal forks.

1 Like

I like this. If we’re able to sort out CI, then I’m all for it.

No issue with that if we manage to make the CI working as expected.

Apparently it works. Our meta-zephyr contains only mirror of upstream master, ostc/master with out patches and one @Stefan_Schmidt’s working branch. The rest has been removed and is not coming back.

Right, the global setting would work only if it could apply to the OSTC namespace. Per-user namespace could be the wild wild west.

Thanks for cleaning up!

Most other git trees have extra branches too, so I was hoping that by somehow enforcing this project-wide (e.g. branch names), the developer experience will get more predictable.

1 Like

I removed the branch.

Maybe make it releases (plural). For the regex we could also set it to enforce the semver naming scheme.

Personally I see not much benefit of having a asos namespace in front of the develop. I would be happy with just develop and let the context of a repo handle the rest. It would also avoid any problems in case of re-branding. Not a strong opinion, but my personal take on it.

I’d proposed devel earlier, but @agherzan had made a good point about potential conflicts with upstream branches with the same name.

I agree that removing asos would avoid branding issues, I’m not married to the actual name of the develop branch as long as its purpose is obvious.

Updated in the original proposal.

The dev/feature branches we accumulated should be checked and killed with fire. We moved to fork-based contributions so that should be a fixed problem.

For forks, I usually recommend having a full mirror (that is updated via CI for example) and a namespaced set of branches with chances specific to the fork:


  • foo
  • bar


  • foo (mirror upstream foo)
  • bar (mirror upstream bar)
  • x/foo (fork of upstream foo)

This avoids name clash while being able to update upstream branches.

For local components, I think we can define a simple structure: main, dev. I don’t mind the releases namespace but I don’t think we need to overcomplicate things with additional brand namespaces when we are talking about internal components (like manifest repo, sysota etc). Brand/unique namespaces are useful when dealing with forks.