Running CI tests on Rebase & Merge?

[loryruta]

Why are you starting this discussion?

For our repository, we have a protected main branch, we develop in feature branches.

Every push to a feature branch which has its PR triggers the run of several workflows.

If the PR is green, the contributor is allowed to click "Rebase & Merge".

I don't want the CI to run again once the PR code is merged, as it was green on the PR. But I do want it to run if anything was rebased.

Suppose the following:

main: a => b => c
PR:     a => d => e

If the user clicks "Rebase & Merge" (can do that if there's no conflict):

PR: a => b => c => d => e

The CI is not run! And since the commit history has changed. I'd like it to run.

How can I fix it? Maybe our design of having a linear history is not ideal?

What GitHub Actions topic or product is this about?

CI/CD workflow

Discussion Details

[WalkedPlate]

This is a common pain point with linear history workflows. When you do Rebase & Merge, GitHub fast-forwards the commits onto main, and if those commits already passed CI on the PR branch, it doesn't re-trigger workflows for them.

A few ways to handle this:

1. Require branches to be up to date before merging — In your branch protection rules, enable "Require branches to be up to date before merging." This forces the contributor to rebase onto latest main before merging, which triggers CI on the PR branch. By the time it's green and merged, it's already tested against the latest main. This is the most common solution.

2. Run CI on push to main — Add push: branches: [main] to your workflow triggers. Yes it runs again after merge, but it catches exactly the scenario you're worried about. You can make it a lighter suite if the full run is too expensive.

3. Merge queue — GitHub's merge queue feature automates option 1. It rebases and tests PRs against latest main before actually merging. Might be overkill for a small team though.

Your linear history approach is totally fine — option 1 is what most teams using rebase workflows go with.

[pratikrath126]

WalkedPlate covered the main approaches. One more option: use GitHub Merge Queue (now GA) which automatically rebases and tests PRs against latest main before merging, ensuring CI ran on the final commit. It works with linear history and protected branches. If you prefer not to enable branch protection, you can also add a push trigger for main as a fallback but make it a lightweight validation (e.g., just build) to reduce cost. Your current design is fine; enabling "Require branches up-to-date" is usually the sweet spot.