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!
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).
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.
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.
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.
Hi! I'm trying to install Joplin Server on my Helios4 board. There are no official ARMv7 (32bits) docker images that I know of, but your unofficial automated build seems to be the most popular option (congrats!)
However the docker-compose file mentions Postgres 13.3, dating back to 2021. Is the dockerhub link still current? Have you tried with more recent version of Postgres? Thanks!
I have just spun up a VM and a new Joplin Server worked fine with Postgres 15.2. From what I found (and what I have read on this forum) you would have a problem if you upgrade the Postgres image but already have a database created with an earlier Postgres major version (as shown below).
Thank you both @MairusuPawa and @dpoulton for the discussion on database versions -- I have updated the GitHub readme to now reference postgres:15 (Docker Hub will reflect these new instructions the next time a new version of Joplin server is released).
If you previously used Postgres 13 and wish to upgrade to Postgres 15, I was able to update my own database using the following procedure:
NOTE: This is fairly generic in that my joplin-data is mounted at /mnt/hdd/docker/volume/joplin-data, so replace this location throughout with wherever you keep your data mounted.
Create a backup of the database and then kill your running joplin-server and joplin-db containers:
Update the Postgres version in the docker-compose.yml file. Example:
joplin-db:
image: postgres:15
Run the new image and allow the file structure to be created
docker compose up -d --force-recreate joplin-db joplin-server
Once the database is up and ready to accept connections (you can check this by viewing the logs), go ahead and copy the backup.dump file into the new volume mount, and import the database from the backup you created in step 1.
You're now running the latest supported version of PostgreSQL with Joplin, and all your notes are intact. Once you have verified everything is working, you can remove the old volume that you moved in step 2 as it's no longer needed:
Has there been a change in Joplin server image location because the latest automated build is at 2.13.3, now 19 days ago, while the current server build, as of 19 Nov, is at v2.13.5?
Are you referring to the x86 build and not the community ARM builds? If so, it looks like latest is set at 2.13.3 however you can pull 2.13.5 as server:2.13.5-beta.
If you are talking about the ARM builds, florider89's ARM server image for 2.13.5 appeared 15 hours ago, however etechonomy's has yet to be published.
I've used both without issue and I am really grateful that these two are providing an ARM build.
From looking at the etechonomy's GitHub page for joplin-server it looks like the build process is currently failing, which probably explains the delay.
