amannn / action-semantic-pull-request Goto Github PK
View Code? Open in Web Editor NEWA GitHub Action that ensures that your PR title matches the Conventional Commits spec
License: MIT License
A GitHub Action that ensures that your PR title matches the Conventional Commits spec
License: MIT License
Hi! There's a common use-case for squash and merge workflows where you can keep all the PR commit history inside the final squashed commit as a comment. This is very useful for scenarios where we still want to keep a single commit going to trunk, but don't want to lose the development context. So, would you be willing to support linting the commits as well?
Eg: post the expected pattern as a comment
Projects like the GitHub App zeke/semantic-pull-request allow for configuration which lets you control things like the list of commit types that are allowed.
Is your feature request related to a problem? Please describe.
I am using custom regex for allowed types:
headerPattern: '^(feat:|fix:|chore:|refact:|ci:|docs:|\[axof: \d+\]|\[axod: \d+\]) (.*)$'
As I understand I need to list all available types. But some of the types are regexes. The list looks like this:
types: |
feat:
fix:
chore:
refact:
ci:
docs:
[axof: \d+]
[axod: \d+]
The problem is that regexes does not work for types, because types.includes(result.type)
is used for the check.
Describe the solution you'd like
I would want to treat types as regexes:
function isUnknownType(type) {
for (type of types) {
const regex = new RegExp(type);
if (regex.test(result.type)) {
return false;
}
}
return true;
}
...
if (isUnknownType(result.type)) {
raiseError(
`Unknown release type "${
result.type
}" found in pull request title "${prTitle}". \n\n${printAvailableTypes()}`
);
}
I have a working code in forked repository:
https://github.com/amannn/action-semantic-pull-request/compare/main...sidlatau:regex-title?expand=1
Would it be possible/useful for others to add such functionality in this action? Or maybe there is an other way how to do it without code changes?
I have been using this action for many of my companies projects and really enjoy it! Specifically we have been using the example repo that adds a comment if the message does not comply and removes it if it does. However, the past few days it has begun to leave comments on all PRs, with empty bodies that look like this:
Regardless of whether the title matches the spec or not. Has anyone else run into this?
This is my workflow:
jobs:
Lint-title:
name: Validate PR title
runs-on: ubuntu-latest
steps:
- uses: amannn/action-semantic-pull-request@v4
id: lint_pr_title
with:
ignoreLabels: |
bot
ignore-semantic-pull-request
dependencies
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- uses: marocchino/sticky-pull-request-comment@v2
# When the previous steps fails, the workflow would stop. By adding this
# condition you can continue the execution with the populated error message.
if: always()
with:
header: pr-title-lint-error
message: |
Hey there and thank you for opening this pull request! ๐๐ผ
We require pull request titles to follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/) and it looks like your proposed title needs to be adjusted.
Details:
```
${{ steps.lint_pr_title.outputs.error_message }}
```
# Delete a previous comment when the issue has been resolved
- if: ${{ steps.lint_pr_title.outputs.error_message == null }}
uses: marocchino/sticky-pull-request-comment@v2
with:
header: pr-title-lint-error
delete: true
Due to a missing condition before the error is thrown
I'm the author of a public npm package called cross-fetch. Every time a push is made on the main
branch, the CI workflow is triggered. If the commit starts with chore(release)
, this is the signal for CI to publish a release on npm and Github after all building, testing and linting is done. However if someone opens a PR with a title that starts with chore(release)
, I'm not seeing a way to avoid the release. Would the maintainers consider adding a disallowedScopes
config so users could avoid scopes such as release
?
A commit message such as feat: Hello world.
passes this GitHub Action. However the Angular convention that Conventional Commits is based on states:
The subject contains a succinct description of the change:
use the imperative, present tense: "change" not "changed" nor "changes"
don't capitalize the first letter
no dot (.) at the end
I'm aware that Conventional Commits isn't as strict, but I see no reason to allow for variations of this kind since they undermine the goal of consistent commits.
We are using semantic-release and have as well some custom types. It would be great if the action could as well read (e.g., .releaserc.json
) from the project and use the same rules/configuration.
Recently I'm trying to replace Semantic Pull Requests with action-semantic-pull-request
, Semantic Pull Requests has config like allowRevertCommits
, but I don't know how use action-semantic-pull-request
to achieve the same effect, I hope action-semantic-pull-request
to support tile like: Revert "feat(xxx): xxx"
.
First all, thanks for making this action!
I noticed an issue where if there are two commits, one of them being a merge commit, GitHub uses the non-merge commit's message when squashing/merging the PR. We have validateSingleCommit
enabled, but the action sees that scenario as two commits so it checks the PR title instead of commit message.
And here is the commit after squashing/merging.
It ended up using the first commit's message instead of the PR title. However the action assumed it would use the PR title. Here is our workflow file.
Hey, I was wondering if you consider the following improvements to this action:
subjectUppercase
. Regex is fine but not readable out of the box for everybody. It would be great to throw clear info to the user that the subject should start with an upper case or lower case. What do you think?I'm wondering what do you think about it
It would be nice if this action would also add a comment to the pull request directly. Here is an example for how that could look like:
The message should - of course - be configurable via an input option.
Implementing this is pretty straightforward:
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: "Please make the title of this Pull Request follow the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) format ๐"
})
I've arrived to this repo from: https://github.com/zeke/semantic-pull-requests
As we are using GHE maybe we cannot use an app, but action looks great.
But, we use some tags that are not the ones defined on this action: Feature
, Fix
, Tech`...
Is possible to add the ability to allow tag customization?
Describe the bug
From the pull_request
section in Event triggers:
If this configuration is used and a pull request from a fork is opened, you'll encounter an error as the GitHub token environment parameter is not available.
However, according to Github documentation, the main difference between pull_request_target
and pull_request
is that the former also gives write permissions, which does not seem to be required by action-semantic-pull-request
.
Furthermore, a run triggered from a fork did finish successfully even though it's pull_request
instead of pull_reuqest_target
in the corresponding workflow file.
As a result, the documentation may be outdated.
To reproduce
pull_request
to be the triggering events.Expected behavior
Updated documentation.
Hi.
It would be really nice if this action could deal with non-conventional commits in PRs.
Thank you.
For version 3.4.3 with Renovatebot PR title equal to
chore(deps): update amannn/action-semantic-pull-request action to v3.4.3
the following error is shown
Error: Cannot read property 'startsWith' of undefined
When I use this action in a private repository I receive the following error: "Resource not accessible by integration"... I tried to add permissions (but that doesn't help much):
jobs:
main:
permissions:
statuses: write
it is also impossible from error to say which operation particularly fails. Thoughts?
Currently we can limit the valid commit "types". It would also be nice if we could limit the list of valid "scopes".
Hello,
Currently all the Pull Request done from a fork fail my job using this github action because it is not possible to have access to the Github Token I have set for my repo from their fork (which is a good thing from a security stand point).
I wonder if it could be possible to get rid of this github token usage ?
I have looked at some other github action doing similar thing and it seems not all of them requires this token
Exemple here
Happy to help if needed to make this working
I did not investigate in details yet but I'm sure something is wrong.
I have the following workflow https://github.com/derberg/test-experiment/blob/master/.github/workflows/testtest.yml
and it fails no matter if derberg/test-experiment#67 is ci: Test test
or ci: test test
I see this action uses pull_request_target
to work on public forks. Have you seen this warning in the GitHub Docs, Events that trigger workflows pull_request_target
?
Warning: For workflows that are triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission unless the permissions key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see "Keeping your GitHub Actions and workflows secure: Preventing pwn requests" on the GitHub Security Lab website.
It might be good to mention this warning in the README.md
as well?
action-semantic-pull-request/src/index.js
Line 42 in fc71bda
Shouldn't the action update the status on the repository where the action was run?
Hi! what permissions does GITHUB_TOKEN require?
I have a simple test repo where I am exploring usage of this action. I created a branch on this repo, added some text to a markdown file, and pushed up a commit with an invalid message. The resulting PR reports a status like:
I have a .github/workflows/pr-commit-lint.yml
file that looks like:
name: 'Lint Commit Messages'
on:
pull_request_target:
types:
- opened
- edited
- synchronize
jobs:
main:
runs-on: ubuntu-latest
steps:
- uses: amannn/[email protected]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Is this expected behavior?
Hi,
this action currently shows a simple Successful
message when the PR title was successfully validated like so:
However, I think GitHub API would allow us to show more information and we could actually indicate what type of change this PR title will lead to. So for example, when using a PR title feat: foo
, the check could say Successful: New Feature
.
Once that works, it would also be handy to look at PR descriptions and look for BREAKING CHANGES
. I know the README says it only looks the PR title, but why not look at the description?
The problem is that semantic-release does not support the exclamation mark. It would be nice if this action worked well with semantic release :)
Check does not fail when PR Title looks like: feat: Add something
but it should fail, semantic release does not allow it. This is only valid for the first letter after feat:
After that it does not matter if there is a upper-case letter.
Run wagoid/commitlint-github-action@v2
8
/usr/bin/docker run --name wagoidcommitlintgithubaction216_474391 --label cc4956 --workdir /github/workspace --rm -e INPUT_CONFIGFILE -e INPUT_FIRSTPARENT -e INPUT_FAILONWARNINGS -e INPUT_HELPURL -e INPUT_TOKEN -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/VivumLab/VivumLab":"/github/workspace" wagoid/commitlint-github-action:2.1.6
9
::stop-commands::3ee5cac1-f660-4061-86b6-5883ca3b608a
10
::error::You have commit messages with errors%0A%0Aโง input: chore: Work in Progress action revert (#254)%0A%0ASigned-off-by: Denis Evers <[email protected]%0Aโ subject must not be sentence-case, start-case, pascal-case, upper-case [subject-case]%0A%0Aโ found 1 problems, 0 warnings%0Aโ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint%0A
11
::3ee5cac1-f660-4061-86b6-5883ca3b608a::
Hey all,
We have some scopes with whitespace like new source
but this action appears to be treating those as two separate scopes (I'm guessing it is just splitting on whitespace). Would it make sense to only split on newlines?
This is related to #203 where I suggest making scopes
and types
actual lists which would also avoid this issue.
I saw there are more and more larger companies showing up in the dependents list. I'd be really curious if there are further companies using it for closed source work and also if you'd be interested in being featured in the README?
This action is really great and covers most of the cases we need, but unfortunately we have slightly different format than "conventional commits". (Our format looks like [ADD] New feature
)
To solve this, it would be great to have option to specify custom regex that validates the whole title, completely replacing the conventional commits parser
Error info:
amannn/[email protected] is not allowed to be used in apache/incubator-pegasus. Actions in this workflow must be: created by GitHub, verified in the GitHub Marketplace, within a repository owned by apache or match the following: apache/, dawidd6/action-download-artifact@, gradle/wrapper-validation-action@, peaceiris/actions-gh-pages@, peaceiris/actions-hugo@, peter-evans/create-pull-request@, scacap/action-surefire-report@, shivammathur/setup-php@, conda-incubator/setup-miniconda@*.
The "v5" tag was not / has not been moved to release tags 5.0.1 and 5.0.2. We reference the a action by @v5
but that tag still references the 5.0.0 release @amannn @tisonkun @martinm82 @martinmigasiewicz-tomtom
Please consider adding a license file to the project (MIT to match semantic-release?)
Hey there!
Looks like the README for this project is referencing an older release of the action. The version 3.1.0 appears to not support the subjectPatternError:
field and logs a warning. So it's possible users might be copy and pasting your example and then getting confused when the subjectPatternError:
doesn't work.
steps:
- uses: amannn/[email protected]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Could either update it to the latest version
@v3.4.0
or put@master
to automatically
stay valid for folks as you push new releases.
steps:
- uses: amannn/[email protected]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Hey all,
We'd like to have comments around our lists of types and scopes but because they are YAML scalars, this isn't possible. For example, we'd like to write:
with:
types: |
chore # An internal change this is not observable by users.
enhancement # Any user observable enhancement to an existing feature.
But the comments are included in the scalar.
Ideally we could provide the types and scopes as actual lists like:
with:
types: |
- chore # An internal change this is not observable by users.
- enhancement # Any user observable enhancement to an existing feature.
Is there a reason the types and scopes are newline delimited strings rather than being YAML lists? Would you be open to a (breaking) PR changing that?
Hi team,
I have a problem and need some help :-)
Event: The second check will make the GitHub action always in the pending state.
As you can see, in this case, we can't tell whether the action was triggered because of the commit just push or PR title action check fail.
Is there any way we can make PRs (without WIP prefix) ignore the second check.
Best regards!
Similar to #86 but simply checking for commitLength > 1
doesn't seem sufficient any longer. This is because if you have a merge commit (update branch to latest e.g.) then you have a single commit + 1 merge commit so the length check passes. But Github still ignores the merge commit and treats it as a single commit PR. Could be a recent change in Github's behavior.
Hi, is there any way to handle multiple scopes, comma seperated?
My desired goal is to either have the validation by default, or to configure regex to pass such title:
feat(core, ui, cdk, ...): do this
Maybe it would be nice to add a multipleScopes
flag to the configuration:
with:
...
multipleScopes: true
...
Hey @amannn I noticed there's a new feature to support a [WIP] prefix: #3
Did you consider GitHub's draft pull requests feature? Instead of using that WIP prefix, this Action could check whether or not the PR is a draft and react accordingly.
Hello @amannn, I really liked your development, but I can't use it at the moment, because I didn't find a parameter thanks to which I could configure the use of this type of commit header: ๐ tag(scope): description
.
I use semantic commit in my repository, with a slightly modernized RegExp expression: /^(?:(?:\u00a9|\u00ae|[\u2000-\u3300]|\ud83c[\ud000-\udfff]|\ud83d[\ud000-\udfff]|\ud83e[\ud000-\udfff]) (\w*))(?:\(([\w\$\.\-\* ]*)\))?\: (.*)$/
Maybe I'm missing something, and there is already such an opportunity?
If the first check fails, it will always stay there as failed, so I can't make this a required check.
I would like to configure and assert errors of specific types/scopes to code changes in the PR diff.
For instance, if I have a PR with docs:
as the type/scope I want to ensure this is only applied when the PR contains changes only to the documentation, that is, a list of files or dirs.
Users will create PRs with fix:
type, but really they're updating some CI, Tests or Docs which should be captured under ci:
, tests:
or docs:
types. This is important with Changelogs generated from semantic commits, helping stop erroneous Changelog entries. It would be useful to assert these types of requirements to remove human error when approving PRs with incorrect semantic types. I often make mistakes when reviewing simple PRs, only noticing my mistakes afterwards ๐
An example of what this would look like in configuration:
name: Lint PR
on:
pull_request_target:
types:
- opened
- edited
- synchronize
jobs:
semantic-pr:
runs-on: ubuntu-latest
steps:
- uses: amannn/[email protected]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
validateSingleCommit: true
typeWhenOnlyPaths:
- docs:
- docs/*
- README.md
- ci:
- .github/*
- tests:
- tests/*
So from this config, PRs with changes only in docs/*
or README.md
can then only have the docs:
type applied. If it has a different type it errors, or if it has changes in the specified paths and elsewhere it is up to the Reviewer to validate the semantic type.
Title/commit: "docs: changing just docs"
Files changed:
- README.md
- docs/index.md
Title/commit: "fix: typo in docs"
Files changed:
- docs/index.md
Wrong type
for changes in Paths. Should have type
of docs:
, found fix:
Title/commit: "fix: typo in ci pipeline"
Files changed:
- .github/workflows/test.yml
Wrong type
for changes in Paths. Should have Type of ci:
, found fix:
If changes occur in more than one of the typeWhenOnlyPaths
then the rules are ignored, they only apply when ONLY those paths are present.
Success PR:
Title/commit: "fix: typo in ci pipeline"
Files changed:
- .github/workflows/test.yml
- docs/index.md
No rules under typeWhenOnlyPaths
match, so the fix:
type cannot be asserted by this configuration. Now we must rely on humans.
This is useful for avoiding simple issues, but doesn't help classify changes to multiple areas of the code at once. More complex changes generally must be reviewed more thoroughly, so complex changes aren't subject to the same simple errors I would like to capture with this type of feature.
Nice to have.
Thanks for the great GitHub Action ๐
@amannn Hello, thank you for developing this useful project!
Is it possible to provide major version tags (v1, v2, v3, ...) as well? I think it's automatically done by using this action.
https://github.com/Actions-R-Us/actions-tagger
Thank you.
Would you be open to have a configurable array of tags for which, when found in PR, verification is skipped?
The changes done by @kenji-miyake in #158 are a great addition, but I think they should be configurable through a flag/setting.
I have a few bot-created pull requests where the single commit message has more info that should stay there, but it's not important for the PR reviewer, so in this case I would like to keep the title simple but the commit message should still have more advanced info inside.
Here is an example: keptn/keptn#6789
When people are learning about conventional commits, they might not know all of the available options.
What might be really useful is that if there's a failure to match a conventional commit, to some how surface the list that's being checked against.
Some random ideas:
I understand the scope of this action relates only to PR titles and there are alternatives for those wishing to lint commit messages in general. However, I wonder if you'd consider an optional extra validation step for PRs with only one commit.
When squashing and merging these PRs, GitHub suggests the commit message instead of the PR title, and if you aren't careful the PR will be merged without a conventional commit causing semantic release to ignore it.
I'm happy to put in a PR for this as I'd use it at work.
My suggestion would be an extra boolean configuration option validateSingleCommit
. If the PR title passes validation and validateSingleCommit
is true, we get the list of commits and pass if length > 1
. Otherwise validate the commit message.
Noticed this in our logs with v2.1.0
[@octokit/rest] `const Octokit = require("@octokit/rest")` is deprecated. Use `const { Octokit } = require("@octokit/rest")` instead
I don't see this being directly anywhere in the src
so probably coming from a dependency.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.