On Thu, Oct 06, 2022 at 10:52:03AM +0200, Peter Krempa wrote:
On Thu, Oct 06, 2022 at 09:20:08 +0100, Daniel P. Berrangé wrote:
On Thu, Oct 06, 2022 at 09:42:26AM +0200, Peter Krempa wrote:
On Tue, Oct 04, 2022 at 08:51:50 -0400, Daniel P. Berrangé wrote:
This refresh switches the CI for contributors to be triggered by merge requests. Pushing to a branch in a fork will no longer run CI pipelines, in order to avoid consuming CI minutes. To regain the original behaviour contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This should be also documented in ci/README.rst as this commit message will become gradually harder to find.
It is present in comments at the top of ci/gitlab.yml, along with info about some other variables that exist.
Ah, okay. So in that case, ci/README.rst should point out that the yml file has further docs, so that the users don't have to look too deep.
I welcome if pipelines are run automatically and I don't have to fiddle with the web UI or try to figure out which custom approach the project picked to run pipelines especially if I can't be bothered to set up the test env locally e.g. for a one-off contribution.
Users were always able to opt-out of running pipelines if they wish to just store code in their fork by using '-o ci.skip=true' which is a gitlab option thus same for all projects.
That was fine (for users, but not GitLab's $$$ burn) when CI was unlimited, but we need to be more respectful of users CI quota now it is finite and very easy to quickly exhaust.
This variable can also be set globally on the repository, though this is not recommended.
Also mention how to do this for anyone interested to preserve the old behaviour by default.
As above, I really recommend against doing this, unles you want to burn through your CI minutes quickly and find you can't run anymore for the rest of the month. If you really really really want to take this risk, then it is just Settings -> CI -> Variables in the repo in question
Well, I only ever really push to my fork to run CI, so I definitely want to preserve the old behaviour. Thus if I run out of CI minutes I'll happen regardless of how that's set up. If that ends up to be a problem I'll most likely have to setup private runners.
BTW, a neat trick for git push options shown in: https://docs.gitlab.com/ee/user/project/push_options.html is to set up git command aliases git config --local alias.push-ci "push -o ci.variable=RUN_PIPELINE=1" git config --local alias.push-mr "push -o merge_request.create=1 -o merge_request.target=master -o merge_request.remove_source_branch=1" So eg git push-mr <remote> wil open a merge request with the branch contents. The caveat is that it will pick the title + description from the first commit which is not too useful. What I'd like is an alias that can popup an $EDITOR to enter the title and description, and then pass those as push options - so you get a workflow kinda like 'git-publish' gives you (but without ability to annotate individual patches). With 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 :|