[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 14/15] gitlab-ci: Allow forks to use different set of job

From: Thomas Huth
Subject: Re: [RFC PATCH 14/15] gitlab-ci: Allow forks to use different set of jobs
Date: Mon, 19 Apr 2021 12:59:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0

On 19/04/2021 12.51, Daniel P. Berrangé wrote:
On Mon, Apr 19, 2021 at 12:48:25PM +0200, Thomas Huth wrote:
On 19/04/2021 12.36, Daniel P. Berrangé wrote:
On Mon, Apr 19, 2021 at 12:20:55PM +0200, Thomas Huth wrote:
On 19/04/2021 12.10, Erik Skultety wrote:
On Mon, Apr 19, 2021 at 10:40:53AM +0100, Daniel P. Berrangé wrote:
On Mon, Apr 19, 2021 at 01:34:47AM +0200, Philippe Mathieu-Daudé wrote:
Forks run the same jobs than mainstream, which might be overkill.
Allow them to easily rebase their custom set, while keeping using
the mainstream templates, and ability to pick specific jobs from
the mainstream set.

To switch to your set, simply add your .gitlab-ci.yml as
is your gitlab 'namespace', usually username). This file will be
used instead of the default mainstream set.

I find this approach undesirable, because AFAICT, it means you have
to commit this extra file to any of your downstream branches that
you want this to be used for.  Then you have to be either delete it
again before sending patches upstream, or tell git-publish to
exclude the commit that adds this.

IMHO any per-contributor overhead needs to not involve committing
stuff to their git branches, that isn't intended to go upstream.

Not just that, ideally, they should also run all the upstream workloads before
submitting a PR or posting patches because they'd have to respin because of a
potential failure in upstream pipelines anyway.

It's pretty clear that you want to run the full QEMU CI before submitting
patches to the QEMU project, but I think we are rather talking about forks
here that are meant not meant for immediately contributing to upstream
again, like RHEL where we only build the KVM-related targets and certainly
do not want to test other things like CPUs that are not capable of KVM, or a
branch where Philippe only wants to check his MIPS-related work during
For contributing patches to upstream, you certainly have to run the full CI,
but for other things, it's sometimes really useful to cut down the CI
machinery (I'm also doing this in my development branches manually some
times to speed up the CI), so I think this series make sense, indeed.

For a downstream like RHEL, I'd just expect them to replace the main
.gitlab-ci.yml entirely to suit their downstream needs.

But that still means that we should clean up the main .gitlab-ci.yml file
anyway, like it is done in this series, to avoid that you always get
conflicts in this big file with your downstream-only modifications. So at
least up to patch 11 or 12, I think this is a very valuable work that
Philippe is doing here.

I don't see a real issue with downstream conflicts. They'll just
periodically pick a release to base themselves off and change once
every 6 months or more.

It's not only downstream distros that rebase every 6 month. Like Philippe, I'm sometimes hacking my .gitlab-ci.yml of my development branch to speed up the CI during my development cycles (i.e. I'm removing the jobs that I do not need). And I'm regularly rebasing my development branchs. Conflicts in .gitlab-ci.yml are then always painful, so a leaner main .gitlab-ci.yml file would be helpful for me, too, indeed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]