Re: gitlab-ci: Only build /staging branch?

[Daniel P . Berrangé]

On Thu, Mar 25, 2021 at 12:05:32PM +0100, Paolo Bonzini wrote:
> On 25/03/21 11:34, Peter Maydell wrote:
> > It needs to be faster. Mostly I do check the gitlab CI pipeline
> > status, but in the run-up to getting rc0 out I stopped waiting
> > for the gitlab CI job to finish, because I was continually finding
> > that I kicked off a run, my local build-tests would complete within
> > an hour or so, and the gitlab CI jobs were still pending, barely
> > started, etc. Turnaround on testing a merge must be 90 minutes or
> > less, especially during release periods, because there are always
> > a huge number of merges that arrive for me to test in the last
> > couple of days before freeze.
> 
> Perhaps we could script it so that if the pipeline passes the merge to
> master is done automatically.

No need to script it, that functionality already exists in GitLab.

Push to the staging branch, and open a merge request for applying
staging -> master, and enable "merge when pipeline succeeds".

You can actually do this all in one command

https://docs.gitlab.com/ee/user/project/push_options.html

  git push \
     -o merge_request.create \
     -o merge_request.target=master \
     -o merge_request.merge_when_pipeline_succeeds \
     origin staging


The gitlab-ci.yml file could then be configured so that pipeline
jobs are associated with a merge request, rather than push event.
This will avoid the pipeline being re-run on master after the
merge.

If you enable "merge trains" option in the repo, then you can
even push to multiple branches concurrently, and gitlab will
serialize the CI pipelines from each merge request in turn,
(assuming no conflicts between then).

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|