How to use as a GitHub Action?

[orhun]

Hello! 🐻

I'm trying to use committed as a GitHub Action as follows:

name: CI

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        if: github.event_name != 'pull_request'
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Checkout
        if: github.event_name == 'pull_request'
        uses: actions/checkout@v3
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
      - name: "Check conventional commits"
        uses: crate-ci/committed@master

However, I'm getting this:

Linting commits:
fatal: ambiguous argument 'HEAD~..HEAD^2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:

Against 'committed.toml':
'git <command> [<revision>...] -- [<file>...]'
parent 1 does not exist; class=Invalid (3); code=NotFound (-3)
subject_length = 0
subject_capitalized = false
subject_not_punctuated = true
imperative_subject = true
no_fixup = true
no_wip = true
hard_line_length = 0
line_length = 0
style = 'conventional'
allowed_types = [
    'fix',
    'feat',
    'chore',
    'docs',
    'style',
    'refactor',
    'perf',
    'test',
]
merge_commit = false

If this fails, don't sweat it. We're trying to encourage clear communication and not hinder contributions.
If it is a reasonable issue and you lack time or feel uncomfortable fixing it yourself,
let us know and we can mentor or fix it.

This is due to hardcoded HEAD~..HEAD^2 in the action:

committed/docker/entrypoint.sh

Line 28 in dc0bcf8

${COMMAND} --color=always -vv --no-merge-commit HEAD~..HEAD^2

$ git log --color=always --graph --oneline HEAD~..HEAD^2

fatal: ambiguous argument 'HEAD~..HEAD^2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

Is there a way to configure this to e.g. pass only HEAD?

[orhun]

Ah, just saw this:

committed/.github/workflows/test-action.yml

Line 2 in dc0bcf8

on: [pull_request]

Is the GitHub Action intended to be used only for pull requests?

[orhun]

I figured out a way to do this and submitted a PR: #321

[epage]

Is the GitHub Action intended to be used only for pull requests?

Yes. Could you describe why you would like this for pushes? It seems like its too late at that point to act on it.

[orhun]

Two reasons:

1. Squash commits: There isn't any check later-on if you squash the commits while merging the PR. This means "unconventional" commits might made into the target branch and they can be easily dismissed.
2. Testing: When you want to integrate committed to your project, there is no way to test the action without creating a PR. I simply want to push to a branch and see it run.

[epage]

Squash commits: There isn't any check later-on if you squash the commits while merging the PR. This means "unconventional" commits might made into the target branch and they can be easily dismissed.

Aren't they squashed into the target branch, making it too late to do anything, or do you have an intermediate step in your process?

Testing: When you want to integrate committed to your project, there is no way to test the action without creating a PR. I simply want to push to a branch and see it run.

Intriguing thought

[orhun]

Aren't they squashed into the target branch, making it too late to do anything, or do you have an intermediate step in your process?

Yes, however, imagine this scenario:

1- Someone opens a pull request with an unconventional (i.e. not committed-friendly) commits.
2- committed warns the author about this situation and they force-push to edit the commit message (or push another commit).
3- The maintainer approves the changes, squashes the commits into the target branch with an unconventional commit message.
4- The commit sits in the branch and no one realizes it.

Versus:

4- committed is being run on pushes and the CI warning about an unconventional commit message.
5- The maintainer throws a random curse word and now becomes more careful (and -I don't condone this but- maybe force-push).

I know this is kind of an edge case but I really think using a GitHub Action for committed would be useful.

[epage]

So the intention is to allow projects to give a feedback loop to maintainers to ensure the squashed commits are conventional?

Sounds reasonable enough! Thank you for helping me understand the workflow!

[orhun]

So the intention is to allow projects to give a feedback loop to maintainers to ensure the squashed commits are conventional?

Sounds reasonable enough! Thank you for helping me understand the workflow!

Yes, exactly. Thanks!