Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
So, since #1060, we're not able to do deploys. They error like as in: https://github.com/mozilla-services/autograph/actions/runs/11748424011/job/32732461427 I thought the `sha` I was removing was the hash of the image, but it's the git commit's sha! The real problem seems to be we are pushing to both dockerhub and to Google Artifact Registry (GAR) at the same time after our builds on `main`. We wanted only to push to GAR and then on release copy them to dockerhub. That happens becuase the `docker/metadata-action` action gets called with both Docker Hub and GAR in its `images` argument. So, to fix this, I thought really hard about what we want to happen. We currently have two separate deploy systems. In one, we need to push non-`latest` tags to Docker Hub only when we want a staging deploy to occur. In the other, we need to push to a semver-like tag to Google Artifact Registry only when we want a staging release to occur. Production deploys in both require a human to intervene and change the expected deployed version. In the deploy system that uses GAR, we need a push to `latest` on each commit to effect a dev deploy. We also use the `latest` on Docker Hub to represent the current `main` branch's code for use in other people's projects. So, let's sum that up in terms of tags. On each commit to `main`, we want these docker tags and only these docker tags pushed up: * `:latest` to `GAR` * `:sha-<the git commit's sha>` to GAR * `:latest` to Docker Hub On each release, we want these docker tags and only these docker tags pushed up: * `:<git tag of release>` to GAR * `:<git tag of release>` to Docker Hub Those `:<git tag of release>` will be copies of the `sha-<the git commit's sha>` tag that was made on commit to `main` and pushed to GAR. This patch does that by breaking up single `docker/metadata-action` action call to two. One for GAR and one for Docker Hub; both with different sets of tags depending on whether this is a "push" (commit on main) or "release" event. But doing just that doesn't quite solve it. Becuse we use `docker/build-push-action` to both build and push to GAR in one go. To avoid building on release, we have to skip that step, but that step is what was doing all the work of talking to GAR. So, we also need to, only on release, "copy" the previously made `sha-` tag to the `:<git tag of release>` tag within GAR itself. This may be the point where we should split this one GitHub Actions workflow into separate `deploy` and a `release` workflows. There is a lot of thinking and conditional checks. It would cost a significant amount of duplication between these two actions to do so. But I could be told to do so. (The crane install would be especially annoying; maybe we should just go install it, anyway, since this install instructions were for a non-Go environment)
- Loading branch information