[server] Publish Docker image automatically on 15th of every month (#5088)

.github/workflows/server-publish.yml

@@ -1,27 +1,24 @@
 name: "Publish ghcr (server)"
 
 on:
-    # Run manually, providing it the commit.
-    #
-    # To obtain the commit from the currently deployed museum, do:
-    # curl -s https://api.ente.io/ping | jq -r '.id'
-    #
-    # See server/docs/publish.md for more details.
+    # Run automatically on 15th of every month, at 05:00 UTC.
+    schedule:
+        - cron: '0 5 15 * *'
+    # Run manually if needed to publish out of schedule.
     workflow_dispatch:
-        inputs:
-            commit:
-                description: "Commit to publish the image from"
-                type: string
-                required: true
 
 jobs:
     publish:
         runs-on: ubuntu-latest
         steps:
+            - name: Determine commit from prod museum
+              run: |
+                  echo "museum_commit=$(curl -s https://api.ente.io/ping | jq -r .id)" >> $GITHUB_ENV
+
             - name: Checkout code
               uses: actions/checkout@v4
               with:
-                  ref: ${{ inputs.commit }}
+                  ref: ${{ env.museum_commit }}
 
             - name: Build and push
               uses: mr-smithers-excellent/docker-build-push@v6

server/docs/publish.md

@@ -21,26 +21,23 @@ commit to the GitHub Container Registry (GHCR) so that it can be used by folks
 without needing to clone our repository just for building an image. For more
 details about the use case, see [docker.md](docker.md).
 
-To publish such an external image, firstly find the commit of the currently
-running production instance.
+These images are published automatically by the "Publish (server)" workflow on
+the 15th of every month. If needed, the workflow can also be manually triggered
+invoked to publish out of schedule. It can be triggered on the GitHub UI, or by
 
-    curl -s https://api.ente.io/ping | jq -r '.id'
+```sh
+gh workflow run server-publish.yml
+```
 
-> We can publish from any arbitrary commit really, but by using the commit
-> that's already seen production for a few days, we avoid externally publishing
-> images with issues.
-
-Then, trigger the "Publish (server)" workflow, providing it the commit. You can
-trigger it either from GitHub's UI or using the `gh cli`. With the CLI, we can
-combine both these steps too.
-
-    gh workflow run server-publish.yml -F commit=`curl -s https://api.ente.io/ping | jq -r '.id'`
+> It uses the commit that is deployed on production museum instances. We can
+> publish from any arbitrary commit really, but by using the commit that's
+> already seen production, we avoid externally publishing images with issues.
 
 Once the workflow completes, the resultant image will be available at
 `ghcr.io/ente-io/server`. The image will be tagged by the commit SHA. The latest
 image will also be tagged, well, "latest".
 
 The workflow will also update the branch `server/ghcr` to point to the commit it
-used to build the image. This branch will be overwritten on each publish, and
-thus it `server/ghcr` points to the code from which the most recent ghcr docker
-image for museum has been built.
+used to build the image. This branch will be overwritten on each publish; thus
+`server/ghcr` will always points to the code from which the most recent ghcr
+docker image for museum has been built.