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

[Peter Krempa]

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.