Re: [libvirt PATCH 2/2] ci: refresh with latest lcitool manifest
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.
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.
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.
Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
This is good to know. Is there a warning or notification that the
pipeline then runs in the context of the project? If not we should
document it at least so that project members are aware not to run
pipelines without thinking about it.
While I'm not a fan of changes to the pipeline running, I'll be able to
live with them once you document them (separately). I welcome the
removal of building containers in the forks.
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>