Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 2 commits into from
Sep 12, 2023

Conversation

zmiklank
Copy link
Contributor

@zmiklank zmiklank commented Sep 5, 2023

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: sclorg/container-common-scripts#351
Fixes: #279

@zmiklank zmiklank added the ready for review The pull request is ready to review label Sep 5, 2023
@frenzymadness
Copy link
Member

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
Copy link
Contributor Author

zmiklank commented Sep 6, 2023

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
Copy link
Member

phracek commented Sep 7, 2023

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.

Copy link
Member

@phracek phracek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@frenzymadness
Copy link
Member

All right then. Manual approach it will be.

This commit brings support for 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 compatibilty also the Fedora target stays in form of
symlink to stable Fedora Dockerfile - currently f38
@zmiklank
Copy link
Contributor Author

[test-all]

@zmiklank
Copy link
Contributor Author

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
Copy link
Member

phracek commented Sep 12, 2023

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 zmiklank merged commit 9af4943 into sclorg:master Sep 12, 2023
@zmiklank
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for review The pull request is ready to review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build s2i-base and s2i-core containers for more Fedora versions
3 participants