tibdex / autosquash

:package: GitHub Action to update PRs with outdated checks and squash and merge the ones matching all branch protections

Autosquash

Autosquash automatically updates and merges your pull requests.

Autosquash is a simple and opinionated JavaScript GitHub action integrating especially well in repositories with branch protections with strict status checks protecting against semantic conflicts.

Pull requests with the autosquash label will be:

• updated when new commits land on their base branch and make their status checks outdated.
• squashed and merged once all the branch protections are respected:
  • The description of the pull request, up to its first thematic break, will become the message of the squashed commit.
  • The creator of the pull request will be the main author of the squashed commit. If other people authored commits in the pull request, they will be added as co-authors of the squashed commit.

Maintenance update

Focus has shifted to the development of Auto-update, the successor of Autosquash.

Indeed, GitHub now supports pull request auto-merge out of the box. The only thing not taken care of by GitHub (yet) is automatically updating a pull request when its base branch receives new commits and that's exactly what Auto-update does.

Usage

• Add this .github/workflows/autosquash.yml to your repository.
• Add the autosquash label to pull requests you want to merge.

Why squash and merge?

Autosquash favors squash and merge over regular merge or rebase and merge for the following reasons:

GitHub is merge oriented rather than rebase oriented

GitHub handles merge commits graciously. Indeed, it has a web interface for resolving merge conflicts and it helps the reviewer not wasting time reviewing conflict-free merge commits by displaying this:

On the other hand, rebasing a pull request rewrites its Git history and GitHub doesn't like that. For instance, clicking on a notification concerning changes in a pull request with rewritten history will give you this:

The same thing will happen if you click on the file link of a line comment but the pull request was rebased since the comment was posted.

Another minor inconvenience with rebase and merge is that it's harder, when looking at the list of main commits, to know which commit comes from which pull request. You have to go to the actual commit page for GitHub to show you which pull request had it. With regular merge or squash and merge, GitHub adds a pull request link in the commit title so the pull request is always a single click away from the list of commits.

git rebase and git push --force are useful when prototyping a feature locally. They also allow to create a pull request with a clean initial Git history. But once you ask for a review and start collaborating on a pull request, it's best to stop using these commands.

This eliminates the rebase and merge option and leaves us with the regular merge or squash and merge ones.

The pull request is the unit of change

It's nice to make small and atomic commits inside a big pull request but it's even nicer to make small and atomic pull requests.

The pull request is the unit of change:

• It is reviewed as a whole. All the commits have to be reviewed and approved since it's their aggregated changes that will be applied to main when merged.
• It is tested as a whole. CI providers only test the pull request's head commit. It's the only one guaranteed to not break the build and the tests. All the intermediate commits, as carefully crafted as they may be, might break git bisect if they land individually on main.

By the time a pull request is ready to be merged, its Git history will often contain commits addressing review comments, fixing tests, typos, or code formatting. There is no point in making these commits part of main's history. We would rather gather all the pull request's commits into a single cohesive commit and put it on top of main. And that's where the Autosquash WALL·E inspired logo and 📦 emoji come from!

The regular merge option doesn't help keeping main's history clean, so we're only left with the squash and merge one.

Read more

• Two years of squash merge
• Utter disregard for Git commit history
• How to split pull requests

autosquash's Issues

[QUESTION] Update branch with rebase

Hi,

Thank you for this amazing bot !

I would like to know if there is a way to avoid the merge commit when autosquash update the branch. Can i specify the update method (like merge/rebase) in the configuration ?

Example:

Thank you :)

Only auto-update with no auto-merge

Is it possible to configure the action to only auto-update the branch but not auto-merge?
If it be controlled by different labels it'll be amazing (autosquash / automerge)

Autosquash is appending the PR's body

I see it described in "The description of the pull request will become the message of the squashed commit."

Why is doing that? I don't see an option to disallow it.

Autosquash doesn't squash on PRs with a single commit

I don't think this is ideal given your comment: #24 (comment)

I would like my team to only focus on PR title and description - I am also enforcing semantic PR title for a clean commit history.

Autosquash 2.0.2 not respecting the code owner protection rule

With the latest version, it seems that the code owner restriction is not considered when using autosquash.
We have the following restriction on our dev branch that uses autosquash:

Starting very recently (pretty confident that's when v 2.0.2 was rolled out), it seems that only having 2 reviewers was deemed enough even though no code owner singed off on the PRs.
And so the incoming PRs were let through, their branches merged to the dev branch and then deleted.
Pinning our usage to v 2.0.1 appears to get us rid of this unfortunate behavior.

Autosquash not updating the PR

I created a PR, added the expected label but the PR has not been updated despite been outdated.

I had similar issue with Autorebase App lately although previously it was perfectly working.

AutoSquash v2 not working - ##[error]Not Found and Deprecation Error

Followed the instructions and setup a user with a a personal access token under AUTOSQUASH_TOKEN. It does not kick off the bot after all the github checks are done (saw that was reported already)

Also getting this cryptic error:

Deprecation: [@octokit/request-error] `error.code` is deprecated, use `error.status`.
    at RequestError.get (evalmachine.<anonymous>:1:84855)
    at isRetryError (evalmachine.<anonymous>:1:48989)
    at evalmachine.<anonymous>:1:49261
    at a.minTimeout (evalmachine.<anonymous>:1:39411)
    at processTicksAndRejections (internal/process/task_queues.js:93:5) {
  name: 'Deprecation'
}
Consider merging #2176
Fetching pull request details
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
Refetching details to know mergeable state
##[error]Not Found

Is this a setup issue?

Only merge approved PRs with no pending comments

We want people to approve a PR with small comments but not let the bot submit the PR until the author addresses the comments.

Failing with 'Input required and not supplied: github_token' error

I tried setting this up recently with a personal access token, ran into this error running the action. Pretty sure I set it up as per recommendations here. I did a search on github and looks like a few repositories there were succesfully using this at one point ran into the error and have removed the workflow as a result.

Only autosquash approved PR's

To avoid unnecessary merges and check runs, the search query for PR's could be updated to include review:approved. I'm not sure how this works in repositories that don't require approvals for merge, but perhaps the action could check requiresApprovingReviews and modify the query accordingly?

Auto-delete branch after merge

autosquash is really nice, coming from bors (and nothing before that). would it be possible to add an option to delete the squashed branch after merge ?

Autosquash is merging PRs even if a review is pending

It would be nice to wait for all pending reviews.

Support for custom labels?

Hey, love this action - it's have been using it for a month and it's working great!

I was wondering if there's any specific reason for the fixed/hardcoded label?
If you're open to adding support for a custom label (declared in the workflow file) then I'd love to create a PR that does this.

Follow progress on similar feature in GitHub's public roadmap

See github/roadmap#107.

Transient "Error: Input required and not supplied: github_token" issue on pull_request_review?

Hello!

First thanks got the nice project, very useful for simplifying the dev process!

One thing I could not debug successfully so far: we are seeing some "Error: Input required and not supplied: github_token" from time to time. It might be only on the "pull_request_review" events.

Would you have any idea on the root cause? Is there a way to get more debug info?
(run that failed, did not have autosquash label but another label, maybe related to label cloudera/hue#1881, note that we try to use github automerge too)

Run that failed:
https://github.com/cloudera/hue/runs/2122777923?check_suite_focus=true

All runs:
https://github.com/cloudera/hue/actions/workflows/autosquash.yml

Thanks!

Can workflow_run allow the use of GITHUB_TOKEN?

Hi, I was wondering if the new workflow_run (https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run) can be used to (reverse-)trigger one workflow from another, thus allowing the use of secrets.GITHUB_TOKEN.

Cryptic "##[error]Validation Failed" error message

2020-03-02T21:45:04.4057734Z ##[section]Starting: Request a runner to run this job
2020-03-02T21:45:05.0278443Z Requesting a hosted runner in current repository's enterprise with labels: 'ubuntu-18.04', require runner match: True
2020-03-02T21:45:05.1196011Z Labels matched hosted runners has been found, waiting for one of them get assigned for this job.
2020-03-02T21:45:05.1811841Z ##[section]Finishing: Request a runner to run this job
2020-03-02T21:45:11.9129447Z Current runner version: '2.165.2'
2020-03-02T21:45:11.9130479Z Prepare workflow directory
2020-03-02T21:45:11.9305157Z Prepare all required actions
2020-03-02T21:45:11.9314318Z Download action repository 'tibdex/autosquash@v2'
2020-03-02T21:45:13.9503952Z ##[group]Run tibdex/autosquash@v2
2020-03-02T21:45:13.9504410Z with:
2020-03-02T21:45:13.9504792Z   github_token: ***
2020-03-02T21:45:13.9504965Z ##[endgroup]
2020-03-02T21:45:14.5134272Z Merge all pull requests on commit 723fb9d86a8a0daede1ddc73ad6a864ac9b51466
2020-03-02T21:45:14.5136268Z ##[error]Validation Failed
2020-03-02T21:45:14.5182792Z Cleaning up orphan processes

We're trying to set up autosquash in a repository and are getting the above error message. What steps can we take to troubleshoot this failure?

[Question] What's AUTOSQUASH_TOKEN ?

Do I have to name it like that when I create the token? Or should I paste the token plan in the yaml file?

Autosquash not triggered when the PR is validated

I have a personal repository where I mostly use PRs to run tests for me.
Therefore, every time I create a PR, I apply it the autosquash label, to have it merge as soon as tests pass.
Currently, I see that this workflow does not get the PR merged as expected [1]. At the end of all checks, I can remove and set again the label. This time, as previous validations were ok, the action is triggered and the merge occurs.

I know it is not the initial goal of this action, but I can't see why it is not triggered, as it seems to be the purpose of the type "check_run:completed_.

[1] (Kineolyan/snow-hall#7)
[2] (https://github.com/Kineolyan/snow-hall/pull/6/checks?check_run_id=370010823)