Add shared workflow for Heroku container deploys

[baelter]

Summary

Shared reusable workflow for repos using Heroku container stack. Builds Docker images in CI and pushes to Heroku's private container registry.

Companion to heroku.yml (git-push deploys) for repos that have been containerized.

Interface

Inputs:

• heroku-app — Heroku app name (defaults to repo name)
• branch — branch to deploy (defaults to default branch)
• targets — space-separated Dockerfile build targets (required)

Secrets:

• heroku-key — Heroku API key (required)
• build-args — newline-separated KEY=VALUE pairs for docker build --build-arg (optional)

Usage

jobs:
  heroku:
    uses: 84codes/actions/.github/workflows/heroku-container.yml@main
    with:
      targets: "web worker release"
    secrets:
      heroku-key: ${{ secrets.HEROKU_API_KEY }}
      build-args: |
        BUNDLE_GITHUB__COM=x-access-token:${{ secrets.ORG_GITHUB_TOKEN_FOR_CI }}

Test plan

• Test with billing-and-compliance (84codes/billing-and-compliance#220)

[dentarg]

Here's some feedback in form of a PR: #43

[dentarg]

Do we need to support multiple targets?

[dentarg]

Ah, it is the Heroku targets (web, worker, release) but they should all be the same image, so we don't need to docker build multiple times? 🤔

[dentarg]

Question is, is it important for Heroku to receive the push for each process type, or is one just enough, and heroku container:release without arguments, will release all?

[dentarg]

I renamed targets to process-types in my PR, but I think we should go either all the way and support individual images, or, if heroku container:release without arguments releases all, omit process-types from the deploy workflow.

[dentarg]

Now it worked 🎉 https://github.com/84codes/dev-playground84/actions/runs/22967795091

[baelter]

Do we need to support multiple targets?

When you push to Heroku's container registry, the CMD in the image is what runs. heroku.yml's is ignored for container registry pushes. So if you build one image with CMD puma and push it as both web and worker, both processes run Puma. That's the bug you hit.

Question is, is it important for Heroku to receive the push for each process type, or is one just enough, and heroku container:release without arguments, will release all?

We need to build each target separately docker buildx build --target web, --target worker, etc. Each Dockerfile stage has its own CMD, so each process type gets the right command. The shared stages (build, app) are cached by buildx/GHA, so it's not actually rebuilding everything N times. Heroku expects one image per process type.

I renamed targets to process-types in my PR, but I think we should go either all the way and support individual images, or, if heroku container:release without arguments releases all, omit process-types from the deploy workflow.

I renamed process-types back to targets since that's what you're passing: Dockerfile build targets. And moved the RUBY_VERSION logic out of the shared workflow since it should be language-agnostic. Repos that need it pass it via build-args.

[dentarg]

What was the reason for not using docker/build-push-action@v7? Changed in 2dd3cca

[dentarg]

Should we have a established way build and push outside of Github Actions, in the case GitHub Actions is unavailable? Today it is as simple as github push heroku

[dentarg]

Should we have a established way build and push outside of Github Actions, in the case GitHub Actions is unavailable?

That would be an argument for not using any actions in the workflow? Outsource everything to a shell script that is possible to run elsewhere (developer machine?)

[baelter]

What was the reason for not using docker/build-push-action@v7? Changed in 2dd3cca

docker/build-push-action can only build one target per step. Since targets is a dynamic input we need to loop. You can't loop over an action step. It's the same engine underneath, caching works the same way.

[baelter]

Should we have a established way build and push outside of Github Actions, in the case GitHub Actions is unavailable?

That would be an argument for not using any actions in the workflow? Outsource everything to a shell script that is possible to run elsewhere (developer machine?)

Good idea. The GHA-specific bits (layer caching, login-action, setup-buildx) wouldn't transfer anyway, so a local fallback would be simpler: just docker login, docker build --target $t -t registry.heroku.com/$APP/$t ., docker push, and heroku container:release. Might be worth having a script for that, easy to add when we need it.

[dentarg]

docker/build-push-action can only build one target per step. Since targets is a dynamic input we need to loop. You can't loop over an action step. It's the same engine underneath, caching works the same way.

Right, I got that same above answer from my 🤖 too but then I made it use tags:

actions/.github/workflows/heroku-container.yml

Line 99 in 9105b4c

tags: ${{ steps.prep.outputs.tags }}

EDIT:

I guess what is lost is in that change is --target

              --target "$target" \
              --tag "registry.heroku.com/$APP/$target" \

[baelter]

docker/build-push-action can only build one target per step. Since targets is a dynamic input we need to loop. You can't loop over an action step. It's the same engine underneath, caching works the same way.

Right, I got that same above answer from my 🤖 too but then I made it use tags:

actions/.github/workflows/heroku-container.yml

Line 99 in 9105b4c

tags: ${{ steps.prep.outputs.tags }}

Right, but that's exactly what caused the worker-starts-Puma bug? Multiple tags on one build = one image with one CMD pushed to all process types. We need separate builds with --target so each process type gets its own CMD from its Dockerfile stage.

[dentarg]

Might be worth having a script for that, easy to add when we need it.

I think we should construct it now?

[dentarg]

Right, but that's exactly what caused the worker-starts-Puma bug? Multiple tags on one build = one image with one CMD pushed to all process types. We need separate builds with --target so each process type gets its own CMD from its Dockerfile stage.

Yes updated my comment #42 (comment)