Add a workflow to try to create a container using ghcr

.github/workflows/build_image.yml

@@ -0,0 +1,97 @@
+name: build_image
+
+# this drew a lot of inspiration from lots of guides on the internet...
+# - ultimately, I was able to find
+#   https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#publishing-a-package-using-an-action
+#
+
+on:
+  # we limit the frequency of when this workflow is run
+
+  pull_request: # only run on PRs when relevant changes have been made
+    branches:
+      - main
+      - dev
+    paths:
+      - ".github/workflows/build_image.yml"
+      - "docker/**"
+
+  push:
+    branches:
+      - main
+      - dev
+    paths:
+      - ".github/workflows/build_image.yml"
+      - "docker/**"
+
+  workflow_dispatch:  # run this when we manually trigger the workflow
+
+env:
+  REGISTRY: ghcr.io
+  IMAGE_NAME: ${{ github.repository }}
+
+jobs:
+  build-and-push-image:
+    runs-on: ubuntu-latest
+    # Sets the permissions granted to the `GITHUB_TOKEN` for the actions in
+    # this job.
+    permissions:
+      contents: read
+      packages: write
+      attestations: write
+      id-token: write
+    steps:
+      # other guides seem to recommend using Docker Buildx (over the normal
+      # checkout step), but I have a sneaking suspicion, that it was "messing
+      # up" the `context` argument within the 
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      # Use the `docker/login-action` action to log in to the Container
+      # registry registry using the account and password that will publish the
+      # packages.
+      # - Once published, the packages are scoped to the account defined here.
+      - name: Log in to the Container registry
+        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      # Use the docker/metadata-action action
+      #     https://github.com/docker/metadata-action#about
+      # to extract tags and labels (from the GitHub repository, itself) that
+      # will be applied to the specified image.
+      - name: Extract metadata (tags, labels) for Docker
+        # set `id` to "meta", to make if possible for subsequent steps of this
+        # job to access the outputs of this current step
+        id: meta
+        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
+        with:
+          # the `images` argument sets the base name that we use for the image
+          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}-ROCm
+          # we primarily name the image based on the (shortenned) hash of the
+          # git-commit that we used to generate the image.
+          tags: type=sha
+
+      # This step uses the `docker/build-push-action` action to build the
+      # image, based on our repository's `Dockerfile`. If the build succeeds,
+      # it pushes the image to GitHub Packages.
+      - name: Build and export
+        uses: docker/build-push-action@v6
+        with:
+          push: true
+          context: .
+          # obviously specifies the path to the docker file
+          file: docker/rocm/Dockerfile
+          # use the tags collected by the "Extract metadata" step
+          tags: ${{ steps.meta.outputs.tags }}
+          # use the labels collected by the "Extract metadata" step
+          labels: ${{ steps.meta.outputs.labels }}
+
+      # the online guide provided by GitHub really wants us to perform an
+      # "attestation" step, but I can't get it to work. So, we just skip it
+      # - Honestly, that step is somewhat irrelevanat for our purposes (i.e.
+      #   creating an image to use as a build environment).
+      # - Attestation is mostly useful when the image is the primary "product"
+      #   a project wants to ship

docker/rocm/Dockerfile

@@ -1,4 +1,4 @@
-FROM rocm/dev-ubuntu-20.04:5.2.3
+FROM rocm/dev-ubuntu-20.04:5.5.1
 
 # Avoid annoying cmake -> tzdata install prompt
 ENV DEBIAN_FRONTEND=noninteractive