Hello!
We use semantic-release
to publish new releases of our software, but the way Codacy handles coverage does not play nice with it.
After each commit that should trigger a release (fix
, feat
, etc.), a workflow runs, creating a new commit, which increments version numbers and updates CHANGELOG.md
, and then publishes a release on GitHub. The commit created in this process has [skip ci]
in the message, so this commit will not trigger any GitHub Actions builds, and thus not have a coverage report associated with it.
Hereās an example where you can see what our repositoriesā commits look like:
Iāve already added a workaround to this repository for coverage disappearing after committing something that should not trigger tests by caching coverage files, skipping tests and then uploading the old coverage again. This does not work for the [skip ci]
commits, though, as the workflow does not run at all. I really donāt want to remove the [skip ci]
tag from those commits, because this introduces another layer of workarounds to get this working, and the preferred behaviour is to NOT run workflows at all when theyāre not necessary. Other coverage CI tools Iāve used do not have this problem.
Weād like to be able to use one single service for both static analysis and coverage, but until this works properly we canāt have the āCodacy Coverage Reportā check block pull requests, and weāre still forced to use another service to manage coverage if we want to keep using Codacy.
PR example: feat: add shipments by EdieLemoine Ā· Pull Request #24 Ā· myparcelnl/pdk Ā· GitHub
At the time of writing, we have a commit in main that has been analysed, so the Codacy Coverage Report has passed.
As soon as a new release commit is added to main and the PR is rebased, this check will be stuck in āpendingā forever, and the Codacy dashboard will say no coverage has been uploaded, while the coverage rate in the āQuality evolutionā block does still say 100%.
I really hope this can be resolved.
Thanks in advance!
Edie
Developer at MyParcel