fix(ci): fail the workflow when a Heroku release command fails

[AlaskanTuna]

Partially addresses #15.

The bug

The deploy step is git push --force ... HEAD:main. Heroku's git push exits 0 once the slug builds — the release: command in the Procfile (pnpm db:migrate:deploy) runs afterwards, and Heroku does not promote the slug if it fails. That failure never reaches the push exit code.

Result: six consecutive deploys (v231–v236, 29–30/07) reported green in GitHub Actions while none of them went live. Production served the v230 slug for two days. Nothing went red.

The fix

Two steps around the push:

1. Record the current release version beforehand, so the verify step can distinguish a genuinely new release from the one already live and never reads a stale succeeded.
2. Poll the Heroku Platform API after the push until a release newer than that version reaches a terminal state. succeeded passes; failed fails the job and prints the release command output inline; a 15-minute timeout also fails.

Verification

Both paths were exercised against the live Heroku API before committing:

• Success path — newest release parses as v239 succeeded → step exits 0.
• Failure path — release v236 parses as failed, output_stream_url is present, and fetching it surfaces exactly the error that was invisible before:

  Error code: P1012
  error: Environment variable not found: DIRECT_URL.
  

That test also caught a bug in this change: my first Range header used order=desc; max=1, which Heroku rejects with 400 bad_request. Corrected to max=1, order=desc.

YAML parses, prettier clean. Merging this exercises the new step for real.

https://claude.ai/code/session_01J6uoj2LBZBMeEkfyx3Bvn8

Summary by CodeRabbit

• Bug Fixes
  • Deployment verification now confirms that a Heroku release completes successfully.
  • Failed deployments report release status and available output.
  • Deployments time out with a clear failure result if no successful release appears within 15 minutes.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2a81e169-9c27-4c7f-a1a5-ed9addd1b50f

📥 Commits

Reviewing files that changed from the base of the PR and between bcc28bf and 26b7d0f.

📒 Files selected for processing (1)

• .github/workflows/ci-cd.yml

---

📝 Walkthrough

Walkthrough

The CI/CD deploy job records the current Heroku release before deployment. It then polls for a newer release for up to 15 minutes and evaluates its status. Failed releases include available release output.

Changes

Heroku release verification

Layer / File(s)	Summary
Capture Heroku release baseline .github/workflows/ci-cd.yml	The deploy job queries and stores the current Heroku release before pushing.
Verify deployed release .github/workflows/ci-cd.yml	After deployment, the job polls every 10 seconds for a newer release. It succeeds on succeeded, reports failed releases and available output, and exits on timeout.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant HerokuAPI
  participant HerokuRelease
  GitHubActions->>HerokuAPI: Query current release
  HerokuAPI-->>GitHubActions: Return release version
  GitHubActions->>HerokuAPI: Push deployment
  GitHubActions->>HerokuAPI: Poll for newer release
  HerokuAPI-->>GitHubActions: Return release status
  GitHubActions->>HerokuRelease: Read output when status is failed
  HerokuRelease-->>GitHubActions: Return release output

Loading

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/ci-detect-failed-heroku-release

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}