From: Cleber Rosa <crosa@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Fam Zheng" <fam@euphon.net>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
"Erik Skultety" <eskultet@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
qemu-devel <qemu-devel@nongnu.org>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Andrea Bolognani" <abologna@redhat.com>,
"Willian Rampazzo" <willianr@redhat.com>,
"Willian Rampazzo" <wrampazz@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v6 4/4] Jobs based on custom runners: add job definitions for QEMU's machines
Date: Tue, 29 Jun 2021 21:02:59 -0400 [thread overview]
Message-ID: <CA+bd_6KU=mCPKsNsESaUGCk8c2Jn_t6O=UBcGbE4EPF2UGuw2A@mail.gmail.com> (raw)
In-Reply-To: <971d069b-9ba1-073d-34aa-15beb1d1a751@redhat.com>
On Thu, Jun 10, 2021 at 2:18 AM Thomas Huth <thuth@redhat.com> wrote:
>
> On 08/06/2021 05.14, Cleber Rosa wrote:
> > The QEMU project has two machines (aarch64 and s390x) that can be used
> > for jobs that do build and run tests. This introduces those jobs,
> > which are a mapping of custom scripts used for the same purpose.
> >
> > Signed-off-by: Cleber Rosa <crosa@redhat.com>
> > ---
> > .gitlab-ci.d/custom-runners.yml | 208 ++++++++++++++++++++++++++++++++
> > 1 file changed, 208 insertions(+)
> >
> > diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml
> > index a07b27384c..061d3cdfed 100644
> > --- a/.gitlab-ci.d/custom-runners.yml
> > +++ b/.gitlab-ci.d/custom-runners.yml
> > @@ -12,3 +12,211 @@
> > # guarantees a fresh repository on each job run.
> > variables:
> > GIT_STRATEGY: clone
> > +
> > +# All ubuntu-18.04 jobs should run successfully in an environment
> > +# setup by the scripts/ci/setup/build-environment.yml task
> > +# "Install basic packages to build QEMU on Ubuntu 18.04/20.04"
> > +ubuntu-18.04-s390x-all-linux-static:
> > + allow_failure: true
> > + needs: []
> > + stage: build
> > + tags:
> > + - ubuntu_18.04
> > + - s390x
> > + rules:
> > + - if: '$CI_COMMIT_BRANCH =~ /^staging/'
>
> I don't think this will work very well... sub-maintainers might want to push
> to a "staging" branch in their forked repositories, and without the s390x
> runner, the pipeline gets stuck now:
>
> https://gitlab.com/thuth/qemu/-/pipelines/317812558
>
Hi Thomas,
As I put it in another response, I saw that actually as a feature, in
the sense that:
* people should indeed be allowed to push to their repos and leverage
their hardware, and
* "staging" is a pretty well scoped word, and has a reasonably well
defined meaning
* one would want to mimic as closely as possible what will be done
before a PR is merged
I agree that having the jobs stuck in any situation is not ideal, but
I honestly find that it would be reasonably hard to accidentally hit
that situation. I also believe it will end up being inevitable for
entities to do a meta-analysis of the GitLab CI pipeline results,
possibly disregarding jobs that they can not run, or simply do not
care about, in their forks.
> We had the same issue in the kvm-unit-test CI, and we solved it there by
> rather making it depend on an environment variable that has to be set if the
> runner is available:
>
> only:
> variables:
> - $S390X_RUNNER_AVAILABLE
>
> I think that's also nicer in case someone brings their own s390x runner and
> want to use the CI tests on other branches than staging.
>
The problem with this approach, is that it would not be enough to
protect the jobs based on variables for the architecture, as the OS
type and version also play a part in the possibility of running jobs.
For instance, suppose we get s390x machines from LinuxOne running
RHEL. We'd need variables such as, say,
S390X_RHEL_8_4_RUNNER_AVAILABLE and S390X_RHEL_7_6_RUNNER_AVAILABLE.
> Could you please change your patch accordingly?
>
If you strongly believe now is the time to attempt to handle that
problem, I can go ahead and change it. I stand behind my original
position that we should start with a simpler, "by convention" approach
and address the more complex scenarios as/if they come up.
> Thanks,
> Thomas
>
Thank you!
- Cleber.
prev parent reply other threads:[~2021-06-30 1:04 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 3:14 [PATCH v6 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI) Cleber Rosa
2021-06-08 3:14 ` [PATCH v6 1/4] Jobs based on custom runners: documentation and configuration placeholder Cleber Rosa
2021-06-08 18:29 ` Wainer dos Santos Moschetta
2021-06-09 13:24 ` Alex Bennée
2021-06-09 14:22 ` Thomas Huth
2021-06-09 14:24 ` Willian Rampazzo
2021-06-08 3:14 ` [PATCH v6 2/4] Jobs based on custom runners: build environment docs and playbook Cleber Rosa
2021-06-08 18:48 ` Wainer dos Santos Moschetta
2021-06-09 16:13 ` Willian Rampazzo
2021-06-29 15:23 ` Cleber Rosa
2021-06-29 15:06 ` Cleber Rosa
2021-06-09 13:31 ` Alex Bennée
2021-06-09 14:21 ` Cleber Rosa Junior
2021-06-09 15:26 ` Alex Bennée
2021-06-09 17:09 ` Cleber Rosa Junior
2021-06-11 10:40 ` Alex Bennée
2021-06-28 23:07 ` Cleber Rosa
2021-06-09 17:16 ` Willian Rampazzo
2021-06-10 8:13 ` Erik Skultety
2021-06-29 23:35 ` Cleber Rosa
2021-06-29 23:30 ` Cleber Rosa
2021-06-08 3:14 ` [PATCH v6 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook Cleber Rosa
2021-06-08 19:04 ` Wainer dos Santos Moschetta
2021-06-29 23:51 ` Cleber Rosa
2021-06-09 17:46 ` Willian Rampazzo
2021-06-30 0:04 ` Cleber Rosa
2021-06-10 6:23 ` Thomas Huth
2021-06-30 0:18 ` Cleber Rosa
2021-06-08 3:14 ` [PATCH v6 4/4] Jobs based on custom runners: add job definitions for QEMU's machines Cleber Rosa
2021-06-08 6:29 ` Philippe Mathieu-Daudé
2021-06-08 13:36 ` Cleber Rosa Junior
2021-06-08 19:07 ` Wainer dos Santos Moschetta
2021-06-09 15:09 ` Stefan Hajnoczi
2021-06-30 0:47 ` Cleber Rosa
2021-06-09 14:54 ` Stefan Hajnoczi
2021-06-30 0:40 ` Cleber Rosa
2021-06-11 11:00 ` Alex Bennée
2021-06-30 1:08 ` Cleber Rosa
2021-06-30 14:24 ` Willian Rampazzo
2021-06-09 14:22 ` Stefan Hajnoczi
2021-06-08 18:27 ` Wainer dos Santos Moschetta
2021-06-09 15:53 ` Alex Bennée
2021-06-30 0:30 ` Cleber Rosa
2021-06-09 18:56 ` Willian Rampazzo
2021-06-10 6:18 ` Thomas Huth
2021-06-30 1:02 ` Cleber Rosa [this message]
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='CA+bd_6KU=mCPKsNsESaUGCk8c2Jn_t6O=UBcGbE4EPF2UGuw2A@mail.gmail.com' \
--to=crosa@redhat.com \
--cc=abologna@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=bleal@redhat.com \
--cc=ehabkost@redhat.com \
--cc=eskultet@redhat.com \
--cc=f4bug@amsat.org \
--cc=fam@euphon.net \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
--cc=willianr@redhat.com \
--cc=wrampazz@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).