From: Thomas Huth <thuth@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: Should we maybe move Cirrus-CI jobs away from Gitlab again?
Date: Tue, 27 Sep 2022 20:40:44 +0200 [thread overview]
Message-ID: <dc108d7d-297b-5a84-68dd-12da3a0e68d0@redhat.com> (raw)
In-Reply-To: <YzM5i5QP7NQq4OHV@redhat.com>
On 27/09/2022 19.57, Daniel P. Berrangé wrote:
> On Tue, Sep 27, 2022 at 01:36:20PM -0400, Stefan Hajnoczi wrote:
>> 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.
>
> 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.
Yes, sure, the jobs are not started automatically. But I *do* want to run
the jobs before sending pull requests - but since the gitlab-CI minutes are
now very limited, I'd like to avoid burning these minutes via gitlab and
start those jobs directly on cirrus-ci.com again. For that the jobs would
need to be moved to our .cirrus-ci.yml file again.
Well, maybe we could also have both, jobs via cirrus-run for those who want
to see them in their gitlab-CI dashboard, and via .cirrus-ci.yml for those
who want to avoid burning CI minutes on Gitlab. It's a little bit of
double-maintenance, but maybe acceptable?
Thomas
next prev parent reply other threads:[~2022-09-27 18:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 8:22 Should we maybe move Cirrus-CI jobs away from Gitlab again? Thomas Huth
2022-09-27 15:44 ` Stefan Hajnoczi
2022-09-27 15:54 ` Daniel P. Berrangé
2022-09-27 17:36 ` Stefan Hajnoczi
2022-09-27 17:57 ` Daniel P. Berrangé
2022-09-27 18:40 ` Thomas Huth [this message]
2022-09-27 18:47 ` Stefan Hajnoczi
2022-09-27 19:04 ` Thomas Huth
2022-09-27 19:10 ` Stefan Hajnoczi
2022-09-28 6:32 ` Thomas Huth
2022-09-28 7:10 ` Daniel P. Berrangé
2022-09-28 7:24 ` Daniel P. Berrangé
2022-09-28 12:27 ` Alex Bennée
2022-09-28 12:56 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc108d7d-297b-5a84-68dd-12da3a0e68d0@redhat.com \
--to=thuth@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=f4bug@amsat.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).