Mise en place d'auto-build lors d'une release GitHub (via GHCR) (#35)

* Attempt to publish the image via GHCR upon successful test

* Fix path for final build

* Update README.md

* Update README.md

.github/workflows/docker.yml

@@ -1,11 +1,12 @@
 # Inspiration:
 # - https://docs.github.com/en/actions/guides/publishing-docker-images#publishing-images-to-github-packages
 # - https://github.com/docker/build-push-action/blob/master/docs/advanced/test-before-push.md
-name: Test the docker image
+# - https://github.com/etalab/transport-tools/blob/master/.github/workflows/docker.yml
+name: Test and publish the docker image
 on:
-  # TODO: publish 1/ "master" for each "master" merged PR
-  # then 2/ for each "release". This will let us iterate
-  # without consequences, and control the moment when we want to tag & ship.
+  # See https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#webhook-payload-object-38
+  release:
+    types: [ released, prereleased ]
   push:
     branches:
       - master
@@ -68,9 +69,24 @@ jobs:
       - name: Test that Erlang can start and has (major) expected version
         run: docker run --rm ${{ env.TEST_TAG }} /bin/bash -c "erl -noshell -eval 'erlang:display(erlang:system_info(system_version))' -eval 'init:stop()'" | grep '${{ env.TEST_EXPECTED_ERLANG_OUTPUT }}'
 
-      # TODO: handle testing then publication using:
-      # - https://github.com/etalab/transport-ops/issues/30
-      # - https://github.com/etalab/transport-tools/blob/master/.github/workflows/docker.yml
-
+      # If we reach this point, we consider the tested imaged is OK, so we can extract the metadat & publish
+      # https://github.com/docker/metadata-action
+      - name: Extract metadata (tags, labels) for Docker
+        id: meta
+        uses: docker/metadata-action@3a3bb3a81753dc99f090d24ee7e5343838b73a96
+        with:
+          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
+
+      # https://github.com/docker/build-push-action
+      # TODO: verify if this will rebuild everything or not. Maybe we can re-tag
+      # the tested image above?
+      - name: Build and push Docker image
+        uses: docker/build-push-action@a66e35b9cbcf4ad0ea91ffcaf7bbad63ad9e0229
+        with:
+          context: transport-site
+          push: true
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+
       # TODO: consider caching
       # - https://github.com/docker/build-push-action/blob/master/docs/advanced/cache.md

README.md

@@ -1,6 +1,21 @@
 # transport-ops
+
 Scripts and config files for provision and deploy transport and required services
 
+# New release process (GitHub actions + GitHub Container Registry)
+
+To create a new release as a Docker image, just create a GitHub release (with tag name == release name), with a changelog.
+
+On release creation (see https://github.com/etalab/transport-ops/blob/master/.github/workflows/docker.yml), a build will start, and should normally result into the publication of a GitHub-hosted Docker image named just like the release.
+
+You can find the resulting image here: https://github.com/etalab/transport-ops/pkgs/container/transport-ops
+
+ One major caveat: the workflow must exist at the moment the tag is created (https://github.community/t/workflow-set-for-on-release-not-triggering-not-showing-up/16286/7):
+
+ > The trigger only executes when a release is created using a tag that contains the workflow.
+
+# LEGACY DOCUMENTATION below - kept until the moment we clean it
+
 ## Image naming convention
 
 In the past images were named "betagouv/transport:x.y.z".