[go: up one dir, main page]
Skip to content

Allow to skip CI pipelines when creating branches and commits from the API

Problem to solve

  • Our products have yearly releases channel, e.g. v2020, v2021
  • The support period for each release channel overlaps with another release, that is, we're working on v2021 already while maintaining v2020
  • We use git branches to target those release channels, so that stuff in the foo/v2020 gets deployed to v2020 and so on
  • We have a few thousands of projects which make extensive use of GitLab CI pipelines
  • When starting a new release channel we need to create the matching branch on each project (5000+)
  • We use the API to efficiently create the new branch across thousands of projects
  • The release channel branches are protected and no direct pushes are allowed
  • We really don't want to trigger thousands of pipelines at the same time, we really don't need them to be run at that point
  • Unfortunately, while git push has -o ci.skip and the Merge Request API has the ci_skip flag when initiating a rebase, the branch API does not have anything like that.

What we currently do is unprotect the branches, push with ci.skip and protect the branches again, which is not exactly great but works.

Intended users

User experience goal

The goal is to expand the API so that it provides features already available via direct git push usage.

It will also make the feature available in some context (creating new protected branches) where usage of git push is disallowed.

Proposal

Add a skip_ci like the one in the API to rebase merge requests to the branch and commit creation APIs.

I assume that disallowing git push when creating protected branches has been done for good reasons and it would be harder to change that.

Further details

Permissions and Security

In general, ci.skip is already available via the git protocol, so this would not change permissions in any way.

However, at the moment creating a new protected branch can be done only via the GitLab branch API and not via the git protocol, so in this specific case (which is the one we are actually interested in) there is an actual impact since currently when creating a new protected branch there is no way to skip CI.

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Release managers handling many repositories with per-release protected branches that need to be regularly branched without running full CI pipelines every time.

Is this a cross-stage feature?

Links / references

Edited by Emanuele Aina