TT-15860 added workflow to suggest branches to target

[sredxny]

Description

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] I ensured that the documentation is up to date
• [ ] I explained why this PR updates go.mod in detail with reasoning why it's required
• [ ] I would like a code coverage CI quality gate exception and have explained why

Ticket Details

TT-15860

Status	Closed
Summary	Unnecessary error message in gateway logs

Generated at: 2025-10-29 21:22:33

[probelabs[bot]]

🔍 Code Analysis Results

This PR introduces a new GitHub Actions workflow to automatically suggest appropriate target branches for pull requests based on information from an associated Jira ticket.

Files Changed Analysis

• File Added: .github/workflows/branch-suggestion.yml
• Changes: 17 lines added, 0 deleted.
• Summary: The change is confined to a single new workflow file that adds CI/CD automation without altering any application source code.

Architecture & Impact Assessment

• What this PR accomplishes: It automates the process of suggesting the correct base branch for pull requests, aiming to reduce merge errors and the manual effort required from developers to select the correct target branch.
• Key technical changes introduced:
  • A new GitHub Actions workflow, intelligent branch merge suggestion, is added. It triggers on pull request opened, synchronize, and reopened events.
  • It utilizes a reusable workflow from TykTechnologies/github-actions, pinned to a specific commit hash (e6be482cae4727719319398446638506847cb7ec) for stability.
  • The workflow requires a JIRA_TOKEN secret to communicate with Jira.
  • It is configured with pull-requests: write and contents: read permissions to post comments on the PR and read repository content.
• Affected system components:
  • CI/CD Pipeline: A new automated job is added to the pull request lifecycle.
  • Developer Workflow: Developers will receive automated comments on their pull requests with suggested target branches, guiding the merge process.

The workflow can be visualized as follows:

graph TD
    A[Pull Request Event<br>(opened, synchronize, reopened)] --> B{Trigger "intelligent branch merge suggestion" workflow};
    B --> C[Execute Reusable Workflow<br>TykTechnologies/github-actions];
    C --> D{Fetch Data from Jira<br>using JIRA_TOKEN};
    D --> E[Determine Suggested Branches];
    E --> F[Post Comment on PR];

Scope Discovery & Context Expansion

• The core logic for generating branch suggestions resides within the external reusable workflow in the TykTechnologies/github-actions repository. A complete review of the suggestion mechanism would require inspecting that workflow to understand how it processes Jira ticket information.
• The functionality is dependent on a valid and correctly-stated Jira ticket being linked in the pull request. The comment history shows that another linter failed because the linked ticket TT-15860 is already Closed. This highlights a dependency: for the new workflow to function correctly, PRs must be linked to active Jira tickets in an appropriate state.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2025-10-29T21:26:56.089Z | Triggered by: synchronize | Commit: 3fbb4fc

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

[probelabs[bot]]

🔍 Code Analysis Results

Security Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/branch-suggestion.yml:15-17	The workflow passes the `JIRA_TOKEN` secret to a reusable workflow from another repository. This establishes a trust relationship, granting the reusable workflow access to the secret and the permissions defined in this workflow (`pull-requests: write`, `contents: read`). While pinning the action to a specific commit hash is a critical security best practice that has been correctly implemented, the security of this workflow is now dependent on the security of the code in the reusable workflow. 💡 Suggestion Ensure that the reusable workflow at `TykTechnologies/github-actions/.github/workflows/branch-suggestion.yml` (commit `e6be482cae4727719319398446638506847cb7ec`) has undergone a security review to verify it handles secrets and permissions safely. This verification is crucial for mitigating potential supply-chain risks.

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/branch-suggestion.yml:3	The workflow is configured to run on the `pull_request` event and uses secrets (`JIRA_TOKEN`). For security reasons, GitHub does not grant workflows triggered by this event from forked repositories access to secrets. Consequently, this workflow will fail for external contributors submitting pull requests from forks. 💡 Suggestion If this workflow must run for external contributors, consider using the `pull_request_target` trigger, but be aware of its significant security implications. If the workflow is only intended for internal contributors, this behavior is acceptable, but it would be beneficial to add a comment to the workflow file clarifying this limitation.

Dependency Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/branch-suggestion.yml:15	The reusable workflow is pinned to a specific commit hash, which is a best practice for stability and security. However, this is inconsistent with other workflows in the repository (e.g., `.github/workflows/lint.yml`) that reference reusable actions using `@main`. This inconsistency in dependency management strategy across workflows should be addressed for better maintainability. 💡 Suggestion For improved architectural consistency, consider adopting a uniform versioning strategy for all reusable workflows. A repository-wide decision to either pin all reusable workflows to commit hashes or use a floating reference like `@main` or a version tag would be beneficial.

✅ Connectivity Check Passed

No connectivity issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2025-10-29T21:26:57.315Z | Triggered by: synchronize | Commit: 3fbb4fc

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

[github-actions[bot]]

🚨 Jira Linter Failed

Commit: 3fbb4fc Failed at: 2025-10-29 21:22:35 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to validate Jira issue: jira ticket TT-15860 has status 'Closed' but must be one of: Dod Check, In Dev, In Code Review, Ready For Dev

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.

[github-actions[bot]]

🎯 Recommended Merge Targets

Based on JIRA ticket TT-15860: Unnecessary error message in gateway logs

Fix Version: Tyk 5.10.0

Required:

• master - Main development branch - ensures fix is in all future releases

Recommended:

• release-5.10 - Minor version branch for 5.10.x releases

---

📋 Workflow

1. Merge this PR to master first
2. After merging, comment on the merged PR with /release to <branch> to cherry-pick to release branches
3. Example: /release to release-5.8
4. The bot will automatically create a backport PR to the specified release branch

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud