Closed zappolowski closed 5 months ago
I think it's nice to add some sort of latest version of each distro, along with some older, still supported version. Using the "latest" tag or similar, these will always be up to date.
Using the "latest" tag or similar, these will always be up to date.
The problem with this approach is, that now the actual version used depends on when the image was (re)build. When sticking to real version, one can at least be sure about the release being used (plus some potential minor updates).
This obviously doesn't work for rolling release distributions like Arch Linux ... so, there latest
is the only option.
Using the "latest" tag or similar, these will always be up to date.
The problem with this approach is, that now the actual version used depends on when the image was (re)build. When sticking to real version, one can at least be sure about the release being used (plus some potential minor updates).
This obviously doesn't work for rolling release distributions like Arch Linux ... so, there
latest
is the only option.
If updating the CI image breaks the building of dunst, that's something we need to know about. Since the distro building dunst will have the same issue. So I think we should actually build the CI images more often and track distro's closely
So I think we should actually build the CI images more often and track distro's closely
That's true, but having just latest
here doesn't automatically create new images if not actively built and pushed to the repository. As this (at least currently) is a manual step one can also quickly check available versions of the images being built and adjust the files (in most cases it's enough to adjust the first line).
If on the other hand CI images are built automatically (maybe on a schedule) you could run into sudden pipeline failures both here (when latest points to another version and packages were renamed/removed - this happened for me for the alpine image) or in the main repo (new compiler version available with stricter rules - breaking previously seemingly good code). As maintenance is rather low (no offense) this should be avoided.
Given that the current approach of having CI images built in a separate repository, from my point of view manual creation of the CI images (also check a successful build of the current main branch of the main repository) seems the best approach. If the actual CI is fully contained in the main repository this whole approach is void anyhow.
Is this mergeable, or does this not run either?
I'm fine with the current approach, so if the CI images run, then I'll merge this
Is this mergeable, or does this not run either?
Edit: I've fixed the 2nd issue. Please take a look at the last commit.
Thanks! I've merged it now.
These are just the easy ones ...
Fedora, Alpine, and Archlinux cannot build current master due to
-Werror
and a lot of warnings there - these have to be fixed before the pipeline images can be updated. See #1232 at the main repo and #8 for a PR here to update the mentioned images.