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

[Daniel P. Berrangé]

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