Joplin Server for arm64 & arm/v7

dpoulton · 2021-09-26T09:16:30.767Z

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.

etho201 · 2021-09-27T04:19:30.985Z

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).

dpoulton · 2021-09-27T06:05:49.424Z

etho201:

... 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.

Joplin Server :latest? Lounge

For information I've now created a new script so that I can mark any beta, once it's proven, as "latest". So that will make it easier for me to quickly tag a release without having to rebuild everything, and also for users since you can now more frequently get updates (provided you use latest).

etho201 · 2021-09-28T04:13:31.861Z

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.

dpoulton · 2021-09-28T10:47:07.098Z

etho201:

... this makes more sense once the -beta tag is ditched.

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.

tessus · 2021-09-28T14:31:23.466Z

dpoulton:

will subsequently tag that x.x.x-beta image with latest as well

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.

laurent · 2021-09-28T15:29:12.402Z

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.

tessus · 2021-09-28T19:33:04.426Z

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.

laurent · 2021-09-28T23:13:47.335Z

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.

MairusuPawa · 2023-04-15T14:37:00.427Z

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!

dpoulton · 2023-04-15T16:34:27.140Z

@MairusuPawa welcome to the forum.

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).

image1449×194 35.4 KB

etho201 · 2023-04-16T05:42:10.124Z

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:

docker exec joplin-db /bin/bash -c '/usr/bin/pg_dump -Fc -U joplin joplin' > /mnt/hdd/docker/volume/joplin-data/backup.dump
docker kill joplin-db joplin-server

At this point, move the mounted directory to some place else. For example:

mv /mnt/hdd/docker/volume/joplin-data /mnt/hdd/docker/volume/joplin-data-pg13

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.
```
cp /mnt/hdd/docker/volume/joplin-data-pg13/backup.dump /mnt/hdd/docker/volume/joplin-data/
docker exec joplin-db pg_restore --clean -U joplin -d joplin /var/lib/postgresql/data/backup.dump
```
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:
```
rm -rf /mnt/hdd/docker/volume/joplin-data-pg13
```

Fezster · 2023-11-20T11:36:36.644Z

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?

dpoulton · 2023-11-20T12:03:01.743Z

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.

Fezster · 2023-11-20T12:42:35.684Z

I've always used etechonomy's docker build without issue on my server.

dpoulton · 2023-11-20T13:55:36.280Z

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.

etho201 · 2023-11-21T18:49:02.836Z

There's an issue affecting builds of arm/v7 with the latest release. For now, the quickest fix was to disable the build process for that architecture. Thankfully, arm64 is unaffected. I now have Joplin Server v2.13.5 arm64 published to Docker. Sorry for the delay!

Tobi · 2023-11-26T22:42:58.534Z

etho201:

arm/v7

Is there any hope that this can be repaired?

Fezster · 2023-12-27T00:51:47.013Z

server-v2.14.1 has been out for a week+. Are the arm64 automated builds also affected?

etho201 · 2023-12-28T14:59:22.154Z

The issue affecting arm64 has been resolved. v2.14.1 is now available.