GitHub Release Process

Our release process is fully automated via GitHub Actions dispatch workflows. Release engineers trigger workflows from the GitHub Actions UI — no manual git merges or CLI commands needed.

Who Can Trigger Releases

Only members of these teams can trigger release workflows:

• release-devs — release engineers
• devops — infrastructure team

Unauthorized users will be denied at the authorize job.

---

Release Flow Overview

---

Step 1: Merge to Main

Workflow: Release: Merge to Main Location: Actions tab → Release: Merge to Main → Run workflow

This merges either develop or hotfix into main.

Inputs

What happens

1. Validates the triggering user is in release-devs or devops
2. Fetches main and the source branch
3. Merges source → main with --no-ff
4. Pushes to main
5. On conflict: sends Slack notification with conflicting files, aborts merge

After merge

The Merge main → develop & hotfix workflow triggers automatically on push to main. This keeps develop and hotfix in sync with main. If there's a conflict during realignment, a Slack notification is sent.

---

Step 2: Pre-Production (Release PR + Notes)

Workflow: Release: Pre-Production Location: Actions tab → Release: Pre-Production → Run workflow Restriction: Can only be triggered from the main branch

This creates (or updates) a release PR from main → production with auto-generated release notes.

Inputs

What happens

1. Pre-flight checks: verifies main is ahead of production, warns if develop has unmerged commits
2. Walks all commits in production...main diff
3. For each commit, finds associated PRs, extracts Jira ticket IDs from PR titles, branch names, and commit messages
4. Links Jira tickets as [EN-XXXXX](https://crelio.atlassian.net/browse/EN-XXXXX)
5. Optionally generates AI-enhanced release notes via Gemini (with raw fallback)
6. Creates or updates a PR from main → production with labels: release, production, ignore-semantic-pull-request
7. Requests review from release-devs team

Notes-only mode

If a release PR already exists, use notes_only: true to refresh the PR body with the latest notes without creating a new PR. Useful after cherry-picks or last-minute merges.

---

Step 3: Merge Release PR

Once QA approves the release PR on the sanity environment:

1. Go to the release PR (main → production)
2. Review the release notes
3. Merge the PR (squash or merge commit)

After merge

The branch realignment workflows handle syncing production changes back to develop and hotfix automatically.

---

Step 4: Release Summary (Cross-Repo)

Workflow: Release: Summary Repo: CrelioHealth/release-notes Location: Actions tab → Release: Summary → Run workflow

This generates a combined release summary across all three main repos and posts it to Slack.

Inputs

What happens

1. Compares production...main diff in each repo:
   • livehealth-frontend
   • crelio-app
   • livehealthapp
2. Extracts Jira ticket IDs from commits, PR titles, and branch names
3. Fetches Jira issue titles from the Jira REST API
4. Deduplicates tickets across repos (same EN-XXXXX in multiple repos shows once)
5. Removes reverted tickets
6. Posts Slack Block Kit message with:
   • Numbered Jira ticket list with links
   • Repo tags per ticket
   • Buttons to release PRs
   • User and group tags

---

Conflict Handling

All merge workflows send Slack Block Kit notifications on conflict. Each notification includes:

• Header with merge direction (e.g., hotfix → develop)
• Repo link
• Source PR (last merged PR that triggered the merge)
• Target PR (last PR on the target branch)
• Who triggered it
• Conflicting files in a code block
• View Diff and Workflow Run buttons

Resolving conflicts

1. Check the Slack notification for conflicting files
2. Locally:

   git checkout <target-branch>
   git merge origin/<source-branch>
   # Resolve conflicts
   git commit
   git push origin <target-branch>

3. Or create a PR from source → target to resolve in the GitHub UI

---

Automated Branch Realignment

These workflows run automatically — you don't trigger them manually:

Both have concurrency groups to prevent race conditions when multiple PRs merge quickly.

---

Quick Reference

Release day checklist

1. Merge to Main — trigger Release: Merge to Main (feature-release or hotfix-release)
2. Wait for branch realignment to complete
3. Pre-Production — trigger Release: Pre-Production (target: production)
4. QA verifies on sanity environment
5. Merge the release PR
6. Release Summary — trigger Release: Summary in the release-notes repo
7. Verify production deployment

Workflow locations

Required secrets

Required variables

---

Last Updated: March 2026