Closed robjweiss closed 5 days ago
This pull request is automatically built and testable in CodeSandbox.
To see build info of the built libraries, click here or the icon next to each commit SHA.
Hey @robjweiss , thanks for this. Would you mind removing the scope from your commit message? It's not a valid scope for this project.
@knocte wdyt?
@escapedcat no problem, updated.
Description
The current documentation suggests using
HEAD~n
to go through all PR commits wheren
is the number of commits in the PR. This may not always produce the desired result though, especially if the history is not perfectly linear and there is a complex history of merges.GitHub Actions provides the base sha on the
pull_request
object as well. This should give a revision list in line with the git log and revisions shown on GitHub.Motivation and Context
While using the previous CI workflow, I found that the commits being linted where different from those I was seeing in the PR. After reading a bit about how
~
and^
work with git I came to the conclusion that going~n
will not necessarily point to the same revision as the first commit shown in the PR (merge base), especially if the history is complex.These are my findings. If there's something I've overlooked or you think my conclusions are incorrect, please do let me know!
The original discussion on the GitHub docs seems to come from here: https://github.com/conventional-changelog/commitlint/issues/586.
Usage examples
In a GitHub Action:
How Has This Been Tested?
I compared the commits linted by using each method. The commits linted by the existing method included some not shown in the PR. The commits linted by the new method matched exactly.
Types of changes
Checklist: