deploy.yml

name: Deploy
on:
  workflow_run:
    workflows: [CI Build] # change this to match your build workflow name
    types: [completed]
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: your-environment-name-here
      url: https://your-app.example.com
    name: Deploy demo
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Push to Heroku
        run: git push -f https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP_NAME.git main
        env:
          HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }}
          HEROKU_APP_NAME: your-heroku-app

With some small tweaks, you can achieve a nicer UI:

jobs.deploy -> jobs.deployment

jobs:
  deployment:
    environment:
      name: production
      url: https://your-heroku-app.herokuapp.com

Oh, very nice! And then we can use the GitHub slack integration instead of the action. Will update.

Just noticed I did sneak a force flag (-f) into the push command which you may not want. It made sense for my use case, but I guess it's safer without!

Just noticed I did sneak a force flag (-f) into the push command which you may not want. It made sense for my use case, but I guess it's safer without!

I think it's appropriate as sometimes people manually deploy different branches.

Just noticed I did sneak a force flag (-f) into the push command which you may not want. It made sense for my use case, but I guess it's safer without!

I think it's appropriate as sometimes people manually deploy different branches.

Makes sense. You may want to add a concurrency key, in case you merge a couple PRs in quick succession and their CI workflows complete out of order.

Edit: Actually I'm not even sure that'd keep you safe. Here be dragons -f.

You may want to add a concurrency key, in case you merge a couple PRs in quick succession and their CI workflows complete out of order.

Yes. Very important addition

this is not really important, but eye catching:

naming job deployment instead of deploy adds some kind of progressbar + text: deploying to

this is not really important, but eye catching:

naming job deployment instead of deploy adds some kind of progressbar + text: deploying to

The progress bar + text shows up for without explicitly naming it "deployment" -- I think it's the presence of environment

I think it's the presence of environment

You are right.