TT-17787: add workflow to promote the production tag

[olamilekan000]

Jira Ticket

TT-17787

Description

Change adds a "Promote production tag" workflow_dispatch that promotes the production tag
- Always promotes main
- Run summary records actor and old -> new SHA, so promotions are audited

Type of Change

• Bug fix
• New feature / action
• Refactor / improvement
• Documentation update
• CI/CD / workflow change
• Other (please describe):

Changes Made

Testing

• Manually triggered the affected workflow(s) and verified expected behaviour
• Checked that existing workflows are not broken

Checklist

• My changes follow the existing conventions in this repo
• I have updated relevant documentation (e.g. README.md, action description fields)
• For changed shell scripts (if applicable): I ran shellcheck, used an appropriate shebang and error handling, and preserved required executable permissions
• For changed actions/scripts (if applicable): I added or updated validation, tests, or clear manual verification steps
• For changed JavaScript files (if applicable): I ran the relevant tests and linting/formatting checks
• For changed Python files (if applicable): I ran the relevant tests and linting/formatting checks
• For Dockerfile changes (if applicable): I reviewed the base image, build context, image size, and runtime security
• For changed actions (if applicable): I updated the action.yml interface, defaults, outputs, and examples as needed
• I reviewed security implications, including least-privilege permissions and safe handling of inputs, secrets, and tokens (if applicable)
• For workflow changes (if applicable): I reviewed triggers, permissions, concurrency, and fork safety
• I have assigned a reviewer

[probelabs]

This PR introduces a new GitHub Actions workflow, Promote production tag, to standardize and audit the process of updating the production git tag to the latest commit on the main branch.

Files Changed Analysis

• .github/workflows/promote-production.yml: A new file was added, containing 59 lines that define the workflow. This is the only file changed in this PR.

Architecture & Impact Assessment

• What this PR accomplishes: It creates a controlled, manually-triggered (workflow_dispatch) process for production promotions. This enhances security and provides a clear audit trail for what was promoted, when, and by whom.

• Key technical changes introduced:

  • A new GitHub Actions workflow that runs on manual trigger.
  • Authentication using a GitHub App token, which is necessary to bypass tag protection rules that might be in place.
  • A script that checks if the production tag is already up-to-date with main to avoid unnecessary runs.
  • On successful promotion, it generates a run summary that records the old and new commit SHAs and the actor who triggered the workflow.

• Affected system components:

  • Git production Tag: The workflow directly modifies this tag.
  • Downstream Consumers: Any deployment pipelines, release automation, or other services that rely on the production tag will be affected. This workflow becomes the formal entry point for triggering those downstream processes.

Promotion Workflow Diagram

graph TD
    A[Manual Trigger] --> B{Promote Job};
    B --> C[Generate GitHub App Token];
    C --> D[Checkout Repository];
    D --> E{"Get SHAs for 'main' & 'production'"};
    E --> F{SHAs are different?};
    F -- No --> G[Exit Gracefully & Log];
    F -- Yes --> H["Force-update 'production' tag to 'main' SHA"];
    H --> I["Force-push 'production' tag to remote"];
    I --> J[Record Promotion in Job Summary];

Loading

Scope Discovery & Context Expansion

The introduction of this workflow implies that the production tag is a critical artifact for release or deployment processes. While the change is confined to a single file, its impact extends to any system that consumes this tag. To fully assess the impact, one would need to identify all downstream systems (e.g., CD pipelines, release builders) that are configured to trigger based on updates to the production tag. These systems are likely external to this repository.

Metadata

• Review Effort: 2 / 5
• Primary Label: chore

---

Powered by Visor from Probelabs

Last updated: 2026-07-22T10:51:30.130Z | Triggered by: pr_updated | Commit: a73ec38

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

✅ Security Check Passed

No security issues found – changes LGTM.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/promote-production.yml:39	The workflow hardcodes `origin/main` as the source for promotion. This lacks flexibility if the main development branch name changes or if promotions from other branches are needed in the future. 💡 Suggestion To improve extensibility and align with GitHub Actions best practices, use the `github.ref_name` context variable to dynamically refer to the branch the workflow is running on. Since this is a `workflow_dispatch` on the default branch, `github.ref_name` will resolve to `main`. This change makes the workflow more resilient to future branch renaming (e.g., `main` to `trunk`) without requiring code changes. Replace origin/main with ${{ github.ref_name }}.

✅ Security Check Passed

No security issues found – changes LGTM.

\n\n

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/promote-production.yml:39	The workflow hardcodes `origin/main` as the source for promotion. This lacks flexibility if the main development branch name changes or if promotions from other branches are needed in the future. 💡 Suggestion To improve extensibility and align with GitHub Actions best practices, use the `github.ref_name` context variable to dynamically refer to the branch the workflow is running on. Since this is a `workflow_dispatch` on the default branch, `github.ref_name` will resolve to `main`. This change makes the workflow more resilient to future branch renaming (e.g., `main` to `trunk`) without requiring code changes. Replace origin/main with ${{ github.ref_name }}.

\n\n ### Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/promote-production.yml:31-34	The workflow fetches the entire git history using `fetch-depth: 0`. This is unnecessary for the operations performed and can significantly increase checkout time, network usage, and disk consumption on the runner, especially for repositories with a long history. 💡 Suggestion To optimize performance, fetch only the required data. This can be achieved by performing a shallow checkout of the `main` branch (the default for `actions/checkout`) and then explicitly fetching the `production` tag in a separate step. Replace the existing 'Checkout' step (lines 29-34) with the following two steps: - name: Checkout main branch uses: actions/checkout@v4 with: token: ${{ steps.app-token.outputs.token }} - name: Fetch production tag run: git fetch origin tag production --no-tags || true This change ensures that only the HEAD of main and the specific production tag are fetched, making the workflow more efficient.

✅ Quality Check Passed

No quality issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-07-22T10:51:12.575Z | Triggered by: pr_updated | Commit: a73ec38

💡 TIP: You can chat with Visor using /visor ask <your question>

[rafalgolarz]

Left a comment. Thank you