cocogitto / cocogitto-action

A github action to ensure your current gitlog respect the conventional commit specification

Cocogitto github action

This action uses cocogitto to check your repository is conventional commit and perform auto-release.

Requirement

1. Before running this action you need to call checkout action with fetch-depth: 0. This is mandatory, otherwise not all commit will be fetched and cocogitto will fail to execute (see actions/checkout for more info).

2. Cocogitto assumes you are running on a x86 linux runner.

Example

on: [push]

jobs:
  cog_check_job:
    runs-on: ubuntu-latest
    name: check conventional commit compliance
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Conventional commit check
        uses: cocogitto/cocogitto-action@v3

If you are running your workflow on: [pull_request], additional setup for actions/checkout is needed to checkout the right commit:

on: [pull_request]

jobs:
  cog_check_job:
    runs-on: ubuntu-latest
    name: check conventional commit compliance
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          # pick the pr HEAD instead of the merge commit
          ref: ${{ github.event.pull_request.head.sha }}

      - name: Conventional commit check
        uses: cocogitto/cocogitto-action@v3

If you are familiar with cocogitto this will run cog check and nothing else.

Check commits since latest tag

In some case you might want to perform check only since the latest tagged version. If your repository has not always been conventional commits compliant, then you probably want to use this option.

      - name: Conventional commit check
        uses: cocogitto/cocogitto-action@v3
        with:
          check-latest-tag-only: true

Let us assume the following git history :

* 9b609bc - (HEAD -> main) WIP: feat unfinished work
* d832ca4 - feat: working on feature A
* d5ce110 - (tag: 0.1.0) chore: release 0.1.0
* 8f25a4b - chore: a commit before tag 0.1.0

Using check-latest-tag-only: true here would make cocogitto check for the two commits made since tag 0.1.0, the action would fail on HEAD which contains the non-conventional commit type 'WIP'.

Performing release

You can also use this action to perform releases (calling cog bump --auto under the hood) (see: cocogitto's auto bump).

      - name: Semver release
        uses: cocogitto/cocogitto-action@v3
        id: release
        with:
          release: true
          git-user: 'Cog Bot'
          git-user-email: '[email protected]'

      # The version number is accessible as a github action output
      - name: Print version
        run: "echo '${{ steps.release.outputs.version }}'"

Note that you probably want to set the git-user and git-user-email options to override the default the git signature for the release commit. If you are not familiar with how cocogitto perform release, you might want to read the auto bump and hook sections on cocogitto's documentation.

Post step run

Once the step is finished cocogitto's binary will be available in your path.

Reference

Here are all the inputs available through with:

Input	Description	Default
check	Check conventional commit compliance with cog check	true
check-latest-tag-only	Check conventional commit compliance with cog check --from-latest-tag	false
release	Perform a release using cog bump --auto	false
git-user	Set the git user.name to use for the release commit	cog-bot
git-user-email	Set the git user.email to use for the release commit	[email protected]

cocogitto-action's Issues

[BUG] Action releases not properly tagged

Describe the bug

Cocogitto action releases are not properly tagged. When targeting v3 you get v3.0 release only which is from March 2022. To get updates, you have to target main which means you may get breaking changes.

To Reproduce
Steps to reproduce the behavior:

• Use cocogitto/cocogitto-action@v3 in your workflow
• You will get the version from March 2022

Expected behavior

I expect when v3.5 is released v3 tag is updated to point to v3.5.

Additional context

For example, actions/checkout updates older tags so when there are minor or patch releases, the users of the actions get those features and fixes. See the tags here

[BUG] - Windows self-hosted runner fails to install

Describe the bug
When attempting to use cocogitto on a self-hosted windows runner, the action will fail with the following error:

D:\GitHub\actions-runner_work_temp\3d7451bb-1855-4c7f-935b-ac2973a0bff8.sh: line 1: D:GitHubactions-runner_work_actionscocogittococogitto-actionv3.5/install.sh: No such file or directory
Error: Process completed with exit code 127.

I noticed that the path to my install.sh is missing all of the directory separators ()
D:GitHubactions-runner_work_actionscocogittococogitto-actionv3.5/install.sh --> D:\GitHub\actions-runner_work_actions\cocogitto\cocogitto-action\v3.5/install.sh

I tried looking into the issue and found the following:
The error you’re encountering seems to be related to the way paths are handled in Windows. In Unix-based systems like Linux or MacOS, paths are typically defined with forward slashes (/), while in Windows, paths are typically defined with backslashes ().

The error message suggests that the backslashes () in the path are being removed, which is a common issue when scripts written for Unix-based systems are run on Windows. This is because the backslash () is an escape character in Unix-based systems, so it’s often removed or treated differently.

To Reproduce

1. Create a windows-based self-hosted runner.
2. In a project, have a github workflow that has the following:
   runs-on:
   • self-hosted
   • windows
3. Create a workflow that you can run with at least these steps.

   • uses: actions/checkout@v3
     with:
     fetch-depth: 0 // aka ∞

   • name: Validate commits
     uses: cocogitto/[email protected]
     with:
     check-latest-tag-only: true

4. Attempt to run workflow.

Expected behavior
Cocogitto runs.

Additional context
D:\GitHub\actions-runner_work_actions\cocogitto\cocogitto-action\v3.5 does exist on the self-hosted runner.
The install.sh script located there indicates that it is not targeting windows, as the cocogitto references unknown-linux.

#!/bin/sh

CUR_DIR=$(pwd)
VERSION=5.4.0
TAR="cocogitto-$VERSION-x86_64-unknown-linux-musl.tar.gz"
BIN_DIR="$HOME/.local/bin"

mkdir -p "$BIN_DIR"
cd "$BIN_DIR" || exit
curl -OL https://github.com/cocogitto/cocogitto/releases/download/"$VERSION"/"$TAR"
tar xfz $TAR
cd "$CUR_DIR" || exit

I would expect this to be cocogitto-6.0.1-x86_64-pc-windows-msvc.tar.gz if I am understanding how the install system works on self-hosted runners.

[BUG] Parse error: expected commit_type

In the latest version of the action in "main" branch, we started getting a parse error. Even though the commits comply to the conventional commit standards

Checking all commits
No errored commits

Error: Parse error

Caused by:
     --> 1:1
      |
    1 | 
      | ^---
      |
      = expected commit_type

To Reproduce

Steps to reproduce the behavior:

• Create a commit that comply to the conventional commit standards
• Ensure the action is run with no parameters (all default values)

on: push
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: cocogitto/cocogitto-action@main

Expected behavior

Action should pass the checks with no errors.

Additional context

It seems to have been caused by #10

[BUG] Cocogitto-action crash on cocogitto 5.6.0 config file

Hi everyone,

I installed cocogitto 5.6.0 and did a cog init in my project.
Here the generated file :

from_latest_tag = false
ignore_merge_commits = false
generate_mono_repository_global_tag = true
branch_whitelist = []
skip_untracked = false
pre_bump_hooks = []
post_bump_hooks = []
pre_package_bump_hooks = []
post_package_bump_hooks = []

[git_hooks]

[commit_types]

[changelog]
path = "CHANGELOG.md"
authors = []

[bump_profiles]

[packages]

And now my github action is crashing with the following error:

Setting git user : cog-bot
Settings git user email [email protected]
Error: failed to parse config

    cause unknown field `skip_untracked`, expected one of `ignore_merge_commits`, `branch_whitelist`, `tag_prefix`, `pre_bump_hooks`, `post_bump_hooks`, `commit_types`, `changelog`, `bump_profiles`

Error: Process completed with exit code 1.

I suggest that cocogitto-action must ignore the new field or be updated to use cocogitto 5.6.0 😄

[FEATURE] Automatically generate changelog content for a github release

For one of my projects I have configured a custom release action that, on new version tag creation, generates a cocogitto changelog and then creates a github release with that changelog.

Maybe it would be useful to have something like this incorporated here?

EDIT: the action, for reference

[FEATURE] Allow Specifying whether to do a Major, Minor or Auto Bump

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

No problem, just an enhancement.

Describe the solution you'd like
A clear and concise description of what you want to happen.

I would like to specify whether the release should trigger a major, minor or automatic version bump. This can be useful when I'm working on an early version of my app, and then want to trigger a 1.x release or 2.x release based on an overhaul that might not have breaking changes but a refreshed UI or so.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Manually running the Cocogitto commands with the Docker image and having different steps based on variables.

Additional context
Add any other context or screenshots about the feature request here.

[BUG] Fails to check from latest tag

Describe the bug
check-latest-tag-only does not seem to work under certain conditions.
Trying to use the action in a repository that has non-compliant commits until including the latest tag results in it actually checking the wrong i.e. almost-all revisions.

To Reproduce

$ cd $(mktemp -d)
$ git init
$ git commit --allow-empty -m 'Non-compliant 1'
$ git commit --allow-empty -m 'Non-compliant 2'
$ git tag -a tag -m 'tag'
$ git checkout -b branch
$ git commit --allow-empty -m 'chore: Compliant 1'
$ git checkout --force $(git rev-parse HEAD)
$ git rev-list --max-parents=0 HEAD
xyz
$ git rev-parse HEAD^1
abc
$ git log --oneline
def (HEAD, branch) chore: Compliant 1
abc (tag: tag, main) Non-compliant 2
xyz Non-compliant 1
$ cog check --from-latest-tag
Found 1 non compliant commits in xyz..HEAD

Errored commit: abc <robot9001>
        Commit message: 'Non-compliant 2'
$ cog check tag..HEAD
No errored commits

Action log:

Checking commits from tag
Error: 
Found 1 non compliant commits in xyz..HEAD:

Errored commit: abc <robot9001>
	Commit message: 'Non-compliant 2'

Expected behavior
I expected the action to successfully check the single compliant commit after the latest tag.
I also expected the action / the cog CLI binary to (debug) log the revisions it is actually using.

I'm filing this issue against the action instead of the binary, since the action's cog.sh seems to log a revision range (tag..HEAD) that the binary does not actually (log and) use (xyz..HEAD), so both likely need to be fixed.

Additional context

permissions:
    contents: read

on:
    pull_request:
        branches: [ main ]

jobs:
    check-commits:
        # https://github.com/cocogitto/cocogitto-action
        runs-on: ubuntu-latest
        name: check conventional commit compliance
        steps:
            - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0
              with:
                fetch-depth: 0
                # pick the pr HEAD instead of the merge commit
                ref: ${{ github.event.pull_request.head.sha }}

            - name: Conventional commits check
              uses: oknozor/cocogitto-action@ac6260150ee57e3164cd95b47fc84cdee9e3444c # v3.5
              with:
                check-latest-tag-only: true

$ cog --version
cog 5.5.0

$ git --version
git version 2.25.1

[BUG] - Tiny Typo in Documentation

Describe the bug
Tiny typo in documentation: cog changelog --template hull_hash should read cog changelog --template full_hash

To Reproduce
see: e.g. https://docs.cocogitto.io/guide/#full-hash

Expected behavior
example for using 'full_hash' template should work when copied.

Additional context
need to replace 'h' with 'f' in 'hull_hash'

[BUG] Action seems to use wrong conventional_commit_parser version

Hello,
I have a Gitlab action failing (https://github.com/aeyoll/wr/actions/runs/3973873822/jobs/6812797736), with the following stack stace:

thread 'main' panicked at 'internal error: entered unreachable code: Unexpected footer token separator : `:
`', /cargo/registry/src/github.com-1ecc6299db9ec823/conventional_commit_parser-0.9.3/src/commit.rs:68:22

This issue seems to be fixed in conventional_commit_parser v0.9.4, but it looks like its using an older version.

Can you take a look? Thank a lot!

[BUG] The action cannot parse cog.toml packages entry

Hi!

Describe the bug
I configured the action as described here. Cocogitto can verify my commits locally without problems, but when I try running the github action it says that my config is invalid, because of the [packages] entry as it is not allowed.

To Reproduce
Try using the action with a monorepo cog.toml config that has a [packages] entry.

Expected behavior
I expected that the action can parse the cog.toml and runs correctly, just as it does locally.

Additional context
I think it is because the action uses an older version of cocogitto.
The log and my action config.

Thanks in advance!

[BUG] GitHub action doesn't fail even though cog check does

Describe the bug
Even though the commit message pushed/tested lets cog check fail the GitHub action succeeds.

To Reproduce
See here: https://github.com/mbehr1/adlt/runs/4753498724?check_suite_focus=true

Expected behavior
Action should fail if cog check fails.

Additional context
Seems as if the "shell=bash" used is set to shell: /usr/bin/sh -e {0} so will always return 0?

[BUG] this gives a false warning of only looking at annotated tags

Describe the bug
A clear and concise description of what the bug is.

For a repository which only uses lightweight tags, not annotated tags, this action will show something similar to

Run /home/runner/work/_actions/oknozor/cocogitto-action/v3/cog.sh    \
  /home/runner/work/_actions/oknozor/cocogitto-action/v3/cog.sh    \
  true \
  true \
  false               \
  cog-bot              \
  [email protected]
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
Setting git user : cog-bot
Settings git user email [email protected]
fatal: No annotated tags can describe 'f907aa4ebb0dd07a557ed5dcba'.

The cause of this is the cog.sh script.

cocogitto-action/cog.sh

Lines 20 to 25 in ac62601

	if [ "$(git describe --abbrev=0)" ]; then
	message="Checking commits from $(git describe --abbrev=0)"
	else
	message="No tag found checking history from first commit"
	fi
	echo "$message"

Based on looking at the script, I actually suspect cog's actual check is still doing the right thing, it's just this red herring error message that might confuse a user.

To Reproduce
Steps to reproduce the behavior:

In a repository with no annotated tags:

❯ git describe --abbrev=0
fatal: No annotated tags can describe 'f907aa4ebb0dd07a557ed5dcba34b39e3a11f43b'.
However, there were unannotated tags: try --tags.

❯ git describe --abbrev=0 --tags
v1.184.0

Expected behavior
A clear and concise description of what you expected to happen.

It should check from the latest tag, whether that is annotated or not.

Additional context
Add any other context about the problem here.

[question] How to detect that no bump was done and no new tag was generated

When I push a commit like this chore: some chores - there are no actual release expected to be done.
So the workflow could detect this and skip all further steps.

But currently there's no way or I can't find it how to detect that there were no bump performed.

I suggest to not create a step output in this case, so subsequent steps can analyze this and skip if needed.