Joplin Server for arm64 & arm/v7

I built a GitHub action that creates automated builds of Joplin Server in amd64, arm64, & arm/v7.

I have it checking for new tags in the upstream repository every 5 minutes. If a new version is found it will automatically update the tag in my repository and then kickoff another action to build new Joplin Server container images based on the latest tag with the additional chipset architectures. I'm sure official builds will come sooner or later, but until then, you're all welcome to use the container images I'm building.

I run arm64 on my Raspberry Pi and its been working great!

Container images are on: Docker Hub

docker pull etechonomy/joplin-server

I initially learned from what Florider was doing, but I spent a lot of time figuring out the tags so here are the key differences:

Thanks for sharing. Now that Piotr's changes have been merged, couldn't we modify the main build script to also publish for ARM?


Yes, that is totally possible and I would prefer it. You can review my build script here -- joplin-server/build-image.yml at main · etechonomy/joplin-server · GitHub.

I will take a look at yours when I have some time to see if I can contribute.

A difference I have noticed is that whilst @laurent's Docker hub page currently has the 2.4.8-beta image also tagged as latest, @etho201's page tags 2.4.10-beta (the most current beta) as latest.

Good point.. I spent some time figuring out a way to always tag the latest build as "latest" no matter what... It makes sense to me to do it this way (at least for now whilst in beta, but may want to change this once a stable release is available).

This post indicates that at this time 2.4.8-beta is considered to now be the stable release and has therefore been given the latest tag.

Thanks for sharing that. In my opinion, this makes more sense once the -beta tag is ditched. The pipeline I'm running checks for new tags for Joplin Server, and once something new is detected it will build and tag it as latest. Once Joplin Server is out of beta it would make sense to stop doing it this way, but until then, I recommend having a backup/restore plan in the event you upgrade to a latest version that possibly has undesired effects.

I may have got it wrong but the post I quoted suggests to me that the -beta tag is not going to be ditched.

Joplin server has been declared production ready and, as a project, out of beta. I read the post I quoted above as meaning the beta naming will be used to indicate a pre-release like the GitHub tag for the desktop client.

So all docker images would be tagged as x.x.x-beta and then, when happy that a particular pre-release is suitable to be a release version, @laurent will subsequently tag that x.x.x-beta image with latest as well, sort of like changing the client's pre-release/release tag on GitHub.

By the way, thank-you for taking the time to help out people like me who want to use Joplin server on an arm device but do not have the skill to build it themselves.

1 Like

I'm not sure that this is the best solution. This still means that the Joplin Server will have a -beta suffix, even though it is not a beta.

I understand that this approach does not require to build the package, but on the other hand the version number is wrong for releases. Unless the server releases in the code do not include the beta anyway, in which case only the docker image version is wrong.

1 Like

Yes I'm aware of that but I'm doing what makes my life easier. Happy to hear it if someone has another solution which is more correct but also equally simple.

It's running a job. It's not as if one has to copy files and build packages manually.

When a "beta" version is deemed ready for prod, we should update the locales (since they are always behind a bit) and create a new version. But that's just my opinion.

I think the current way is correct - each server release is properly tagged in git and we don't create artificial new releases for latest. Instead it's the release on DocketHub that gets updated from beta to latest.

I guess we could also remove the beta tag too. Maybe I'll do it one day but for now this technique accomplishes the main goal, which is to tell users "this release is stable" in a simple way.