Re: [libvirt PATCH 2/2] ci: refresh with latest lcitool manifest

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.