compilerla / conventional-pre-commit Goto Github PK

[INFO] Installing environment for https://github.com/compilerla/conventional-pre-commit.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
An unexpected error has occurred: AssertionError: BUG: expected environment for python to be healthy immediately after install, please open an issue describing your environment

more info:

pyvenv.cfg does not exist (old virtualenv?)Check the log at /home/ec2-user/.cache/pre-commit/pre-commit.log

version information

pre-commit version: 2.20.0
git --version: git version 2.40.1
sys.version:
    3.7.16 (default, Mar 10 2023, 03:25:26) 
    [GCC 7.3.1 20180712 (Red Hat 7.3.1-15)]
sys.executable: /usr/bin/python3
os.name: posix
sys.platform: linux

error information

An unexpected error has occurred: AssertionError: BUG: expected environment for python to be healthy immediately after install, please open an issue describing your environment

The conventional commit specification states if a body is included in the commit message there must be a blank line separating the title and the body, see point six in the docs.

I will attempt to put a PR together to provide a solution.

Hey! Thank you for this hook. I saw that you have a typo in one of your topics: convetional-commits is missing an n.

In my CI I need to include cases as feat!: message, fix!: some messsage would be possible to add extra types instead of listing all then in the args list?

I would like to suggest adding an option for checking if description does not end with a period (full stop, .). Although not explicitly stated in spec, <description> in all examples has this property and (as far as I can tell) this is a rule followed by many users of conventional commits.

Possible approaches might be --force-no-period (more reasonable) or as part of --strict.

Hello,

I try to set hook but it's doesn't detect commit prefix :/

.pre-commit.config.yaml :

minimum_pre_commit_version: 3.6.0
fail_fast: true
repos:

  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace # Trims trailing whitespace
        stages: [pre-commit]
      - id: check-yaml # Validates YAML files
        stages: [pre-commit]
        exclude: ^src/docapi/.*|^tests/templates/.*|^src/templates/.*|
      - id: check-json # Validates JSON files
        stages: [pre-commit]
        exclude: ^src/docapi/.*|^tests/templates/.*|^src/templates/.*|
      - id: check-added-large-files # Checks for files that are added to the repository that are larger than a threshold
        stages: [pre-commit]
      - id: check-case-conflict # Checks for files that would conflict in case-insensitive filesystems
        stages: [pre-commit]
      - id: check-merge-conflict # Checks for files that contain merge conflict strings
        stages: [pre-commit]
      - id: detect-private-key # Check for the existence of private keys
        stages: [pre-commit]
      - id: check-executables-have-shebangs # Checks that executables have shebangs
        stages: [pre-commit]
      - id: end-of-file-fixer  # Makes sure files end in a newline and only a newline
        stages: [pre-commit]

  - repo: local
    hooks:
      - id: flake8
        stages: [pre-commit]
        name: flake8
        always_run: true
        entry: bash -c 'make flake8'
        language: system
        types: [python]
        pass_filenames: false

      - id: black
        stages: [pre-commit]
        name: black
        always_run: true
        entry: bash -c 'make black'
        language: system
        types: [python]
        pass_filenames: false

      - id: pylint
        stages: [pre-commit]
        name: pylint
        always_run: true
        entry: bash -c 'make pylint'
        language: system
        types: [python]
        pass_filenames: false

  - repo: https://github.com/compilerla/conventional-pre-commit
    rev: v3.1.0
    hooks:
      - id: conventional-pre-commit
        stages: [commit-msg]
        args: [--strict, --force-scope, core, build, chore, ci, docs, feat, fix, perf, style, refactor, test]

Result with command : git add --all; git commit -m "fix: test"

Pre-Commit version : 3.6.1

Current bash script only works for system with grep which understands perl regex (switch -P)

grep (GNU grep) vs grep (BSD grep)

Maybe switch to egrep patterns?

There seems to be a problem if the commit message contains any mark signs like ", ', backtick, etc. I guess those signs should be allowed.

[EDIT] To offer an solution I think line 27 should be:

r_subject=" [[:print:]].+"

With #21 and #22 we will publish a new tag v1.4.0

When the --verbose argument is used during commit, an exception occurs. The command git commit --verbose shows a DIFF of the changes being committed. The diff is separated from the commit message through the following few lines.

# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.

I assume this case isn't included appropriately when parsing the commit message for valid use of conventions.

Reproducible with git commit with --verbose argument committing unsuccessful, and without argument successful.

Hi, I love the pre-commit hook.

I have one small issue with it though. It rejects fixup / squash commits.

fixup / squash / amend commits are only intended for local development, but allow you to amend a commit further in the past than your current HEAD and can be trivially processed using. git rebase --autosquash. This is a really handy feature of git, but it will create commits of the following pattern:

fixup! Commit message of the old commit to apply the change to

squash! Commit message of the old commit to apply the change to

amend! Commit message of the old commit to apply the change to

Obviously, these are rejected by the pre-commit hook. Yet it would be nice if there would at least be an option to allow them until you push

Hi!

I read carefully through the previous discussion about the subject and decided to raise the matter again. Strictly following conventional commits is a good thing, but during the code review process you might be using "fixup!" commits to make the process simpler for the reviewer. It means that --no-verify is not an option anymore. And when I'm adding "fixup" to the "args" list it still requires ":".

In light of this, it'd be nice to have an option like this or similar:

    hooks:
      - id: conventional-pre-commit
        stages: [commit-msg]
        args: []
        allow-fixup-commits: true

It should be easy to use a simple regexp like this ^(fixup! +) to check it or even a method like startswith.

I've just worked myself through a question how to best integrate the checks into a ci pipeline. Would like to share my experience from the approach and also trigger a question if it's possible to implement support for such use cases.

In our team the context is as follows:

• We work locally and some have the checks based on pre-commit also enabled locally.
• Then work is pushed into a branch and a Merge Request / Pull Request is opened based on the branch.
• On this Merge Request we wanted to trigger the same linting checks, so that we never have to worry about commit message structure, even if a colleague decided to not enable pre-commit locally. Latest on the Merge Request the automated feedback would be available.

While building this (in our case based on gitlab ci) I found it a particular challenge that I need to extract every commit message manually and then run pre-commit to have the message checked. I've reached a working state for us, and still I wonder if it wouldn't be a good improvement to be able to run a check by passing the hashes of a starting and ending commit.

As pseudo code it could look something like the following:

pre-commit --from-ref=XY --tro-ref=YZ --hook-stage=commit-msg

The below example shows how I've done it currently and probably helps to understand how I got to the question/suggestion:

      any_failure=0
      tmp_file="$(mktemp --tmpdir=.)"
      for x in $(git log --format="%H" "${CI_MERGE_REQUEST_DIFF_BASE_SHA}..${CI_COMMIT_SHA}")
      do
          echo "Checking commit message for $x"
          git log --format="%B" -n 1 "$x" > "$tmp_file"
          pre-commit run --hook-stage=commit-msg --commit-msg-filename="$tmp_file" \
              conventional-pre-commit || any_failure=1
      done
      rm "$tmp_file"
      if [ "$any_failure" -ne 0 ]
      then
          exit 1
      fi

Hi,
could you add the colon to "r_scope()" method to be a valid sign?

The colon could be used as a separator for a module chain. (Some kind of parent -> child relation)
Ex.: feat(parent:child)

Or even better: Could you make it configurable? (Inside the ".pre-commit-config.yaml" file)

Greetings

• Version bump
• Tagging
• Release notes

Hello, is there a way to enable merge commits? Mine start with "Merge branch 'master'..."

Hi, I wonder how hook should be configured to be run with pre-commit run --all-files command, so I could utilize it with CI. Seems that default stage [commit-msg] doesn't work in that case, and when I experimented a little with different stages configuration, hook started validating commited files body :/. Any ideas how this issue could be solved? Thanks in advance

In #68 there's now a check for an extra blank line. Given the wording in the release notes and in the output message if you fail the check I more read this as you need a blank line if you have a body:

Conventional Commits start with one of the below types, followed by a colon, followed by the commit subject and an optional body seperated by a blank line:

I require a blank line even if I don't supply a body.

I think there are a few possibilities here:

• This was unintentional and we need to fix
• This was intentional and I feel the messaging could be a bit clearer

If the 2nd one, what do you think about drawing more attention to it in the program? Can it be made bold or surrounded by *** or something to draw attention to it for a few versions and then special messaging can be deprecated?

I suggest this yaml:

repos:
  - repo: local
    hooks:
      - id: conventional-pre-commit
        name: Conventional Commit (local)
        entry: bash conventional-pre-commit.sh
        language: system
        stages: [commit-msg]

With this it won't be necessary to make the shell-script executable.

Sometimes it is convenient to specify multiple scopes in a commit message e.g. feat(pkg1,pkg2): add some feature.

Current behaviour with v3.0.0

The following command is raising an error:

git commit -m "feat(pkg1,pkg2): add new feature"

[Bad Commit message] >> feat(pkg1,pkg2): add new feature

        Your commit message does not follow Conventional Commits formatting
        https://www.conventionalcommits.org/

        Conventional Commits start with one of the below types, followed by a colon,
        followed by the commit subject and an optional body seperated by a blank line:

            ci build docs feat fix perf refactor style test EXP

        Example commit message adding a feature:

            feat: implement new API

        Example commit message fixing an issue:

            fix: remove infinite loop

        Example commit with scope in parentheses after the type for more context:

            fix(account): remove infinite loop

        Example commit with a body:

            fix: remove infinite loop

            Additional information on the issue caused by the infinite loop

Expected behaviour

If the scopes are comma separated, the commit message should be considered as valid ✅

This is something supported by other tools to validate commit message e.g. conventional-changelog/commitlint#901

Standard way am doing using hook like that:

Hello, I have discovered by reading the code that the colours codes are used unconditionnally. In the case where the output is piped to a process, those colour code might make the output less easy to read.

It would be nice to either provide a command-line argument to disable the colours and/or use a validation method that ensures that stdout is an actual terminal which supports colours codes.

When running pre-commit autoupdate the rev is first updated from whatever tag to v1 (even from v1.2.0 which is the same commit). Latter autoupdate runs produce the following warning:

[WARNING] The 'rev' field of repo 'https://github.com/compilerla/conventional-pre-commit' appears to be a mutable reference (moving tag / branch).  Mutable references are never updated after first install and are not supported.  See https://pre-commit.com/#using-the-latest-version-for-a-repository for more details.  Hint: `pre-commit autoupdate` often fixes this.

Thanks for the useful hook!

You might consider adding it to https://pre-commit.com/hooks.html so that it is easier for others to discover.

Hi,
Thanks for this nice piece of code !

I plan to use it in my organization, but we already use git flow to manage our branching model.
And when git flow merge a branch, the message is:
"Merge branch 'feature/xxx' into develop"
I would like to add a command line option to allow user to define one or many regex.
If the message match one of the regex, it will be accepted, even if it don’t respect conventionnal commit.

Thought ?

This would follow pre-commit recommended best-practice, to take full advantage of the framework and reduce (remove) external dependencies.

From pre-commit/pre-commit.com#691

it appears to require a modern bash as well as grep -- it would be better if implemented in python -- or really the whole script can be replaced with a pygrep regex

Tangentially related to #16 but that approach would have also been not as "best-practice".

Something like Merge branch .* into .* should still ok or am I mistaken?