Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

commitsar not properly running on master? #167

Open
tommyalatalo opened this issue Feb 8, 2020 · 8 comments
Open

commitsar not properly running on master? #167

tommyalatalo opened this issue Feb 8, 2020 · 8 comments
Labels
enhancement New feature or request proposal Issues that have no certain future yet

Comments

@tommyalatalo
Copy link

tommyalatalo commented Feb 8, 2020

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 git@github.com: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?

@fallion
Copy link
Member

fallion commented Feb 10, 2020

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.

@fallion fallion added the bug Something isn't working label Feb 10, 2020
@tommyalatalo
Copy link
Author

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?

@fallion
Copy link
Member

fallion commented Feb 10, 2020

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 fallion added enhancement New feature or request proposal Issues that have no certain future yet and removed bug Something isn't working labels Feb 10, 2020
@matoous
Copy link

matoous commented Feb 10, 2020

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.

lfilho pushed a commit to lfilho/sample-webextension that referenced this issue Jun 16, 2020
@lfilho
Copy link

lfilho commented Jun 16, 2020

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/commitsar@v0.13.0

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/commitsar@v0.13.0
        env: 
          GIT_DEPTH: 0

Full log from Github actions:

Commitsar check
0s
    GIT_DEPTH: 0
Run aevea/commitsar@v0.13.0
  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

@fallion
Copy link
Member

fallion commented Jun 16, 2020

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

@lfilho
Copy link

lfilho commented Jun 16, 2020

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
Copy link

lfilho commented Jun 17, 2020

Yeap, confirmed it worked with checkout@v1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request proposal Issues that have no certain future yet
Projects
None yet
Development

No branches or pull requests

4 participants