sclorg / s2i-base-container

OpenShift base images
Apache License 2.0
86 stars 141 forks source link

enable builds of core and base images for 2 Fedora releases #280

Closed zmiklank closed 1 year ago

zmiklank commented 1 year ago

Currently supported are f38 and f39, later f38 will be migrated to f40. This change enables us to test on bleeding edge Fedora and sustain the stable one for standard container images at the same time.

For backwards compatibility also the Fedora target stays in form of symlink to stable Fedora Dockerfile - currently f38

Depends on: https://github.com/sclorg/container-common-scripts/pull/351 Fixes: https://github.com/sclorg/s2i-base-container/issues/279

frenzymadness commented 1 year ago

I have nothing against this manual approach. I think it's not that hard to copy a file and make one or two simple changes for every new Fedora release.

I can also imagine an automatic approach. We can have Fedora Dockerfile as a template where the version is a placeholder. Then we can have a list of supported releases in GH actions config and a simple sed replacing the placeholder with particular Fedora version before the build starts. Something like:

sed "s/FEDORA_VERSION/38/g" Dockerfile.fedora > Dockerfile.f38
podman build …

But that would work only for GH actions here and I have no idea how many consumers of this repo use the docker files directly.

zmiklank commented 1 year ago

Thank you for the review. When I started implementing this feature I chose the automatic approach as well, but while proceeding with the job I came into the conclusion that it is more important (to me) to not make changes used only in s2i-base repo to the tooling in container-common-scripts which is used in all other repos.

I did not look into the option to change only the github action - seems like it could be sufficient for this usecase. I will look into this later.

phracek commented 1 year ago

I would prefer to manual approach is good. We will change this version once per half a year. I have no problem with review it.

frenzymadness commented 1 year ago

All right then. Manual approach it will be.

zmiklank commented 1 year ago

[test-all]

zmiklank commented 1 year ago

With current approach are the tests ran only on stable fedora (the one, on which Dockerfile.fedora symlink points). Is it sufficient? In my opinion yes, the core and base tests are quite minimal anyway. On the other hand it could be beneficial to at least build both images before merging to master. WDYT?

phracek commented 1 year ago

It is a Fedora image. The older versions are tested before moving to the newest or newer Fedora version and therefore I guess , the images are tested properly.

zmiklank commented 1 year ago

There is one more issue about this PR that did not occur to me before - and that is the 'latest' tag. The design as its proposed tags the last one build image with 'latest' tag -> so it can be f38 and f39 - it is non-deterministic.

I think we do not want this. Question is - which one of those two fedoras should obtain the latest tag? It would make sense to me if it is the last stable one - currently it is f38.