Docker Hub image automated builds broken

[mstenta]

I broke the automated builds on Docker Hub when I cleaned up after farmOS/farmOS#580 :-(

Opening this so we don't forget about it...

[mstenta]

We have a choice here:

1. Try to set it up like it was before (or similar). I think this will require creating a new GitHub "machine user". Previously we had a farmOS-docker user which I deleted.

• Remove farmOS-docker GitHub user from "Linked Accounts" in farmOS organization settings.
  • Deactivate farmOS-docker GitHub user? I don't think this is used for anything else.

farmOS/farmOS#580 (comment)

2. Build the images via GitHub Actions and push to Docker Hub, like we are now doing for farmOS.

[mstenta]

Build the images via GitHub Actions and push to Docker Hub, like we are now doing for farmOS.

I'd rather go this route, if possible, for consistency and simplicity/security (no need to maintain another GitHub user, all controlled through the same shared GitHub secrets that the farmOS repo uses). It requires some development/testing though...

It also means we'd have to manually create/push the 2.0.0-beta2 tag I think...

[mstenta]

@ktohalloran ran into this: https://farmos.discourse.group/t/authorizing-a-farm-in-farmos-aggregator/2159/8

[ktohalloran]

@mstenta This probably doesn't exactly fit within the scope of this issue, but as it's at least related, it's worth mentioning that the Docker images referenced in docker-compose.deploy-template.yml refer to farmos/aggregator:backend and farmos/aggregator:frontend, rather than the latest images. Updating our version of docker-compose.yml based on that file to use the 2.x tagged versions at least partially fixed the issues I was having. Please let me know if there's some other action you'd like me to take with this issue.

[ktohalloran]

the Docker images referenced in docker-compose.deploy-template.yml refer to farmos/aggregator:backend and farmos/aggregator:frontend, rather than the latest images.

I just saw the deployment docs say these are meant to be aliases for the latest images, but our Docker containers were built on the images named that from 5 years ago. I don't really know how image aliases are supposed to work, so noting this here on the off-chance it has something to do with the automated build process.