Re: Should we maybe move Cirrus-CI jobs away from Gitlab again?

[Stefan Hajnoczi]

On Tue, 27 Sept 2022 at 11:54, Daniel P. Berrangé <berrange@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 <thuth@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.

Stefan