On Tue, Sep 27, 2022 at 01:36:20PM -0400, Stefan Hajnoczi wrote: > On Tue, 27 Sept 2022 at 11:54, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Tue, Sep 27, 2022 at 11:44:45AM -0400, Stefan Hajnoczi wrote: > > > On Tue, 27 Sept 2022 at 05:02, Thomas Huth <th...@redhat.com> wrote: > > > > now that Gitlab is giving us pressure on the amount of free CI minutes, > > > > I > > > > wonder whether we should maybe move the Cirrus-CI jobs out of the > > > > gitlab-CI > > > > dashboard again? We could add the jobs to our .cirrus-ci.yml file > > > > instead, > > > > like we did it in former times... > > > > > > > > Big advantage would be of course that the time for those jobs would not > > > > count in the Gitlab-CI minutes anymore. Disadvantage is of course that > > > > they > > > > do not show up in the gitlab-CI dashboard anymore, so there is no more > > > > e-mail notification about failed jobs, and you have to push to github, > > > > too, > > > > and finally check the results manually on cirrus-ci.com ... > > > > > > My understanding is that .gitlab-ci.d/cirrus.yml uses a GitLab CI job > > > to run the cirrus-run container image that forwards jobs to Cirrus-CI. > > > So GitLab CI resources are consumed waiting for Cirrus-CI to finish. > > > > > > This shouldn't affect gitlab.com/qemu-project where there are private > > > runners that do not consume GitLab CI minutes. > > > > > > Individual developers are affected though because they most likely > > > rely on the GitLab shared runner minutes quota. > > > > NB, none of the jobs should ever be run automatically anymore in > > QEMU CI pipelines. It always requires the maintainer to set the > > env var when pushing to git, to explicitly create a pipeline. > > You can then selectively start each individual job as desired. > > Cirrus CI is not automatically started when pushing to a personal > GitLab repo? If starting it requires manual action anyway then I think > nothing needs to be changed here.
No pipeline at all is created unless you do git push -o ci.variable=QEMU_CI=1 <your-fork-remote> that creates the pipeliune but doesn't run any jobs - they're manual start. Or QEMU_CI=2 creates & starts the jobs (like the old way we had CI until a few months ago, which burns CI quota hugely). 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 :|