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 :|
