TT-16103: trigger release to suggested branch after merge

[olamilekan000]

change adds a workflow for adding a comment to a merged PR. This comment will then inturn trigger a PR on the target branch

[probelabs]

This PR introduces an automation that triggers release workflows after a pull request is successfully merged. It extends the existing branch-suggestion workflow to automatically post /release to <branch> comments for each of the suggested "required" and "recommended" branches. This creates a ChatOps-based trigger for downstream release processes, streamlining the hand-off from development to release.

Files Changed Analysis

• Workflow Configuration (.github/workflows/branch-suggestion.yml, branch-suggestion/branch_suggestion.yml): The workflow trigger is updated to include the pull_request.closed event. A new conditional job, post-release-commands, is added, which only executes if the pull request was merged. State is passed from the analysis job to this new job via a JSON file written to /tmp.
• New Automation Script (branch-suggestion/scripts/github/post-release-commands.js): This new Node.js script contains the core logic. It parses the suggested branches from the analysis step, filters for those with "required" or "recommended" priority, dynamically fetches the PR's base branch to avoid self-triggering, checks for pre-existing release comments to avoid duplicates, and posts the corresponding /release commands using the GitHub API. It also includes a security validation for branch names.
• Testing (branch-suggestion/scripts/github/__tests__/post-release-commands.test.js): A comprehensive suite of unit tests is added for the new script, covering various scenarios including successful comment posting, skipping duplicates, handling API errors, and validating branch names.
• API Utilities (branch-suggestion/scripts/github/github-api.js): The listPRComments function has been improved to handle pagination, ensuring all comments on a PR are fetched. The parseRepo utility function has been centralized here for better code reuse.
• Documentation (README.md, example-usage.yml.template): The documentation and usage examples are updated to reflect the new closed trigger type for the pull request workflow.

Architecture & Impact Assessment

• What this PR accomplishes: It automates the hand-off from a merged pull request to a release process by posting a standardized, machine-readable command as a PR comment.
• Key technical changes introduced:
  • The workflow now runs on the pull_request.closed event and uses the merged status as a condition for execution.
  • It passes state between jobs using the runner's local filesystem (/tmp/branch_suggestion_results.json).
  • A new Node.js script interacts with the GitHub API to post comments intended to trigger other workflows.
  • API interactions are made more robust with pagination handling and more efficient by centralizing the parseRepo utility.
  • A security check is added to validate branch names before they are used in comments.
• Affected system components: The primary component affected is the branch-suggestion reusable workflow. Its impact extends to any repository using this workflow, as it will begin posting comments on merged PRs. This creates an implicit contract with a downstream process that must be configured to act on these /release comments.

graph TD
    A[PR Merged] -->|Triggers `pull_request:closed`| B(branch-suggestion.yml Workflow)
    subgraph B
        C{Is PR Merged?} -- Yes --> D[analyze-and-suggest job]
        C -- No --> E[Exit]
        D -->|Saves results to disk| F["/tmp/results.json"]
        D --> G[post-release-commands job]
        G -->|Reads results from disk| F
        G --> H[Run post-release-commands.js]
    end
    subgraph "Node.js Script"
        H --> I{Filter for required/recommended branches}
        I --> J[For each branch]
        J --> K[Check for existing comment via API]
        K -- Not found --> L[Post `/release to <branch>` comment]
        K -- Found --> M[Skip]
    end
    L --> N((🚀 Downstream Release Workflow Triggered))

Loading

Scope Discovery & Context Expansion

• The changes are well-encapsulated within the branch-suggestion action. However, the feature's utility is entirely dependent on an external system. For this automation to be effective, repositories using this action must also have a separate workflow (e.g., a release bot) configured to be triggered by comments containing the /release to <branch> command.
• The improvement to listPRComments to handle pagination is a valuable enhancement that increases the robustness of the entire action, not just the new functionality, especially for PRs with many comments.
• The addition of a security check for branch names is a good defensive programming practice that mitigates potential injection risks.

Metadata

• Review Effort: 3 / 5
• Primary Label: feature

---

Powered by Visor from Probelabs

Last updated: 2026-06-11T08:32:16.056Z | Triggered by: pr_updated | Commit: ee2525d

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

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟡 Warning	branch-suggestion/scripts/github/post-release-commands.js:80	The branch name validation is too permissive. It allows branch names that could be misinterpreted as command-line options by downstream tools that consume these comments. For example, a branch named `-rf` would pass validation, but could cause unintended consequences if used directly in a shell command by a downstream workflow that parses this comment. 💡 Suggestion Strengthen the branch name validation to prevent patterns that can be confused with command-line flags. At a minimum, disallow branch names that start with a hyphen (`-`). For more robust security, consider aligning the validation with Git's own `git-check-ref-format` rules, which disallow other problematic characters and sequences (e.g., `..`, `~`, `^`, `:`).

Security Issues (1)

Severity	Location	Issue
🟡 Warning	branch-suggestion/scripts/github/post-release-commands.js:80	The branch name validation is too permissive. It allows branch names that could be misinterpreted as command-line options by downstream tools that consume these comments. For example, a branch named `-rf` would pass validation, but could cause unintended consequences if used directly in a shell command by a downstream workflow that parses this comment. 💡 Suggestion Strengthen the branch name validation to prevent patterns that can be confused with command-line flags. At a minimum, disallow branch names that start with a hyphen (`-`). For more robust security, consider aligning the validation with Git's own `git-check-ref-format` rules, which disallow other problematic characters and sequences (e.g., `..`, `~`, `^`, `:`).

\n\n ### ✅ Architecture Check Passed

No architecture issues found – changes LGTM.

Performance Issues (2)

Severity	Location	Issue
🟡 Warning	branch-suggestion/scripts/github/post-release-commands.js:81	The script checks for existing release comments by iterating through the entire list of comments for each target branch. For pull requests with a very large number of comments, this O(N*M) approach (where N is the number of target branches and M is the number of comments) can be inefficient. 💡 Suggestion To optimize this, pre-process the comments list once to extract all existing release markers into a `Set`. This changes the lookup for each branch to O(1) on average, making the overall check more efficient with a complexity of O(M + N) instead of O(M * N). Example: // Before the loop, create a set of existing markers const existingMarkers = new Set(); const markerRegex = /<!-- auto-release: (.*?) -->/; for (const comment of comments) { const match = comment.body.match(markerRegex); if (match) { existingMarkers.add(match[1]); // Add the branch name } } // Inside the loop, check against the set for (const [branch, priority] of targetBranches.entries()) { if (existingMarkers.has(branch)) { console.log(`ℹ️ Release comment for ${branch} already exists. Skipping.`); continue; } // ... post comment }
🟡 Warning	branch-suggestion/scripts/github/github-api.js:109-127	The implementation of `listPRComments` fetches all comments from a pull request using pagination. While this is functionally correct and an improvement over not handling pagination, it can lead to performance issues on pull requests with an extremely large number of comments (e.g., thousands), as it will sequentially fetch every page. This can increase the execution time of the GitHub Action. 💡 Suggestion For very high-comment PRs, the sequential fetching of comment pages can be slow. While the GitHub API does not support parallel fetching of pages, consider adding a warning log if the number of fetched pages exceeds a certain threshold. More importantly, the calling function (`post-release-commands.js`) should be optimized to handle the large list of comments efficiently, as noted in the other issue. No code change is strictly necessary here as the implementation is correct, but be aware of the potential for long run times in extreme edge cases.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/branch-suggestion.yml:33	The workflow checks out the 'github-actions' repository using a feature branch ('trigger-release-to-releas-branch-after-suggestion') instead of a stable branch like 'main' or a version tag. This is common during development but should not be merged into the main branch, as it makes the workflow dependent on a temporary branch that may be deleted, causing future workflow runs to fail. 💡 Suggestion Before merging, update the 'ref' to point to a stable branch like 'main' or a specific release tag to ensure the workflow's stability and long-term maintainability.

---

Powered by Visor from Probelabs

Last updated: 2026-06-11T08:31:31.948Z | Triggered by: pr_updated | Commit: ee2525d

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

[probelabs]

The PR looks solid and correctly implements the automated release comments logic.

A few highlights:

1. Idempotency: The use of <!-- auto-release: <branch> --> markers ensures we don't post duplicate comments if the workflow is re-run.
2. Early Exits: Correctly skipping analysis when a PR is closed but not merged saves unnecessary API calls.
3. Branch Filtering: Correctly filters out master and only targets required or recommended branches.

⚠️ Important Next Step for Adoption:
Because this is a reusable workflow, updating the on.pull_request.types here to include closed is only half the puzzle.
For this to actually trigger when a PR is merged in the tyk repository, you will also need to update the caller workflow in the tyk repo (.github/workflows/intelligent-branch-recomendations.yml) to include the closed event type:

on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
      - ready_for_review
      - closed # <--- This must be added in the tyk repo!

Great work on this!

[rafalgolarz]

After a call with @olamilekan000 and @konrad-sol we can merge it in to test it before the actual release.

[rafalgolarz]

Approved. Please remember about pushing changes in separated commits 🥺 🙏
Please confirm with @ilijabojanovic it can be merged in, thank you.