amannn / action-semantic-pull-request Goto Github PK

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.

Here is an example PR.

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:

• have explicit option to check if the subject starts with upper case or lower case, something like 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?
• turn action into a more conversational action. So whenever linting is done, publish a successful message or an error as a comment to the PR, so PR's submitter doesn't have to go to check logs.

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

1. Use this action and configure pull_request to be the triggering events.
2. Create a PR from a fork. The check should not work according to the documentation, but it works.

Expected behavior

Updated documentation.

Hi.
It would be really nice if this action could deal with non-conventional commits in PRs.
Thank you.

For some reason, this action gets triggered twice and I can see the same in the Pull requests i this repo as well.
Example #71

@amannn any way to prevent this ?

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?

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?)

Description

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.

Problem Section 🐞

   steps:
      - uses: amannn/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Recommended Change 💡

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.

PR

Commit that landed in main

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?

Same as: https://github.community/t5/GitHub-Actions/Action-showing-up-several-times-in-quot-checks-quot/td-p/40385

If the first check fails, it will always stay there as failed, so I can't make this a required check.

What

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.

Why

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 😅

Example

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.

Success PR:

Title/commit: "docs: changing just docs"
Files changed:
- README.md
- docs/index.md

Failure PR:

Title/commit: "fix: typo in docs"
Files changed:
- docs/index.md

Wrong type for changes in Paths. Should have type of docs:, found fix:

Failure PR:

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:

More changes detected

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.

Caveats

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.

Urgency

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:

1. Leave a comment with all descriptions?
2. Leave a comment with a link to the conventional-commit-types file

I'm wondering why a GITHUB_TOKEN is necessary for this action to work correctly.

Both pull_request and pull_request_target events deliver a payload that contains the current pull request title (src). The full payload is available via the github context under the event property (src).

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.