-
Notifications
You must be signed in to change notification settings - Fork 139
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
Conversation
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
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. |
Thank you for the review. 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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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
[test-all] |
With current approach are the tests ran only on stable fedora (the one, on which |
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. |
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. |
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