[zakisk]

📝 Description of the Change

Remove the restriction that required GitOps comments to target only the HEAD commit of a branch for both GitHub and GitLab providers. Users can now trigger PipelineRuns on any commit in the push history, enabling more flexible automation workflows.

🔗 Linked GitHub Issue

Fixes #

🧪 Testing Strategy

• Unit tests
• Integration tests
• End-to-end tests
• Manual testing
• Not Applicable

🤖 AI Assistance

AI assistance can be used for various tasks, such as code generation,
documentation, or testing.

Please indicate whether you have used AI assistance
for this PR and provide details if applicable.

• I have not used any AI assistance for this PR.
• I have used AI assistance for this PR.

Important

Slop will be simply rejected, if you are using AI assistance you need to make sure you
understand the code generated and that it meets the project's standards. you
need at least know how to run the code and deploy it (if needed). See
startpaac to make it easy
to deploy and test your code changes.

If the majority of the code in this PR was generated by an AI, please add a Co-authored-by trailer to your commit message.
For example:

Co-authored-by: Claude noreply@anthropic.com

✅ Submitter Checklist

• 📝 My commit messages are clear, informative, and follow the project's How to write a git commit message guide. The Gitlint linter ensures in CI it's properly validated
• ✨ I have ensured my commit message prefix (e.g., fix:, feat:) matches the "Type of Change" I selected above.
• ♽ I have run make test and make lint locally to check for and fix any
  issues. For an efficient workflow, I have considered installing
  pre-commit and running pre-commit install to
  automate these checks.
• 📖 I have added or updated documentation for any user-facing changes.
• 🧪 I have added sufficient unit tests for my code changes.
• 🎁 I have added end-to-end tests where feasible. See README for more details.
• 🔎 I have addressed any CI test flakiness or provided a clear reason to bypass it.
• If adding a provider feature, I have filled in the following and updated the provider documentation:
  • GitHub App
  • GitHub Webhook
  • Gitea/Forgejo
  • GitLab
  • Bitbucket Cloud
  • Bitbucket Data Center

[pipelines-as-code]

Paco Review

The PR replaces the isHeadCommitOfBranch check (which required the commit to be the HEAD of a branch) with a CompareCommits API call that allows any commit that is part of the branch (status "behind" or "identical"). The old HEAD-only restriction and its test are removed, and new test cases cover behind, identical, ahead, and invalid-branch scenarios. Documentation is updated to remove the HEAD-only restriction note.

Paco could not check everything:

• Could not load 5 files at PR head 2456ba2 and base a53fa58 because they were too large, looked like credentials, or could not be read.
• A candidate could not be verified with the available context.

No new verified findings. This is not a guarantee that the change is defect-free.

1 candidates not published

• missing-pr-mux-reply-ahead-test: insufficient_evidence. The test file (pkg/provider/github/parse_payload_test.go) is excluded from the collected snapshot, so I cannot read the test infrastructure to confirm how muxReplies are wired up or whether the missing /repos/owner/reponame/pulls/777 entry actually matters. The getPullRequestsWithCommit function uses PullRequests.ListPullRequestsWithCommit (a different API endpoint pattern than /pulls/{number}), so it is unclear that the /pulls/777 mock is even needed for that code path. Without being able to read the full test setup and verify which endpoints are actually called during this test case, I cannot confirm or deny the claim.

_{Reviewed commit: 2456ba2. 0 verified findings; 0 summary-only.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.99%. Comparing base (a53fa58) to head (2456ba2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3059      +/-   ##
==========================================
+ Coverage   91.98%   91.99%   +0.01%     
==========================================
  Files         167      167              
  Lines       12973    12965       -8     
==========================================
- Hits        11933    11927       -6     
+ Misses       1039     1037       -2     
  Partials        1        1              

Flag	Coverage Δ
unit-tests	91.99% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

🟡 Changes recommended

Unresolved ancestry and branch-existence validation gaps allow non-ancestor commits to be treated as default-branch commits and SHAs or tags to be accepted as branches, potentially selecting incorrect pipelines.

2 open issues

• Validate ancestry for implicit and explicit retest branches · New
• Validate branch existence before comparing commits · New

What changed in this PR

This PR enables GitHub GitOps commands on historical commits, replacing the branch-HEAD restriction with an ancestry check when a branch is explicitly supplied.

Changes:

• Accepts older commits belonging to an explicitly selected GitHub branch.
• Updates payload tests and removes the obsolete HEAD-check helper and tests.
• Removes the HEAD-only restriction from the shared push-command guide.

File	Description
pkg/​provider/​github/​parse_payload.go	Adds commit comparison for explicitly selected branches.
pkg/​provider/​github/​parse_payload_test.go	Covers historical commits, branch HEADs, and invalid comparisons.
pkg/​provider/​github/​github.go	Removes the HEAD-only validation helper.
pkg/​provider/​github/​github_test.go	Removes tests for the deleted helper.
docs/​content/​docs/​guides/​gitops-commands/​push-commands.md	Removes the documented HEAD-only limitation.

_{Review effort: Balanced}

[theakshaypant]

How would this impact ok-to-test?

[zakisk]

How would this impact ok-to-test?

None, this is about Gitops comment on pushed commits where we don't need ok-to-test comment.