Re: [PATCH 6/6] docker: Add Fedora 35 container

[Philippe Mathieu-Daudé]

On 11/3/21 18:51, John Snow wrote:> On Wed, Nov 3, 2021 at 1:01 PM
Daniel P. Berrangé <berrange@redhat.com
> <mailto:berrange@redhat.com>> wrote:
> 
>     On Wed, Nov 03, 2021 at 10:48:44AM -0400, John Snow wrote:
>     > Or, more accurately, update our current Fedora container to Fedora 35,
>     > and then add a new fedora34 container and build test.
>     >
>     > Signed-off-by: John Snow <jsnow@redhat.com <mailto:jsnow@redhat.com>>
>     > ---
>     >  .gitlab-ci.d/buildtest.yml               |  16 ++++
>     >  .gitlab-ci.d/container-core.yml          |   5 +
>     >  tests/docker/dockerfiles/fedora.docker   |   2 +-
>     >  tests/docker/dockerfiles/fedora34.docker | 117
>     +++++++++++++++++++++++
> 
>     We already struggle with having too much work in the CI pipeline
>     and will be in trouble when they start enforcing CI limits.
> 
>     With that in mind I'm not sure that having both Fedora versions
>     brings large enough benefit to justify the CI CPU time burnt.
> 
> 
> Fair. I'd say having stuff like ubuntu21.10 is more important than
> having both f34/f35. I have a keen interest on pushing forward into
> bleeding edge releases to identify potential issues sooner rather than
> later; and can generally trust that the older releases are well traveled
> through developer's personal machines.
>  
> 
>     If we did want both versions though, we should be consistent
>     with file naming - ie fedora35.dockre, not fedora.docker
>     to match fedora34.docker.
> 
> 
> OK. I was originally considering the "unversioned" file to be the "most
> recent one" that would update on a rolling schedule. On IRC you made a
> good point that when we fork a stable branch, we actually don't want
> this behavior. Explicit naming is therefore the best policy.
> 
> I am still somewhat interested in having the F34 image, but we don't
> need it on the CI platform right now. Maybe it could be included later
> on as a target of lesser value to only be run occasionally, but I can
> worry about that a little later.

I agree with Daniel, this is not ideal on mainstream CI.

However you can add it to your fork, see commit 8b185c815ce
("gitlab: Document how forks can use different set of jobs"):

+# To use a different set of jobs than the mainstream QEMU project,
+# you need to set the location of your custom yml file at "custom CI/CD
+# configuration path", on your GitLab CI namespace:
+#
https://docs.gitlab.com/ee/ci/pipelines/settings.html#custom-cicd-configuration-path