Skip to content

Commit 51a559e

Browse files
hangfeicopybara-github
authored andcommitted
chore: Adding PR commit check github workflow
This will fail a PR check if multiple commits are added, and will give the user instructions on how to fix the issue. PiperOrigin-RevId: 776638574
1 parent 1fe9c47 commit 51a559e

File tree

1 file changed

+62
-0
lines changed

1 file changed

+62
-0
lines changed

.github/workflows/pr-commit-check.yml

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
# .github/workflows/pr-commit-check.yml
2+
# This GitHub Action workflow checks if a pull request has more than one commit.
3+
# If it does, it fails the check and instructs the user to squash their commits.
4+
5+
name: 'PR Commit Check'
6+
7+
# This workflow runs on pull request events.
8+
# It's configured to run on any pull request that is opened or synchronized (new commits pushed).
9+
on:
10+
pull_request:
11+
types: [opened, synchronize]
12+
13+
# Defines the jobs that will run as part of the workflow.
14+
jobs:
15+
check-commit-count:
16+
# The type of runner that the job will run on. 'ubuntu-latest' is a good default.
17+
runs-on: ubuntu-latest
18+
19+
# The steps that will be executed as part of the job.
20+
steps:
21+
# Step 1: Check out the code
22+
# This action checks out your repository under $GITHUB_WORKSPACE, so your workflow can access it.
23+
- name: Checkout Code
24+
uses: actions/checkout@v4
25+
with:
26+
# We need to fetch all commits to accurately count them.
27+
# '0' means fetch all history for all branches and tags.
28+
fetch-depth: 0
29+
30+
# Step 2: Count the commits in the pull request
31+
# This step runs a script to get the number of commits in the PR.
32+
- name: Count Commits
33+
id: count_commits
34+
# We use `git rev-list --count` to count the commits.
35+
# ${{ github.event.pull_request.base.sha }} is the commit SHA of the base branch.
36+
# ${{ github.event.pull_request.head.sha }} is the commit SHA of the head branch (the PR branch).
37+
# The '..' syntax gives us the list of commits in the head branch that are not in the base branch.
38+
# The output of the command (the count) is stored in a step output variable named 'count'.
39+
run: |
40+
count=$(git rev-list --count ${{ github.event.pull_request.base.sha }}..${{ github.event.pull_request.head.sha }})
41+
echo "commit_count=$count" >> $GITHUB_OUTPUT
42+
43+
# Step 3: Check if the commit count is greater than 1
44+
# This step uses the output from the previous step to decide whether to pass or fail.
45+
- name: Check Commit Count
46+
# This step only runs if the 'commit_count' output from the 'count_commits' step is greater than 1.
47+
if: steps.count_commits.outputs.commit_count > 1
48+
# If the condition is met, the workflow will exit with a failure status.
49+
run: |
50+
echo "This pull request has ${{ steps.count_commits.outputs.commit_count }} commits."
51+
echo "Please squash them into a single commit before merging."
52+
echo "You can use git rebase -i HEAD~N"
53+
echo "...where N is the number of commits you want to squash together. The PR check conveniently tells you this number! For example, if the check says you have 3 commits, you would run: git rebase -i HEAD~3."
54+
echo "Because you have rewritten the commit history, you must use the --force flag to update the pull request: git push --force"
55+
exit 1
56+
57+
# Step 4: Success message
58+
# This step runs if the commit count is not greater than 1 (i.e., it's 1).
59+
- name: Success
60+
if: steps.count_commits.outputs.commit_count <= 1
61+
run: |
62+
echo "This pull request has a single commit. Great job!"

0 commit comments

Comments
 (0)