commitsar icon indicating copy to clipboard operation
commitsar copied to clipboard

commitsar not properly running on master?

Open tommyalatalo opened this issue 5 years ago • 8 comments

Since 0.9.0 had in its release notes that commitsar now should run on master I was curious to try it, but it seems to me that it's not working.

To reproduce:

  1. Clone a repo, (my example [email protected]:go-task/task.git)
  2. cd into repo, make sure master is checked out, which it is by default.
  3. I have commitsar 0.9.0 in my PATH, so I run commitsar

The resulting output:

❯ commitsar                                                                                                      
Starting analysis of commits on branch

1 commits filtered out

Found 0 commit to check
No commits found, please check you are on a branch outside of main

I ran git rev-list --count master to count the commits on the master branch of go-task, the result is 698. I guess this confirms that commitsar is not doing it's thing correctly?

Why is the first line of output from commitsar Starting analysis of commits on branch not stating a branch name?

tommyalatalo avatar Feb 08 '20 16:02 tommyalatalo

Hi @tommyalatalo , This was discussed already in https://github.com/outillage/commitsar/issues/104 so I guess this issue can be reopened.

The main issue is that if it's set to scan all master on existing repos that were not conventional commit compliant then your pipeline in master will always fail. We could try to set it up to use the GIT_DEPTH variable OR some config file which would allow you to overwrite the limit for checking on master.

Let me know if you have any other ideas. @matoous what do you think? Since you were in the original issue.

Why is the first line of output from commitsar Starting analysis of commits on branch not stating a branch name?

I'll make a separate issue out of this.

fallion avatar Feb 10 '20 09:02 fallion

Hi @tommyalatalo , This was discussed already in #104 so I guess this issue can be reopened.

The main issue is that if it's set to scan all master on existing repos that were not conventional commit compliant then your pipeline in master will always fail. We could try to set it up to use the GIT_DEPTH variable OR some config file which would allow you to overwrite the limit for checking on master.

Let me know if you have any other ideas. @matoous what do you think? Since you were in the original issue.

Why is the first line of output from commitsar Starting analysis of commits on branch not stating a branch name?

I'll make a separate issue out of this.

Well the problem for me now is that you can't use commitsar with a new repo where you use conventional commits from the start either?

tommyalatalo avatar Feb 10 '20 12:02 tommyalatalo

I found the issue and opened up #169 to fix it. This issue will be kept to track the idea of how far to run it. Thanks for the report @tommyalatalo !

fallion avatar Feb 10 '20 12:02 fallion

The GIT_DEPTH variable approach seems good to me, not sure if there's anything better that can be done to enable checking the whole master without breaking the check for people that didn't start with conventional commits.

matoous avatar Feb 10 '20 12:02 matoous

Hey, I'm using github actions, just like the example in the docs:

name: Conventional Commits checker

on: [pull_request]

jobs:
  validate-commits:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code into the Go module directory
        uses: actions/checkout@v2
      - name: Commitsar check
        uses: aevea/[email protected]

How should I set this GIT_DEPTH variable? I tried the following but it didn't work:

[...]
    steps:
      - name: Check out code into the Go module directory
        uses: actions/checkout@v2
      - name: Commitsar check
        uses: aevea/[email protected]
        env: 
          GIT_DEPTH: 0

Full log from Github actions:

Commitsar check
0s
    GIT_DEPTH: 0
Run aevea/[email protected]
  with:
  env:
    GIT_DEPTH: 0
/usr/bin/docker run --name d34832264d60c2464da27002c089c2c674_d86e4e --label 3888d3 --workdir /github/workspace --rm -e GIT_DEPTH -e INPUT_CONFIG -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_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 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/ddg-test-project/ddg-test-project":"/github/workspace" 3888d3:4832264d60c2464da27002c089c2c674
Starting analysis of commits on branch HEAD
reference not found

lfilho avatar Jun 16 '20 19:06 lfilho

Seems checkout@v2 works a little different. Going to fork an issue for this. Thanks for the report @lfilho

fallion avatar Jun 16 '20 19:06 fallion

Thanks for the quick reply! I'm using checkout@v2 for all my other workflows so though of keeping it consistent :-)

I'll try with v1 on my next PR and report back to confirm it worked.

lfilho avatar Jun 16 '20 20:06 lfilho

Yeap, confirmed it worked with checkout@v1

lfilho avatar Jun 17 '20 02:06 lfilho