add multi arch docker build #5808
Conversation
|
Is publishing on github actions wantend? |
|
https://github.com/b-reich/FreshRSS/actions/runs/6733089164/job/18301035008 looks like the build itself works |
|
Thanks, that looks pretty good already 👍🏻 |
|
For reference, the current Docker Hub build configuration:
|
in the end we should only have something like latest and latest-alpine i think. No need to tag the arm images separately. This is kinda a breaking change than. |
|
Maybe the Dockerfile Labels should also be adapted for this. The FreshRSS/Docker/Dockerfile-Alpine Lines 23 to 33 in 8b2f784 |
The generated one from the metadata action are not used at the moment. this could be change @Alkarex what do you think? |
Indeed. I think it would be an acceptable breaking change.
Providing a Debian and an Alpine version is quite common. There are pros and cons with both (for instance build speed for Alpine, among other things), and having an alternative can be helpful (e.g. #5742 ) I will come back for the other questions |
|
https://github.com/b-reich/FreshRSS/actions/runs/6738089530/job/18316933656 the github action is nearly finish I think.... |
Co-authored-by: EdJoPaTo <rfc-conform-git-commit-email@funny-long-domain-label-everyone-hates-as-it-is-too-long.edjopato.de> Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
Yes, it would probably be better to use the ones from the Action, indeed |
Docker/Dockerfile
Outdated
| LABEL \ | ||
| org.opencontainers.image.authors="Alkarex" \ | ||
| org.opencontainers.image.description="A self-hosted RSS feed aggregator" \ | ||
| org.opencontainers.image.documentation="https://freshrss.github.io/FreshRSS/" \ | ||
| org.opencontainers.image.licenses="AGPL-3.0" \ | ||
| org.opencontainers.image.revision="${SOURCE_BRANCH}.${SOURCE_COMMIT}" \ | ||
| org.opencontainers.image.source="https://github.com/FreshRSS/FreshRSS" \ | ||
| org.opencontainers.image.title="FreshRSS" \ | ||
| org.opencontainers.image.url="https://freshrss.org/" \ | ||
| org.opencontainers.image.vendor="FreshRSS" \ | ||
| org.opencontainers.image.version="$FRESHRSS_VERSION" |
There was a problem hiding this comment.
I would prefer to keep the static ones here, so that they exist when the builds are done locally, e.g. like
FreshRSS/Docker/freshrss/docker-compose.yml
Lines 12 to 15 in 8b2f784
authors can be removed
By the way, if anyone knows a way to populate revision and/or version even in those more manual scenarios, let me know
There was a problem hiding this comment.
not sure what happen when you use the github action ones and the static ones.
There was a problem hiding this comment.
Let's try to remove the static ones from GitHub Actions, so that we can see whether that is sufficient or whether they need to be overridden again
There was a problem hiding this comment.
I found some docu about.
passing labels at build time will overwrite the static ones
.github/workflows/build-images.yml
Outdated
| # username: ${{ secrets.DOCKERHUB_USERNAME }} | ||
| # password: ${{ secrets.DOCKERHUB_TOKEN }} | ||
|
|
||
| # - name: Login to GitHub Container Registry |
There was a problem hiding this comment.
Any comments about how pros and cons of (also) using the GitHub Container Registry?
Probably seems overkill for now?
There was a problem hiding this comment.
For podman user?
And Dockerhub had in the pass some weird decisions I think.
Personaly I prefer the github registry
There was a problem hiding this comment.
Ok. Let's keep it but comment out for now, so we can easily activate if needed.
I am not familiar with the use-case: Can't Podman users pull from Docker Hub?
There was a problem hiding this comment.
It can, but the default registry (dockerhub) is not set.
There was a problem hiding this comment.
Newer podman versions try dockerhub on unspecified image tags. Personally I don't think it matters much as its the same image
|
@Alkarex you need to checkout the repo when you try to retrive the version |
Thanks. Right, I had read a bit too fast that comment #5808 (comment) As you can see, I am experimenting with an arg-based approach for labels. What do you think? |
|
Hum, I was hopping that |
|
The output looks good to me now, although I would have liked to simplify a bit more if we could avoid |
|
Out of curiousity: why would you like to avoid using metadata-action? it seems helpful to me for generating the v1, v1.2, v1.2.3 tags and so on. Maybe I overlook something? |
| tags: ${{ matrix.tags }} | ||
| labels: | | ||
| org.opencontainers.image.revision=${{ github.ref_name }}.${{ github.sha }} | ||
| org.opencontainers.image.version=${{ env.FRESHRSS_VERSION }} |
There was a problem hiding this comment.
this is already handle by the org.opencontainers.image.revision label which is the commit hash
dont know if there is benefit to know which branch is build from, when you have the commit
also thinks the container version label is fine with sometthing like 1.22.2 or 1.22.2-alpineits specify the container version not the version of the application itself
There was a problem hiding this comment.
if there is benefit to know which branch is build from
This is mostly because this is what we already have, and I find it a bit easier to read with something like 1.22.1.cc2878aed855463efe36cf6fb96d001dbb75612e. But I would not be much against leaving it to only the git SHA, if this is what is most standard.
Edit: indeed, according to https://specs.opencontainers.org/image-spec/annotations/#pre-defined-annotation-keys : org.opencontainers.image.revision Source control revision identifier for the packaged software.
I will edit accordingly
also thinks the container version label is fine with sometthing like 1.22.2 or 1.22.2-alpineits specify the container version not the version of the application itself
I would also be happy with 1.22.2-alpine, but that does not work for e.g. edge builds
There was a problem hiding this comment.
Switched back to default revision 3d110b8
|
Not sure why you would avoid using the metadata action? |
Although it does not matter much, it would be mostly to remain as simple as possible, as we do not know how things will evolve in the future. For instance, we have been through periods during which the auto-build in Docker Hub was not available while waiting for a (initially long) Sponsored OSS process. During that period, I built and pushed images manually. The more tags there are, the more difficult it is to move to another build system, and the more work there is for the maintenance. Another use-case: if we were to move back to building on Docker Hubs, there is poor support for multiple tags, which each take a new build, so I would not like to have 1, 1.22, 1.22.1 but only 1.22.1. Especially not when combined with multiple architectures and Debian + Alpine. It just becomes too many tags. Furthermore, FreshRSS is not a library. And we do not have the resources to maintain several branches anyway. So the semver semantics only marginally applies to it. For instance, fixes in 1.22.1 may very well be in 1.23.0. So I am not sure why anyone would chose to track 1.22 instead of 1.22.1 or latest. And by offering semver tags, it might mislead some users into believing that we do have updates on old branches, which we do not.
Yes, and that is why I would probably like to err on the side of simplicity instead of having rarely-used features, which might end up having some drawbacks (see my explanation higher up). As soon as we introduce something, I take on me to actually make a good effort to maintain it over time, so I need to balance what we add with its actual value. |
When I moved away from auto build on Docker Hub it supported multiple tags like 1, 1.2, 1.2.3, … But that is some time ago. I explicitly searched for a way to replicate that behavior on GitHub Actions so I know and understand the pain points you are speaking of. Thanks for clarifying :)
Personally I use the main version tag for my containers. I get all the new features and bugfixed without worrying about breaking changes (new major release). Chosing a minor release would be to manually update but get bugfix only releases which don't change much and update the rest manually (like you suggested pinning a git hash on a used action. Just to give an idea here: Maybe only support major and bugfix version (1 and 1.2.3). Minor releases and bugfix releases would be kinda the same. When someone wants to pin them they can. If they only care for breaking changes they can use the major version tag. This reduces the amount of tags while still allowing for non-breaking tags like I mainly use. |
Might be enabled later if desired
Ok, let's go for that |
|
Let's give it a spin 🚀 Seems to work fine for most of it:
There are only a few things that need to be ironed out: |
Follow up of FreshRSS#5808
|
@b-reich and @EdJoPaTo : please add a line for you in https://github.com/FreshRSS/FreshRSS/blob/edge/CREDITS.md |
|
Everything seems fine now, including the push to the Docker Hub description https://hub.docker.com/r/freshrss/freshrss/ Ideas for future improvement:
|
Closes #4089
Changes proposed in this pull request:
How to test the feature manually:
Pull request checklist:
Additional information can be found in the documentation.