commitsar
commitsar copied to clipboard
aevea
Add 'docker run' example / incorrect docker result
Could you add a "docker run ..." command example to the repository README.md docs?
I've been trying to run commitsar with a direct docker run command, and I think I have it running correctly with this: docker run --rm --name="commitsar" -w /src -v "$(pwd)":/src commitsar/commitsar:0.10.0
But the result is incorrect. I ran the above container from a repository with a master branch containing 71 commits, but commitsar just finds the latest commit and reports 1 of 1 commits are not conventional commit compliant. Why are the other 70 commits ignored?
First part I will add this week to the README. Thanks again for finding issues like this.
As for:
But the result is incorrect. I ran the above container from a repository with a master branch containing 71 commits, but commitsar just finds the latest commit and reports 1 of 1 commits are not conventional commit compliant. Why are the other 70 commits ignored?
Can you check the discussion here? https://github.com/outillage/commitsar/issues/167#issuecomment-584108836 We need to find a balance of how far to check on master due to repos not having adopted the conventional commit standard in the past.
I'm going to add 2 flags which will sort this out. --all which is the use you're looking for and --limit which will limit the number of checked commits.
I'm going to add 2 flags which will sort this out.
--allwhich is the use you're looking for and--limitwhich will limit the number of checked commits.
That would work, but shouldn't "all" be the default behavior? Limiting the range of commits to be checked seems like perfect flag material. What would running commitsar without flags do otherwise?
Currently it goes like this:
on branch -> All commits are checked until the upstream
on master -> Last commit is checked in order to not block all repositories that were not conventional commit compliant before
There was a suggestion to mirror GIT_DEPTH as well for how far to check on master. It's primarily an issue during adoption. After that it is fine, but if you have very large repositories you do not want to go too far back as it would constantly fail on master in those repositories.
Currently it goes like this:
on branch-> All commits are checked until the upstreamon master-> Last commit is checked in order to not block all repositories that were not conventional commit compliant beforeThere was a suggestion to mirror
GIT_DEPTHas well for how far to check on master. It's primarily an issue during adoption. After that it is fine, but if you have very large repositories you do not want to go too far back as it would constantly fail on master in those repositories.
Either way works I guess, I hope the --all flag can get implemented soon, I'm itching to get this into my pipeline for the master branch!
@tommyalatalo sorry about the delay. Here it is: https://github.com/outillage/commitsar/releases/tag/v0.11.0
https://github.com/outillage/commitsar#flags
@tommyalatalo Pushed. I migrated this repo to GH Actions, but clearly forgot the docker hub push. 🤦♂
0.11.1 (latest release) is. I’ll release 0.11.0 ASAP.
No its not, at least not tagged as "0.11.1"
docker pull commitsar/commitsar:0.11.1
Error response from daemon: manifest for commitsar/commitsar:0.11.1 not found: manifest unknown: manifest unknown
I see the issue. https://hub.docker.com/r/outillage/commitsar
There was a rebranding under the outillage name. I’ll set up the backwards compatibility with the old namespace and set up a deprecation strategy.
I need to improve communication on such issue, however I need to find the correct medium.
@tommyalatalo is it working ok for you? Can I close this after adding it to docs?
It works, but you shouldn't really need to define the workdir though. If you just write the entrypoint to always run in /src then you can just state in the docs that you always mount the git repo to be checked into /src and you can skip setting the workdir. Would be one thing less to consider.