Two things in the coverage path report success while doing nothing. Both are
visible in the logs of run
30401988315,
which is a normal PR run on develop.
The Codecov upload fails and the job goes green
-> Token length: 0
warning -- Some files were not found --- {"not_found_files": ["coverage.xml\n"]}
info -- Found 1 coverage files to report
error -- Upload queued for processing failed: {"message":"Token required - not valid tokenless upload"}
CodecovUpload is reported as success.
Three separate things line up here:
files: is written as a YAML block literal, so the filename arrives with a
trailing newline and the named file is not found. The uploader then falls
back to searching, which is why it still finds one file.CODECOV_TOKEN resolves to empty, so the upload is rejected. This run is
from a branch in this repository rather than a fork, so a missing secret on
fork PRs does not explain it.fail_ci_if_error: false means none of that fails the job.
So the coverage number Codecov shows has not been updated by this workflow.
Suggested shape of a fix: files: coverage.xml on one line, disable_search: true
so a silent fallback cannot mask a wrong path, and fail_ci_if_error: true so
the next breakage is visible. That last one only makes sense once the token
question is settled, otherwise every run goes red.
Six jobs write the same artifact name
The test matrix is {ubuntu, macos, windows} x {3.10, 3.14}, and every leg ends
with
- name: Upload coverage to artifacts
uses: actions/upload-artifact@main
with:
name: coverage
path: coverage.xml
overwrite: trueoverwrite: true replaces the artifact rather than merging into it, so the six
legs race and five results are discarded. The run above produced exactly one
artifact named coverage, 46638 bytes, and CodecovUpload downloads that one.
Whichever leg finished last is the whole picture.
Two ways out. Either give each leg a unique artifact and XML name and combine
them deliberately, or generate coverage in one canonical job and let the matrix
legs just prove the tests pass on each platform. The second is simpler to read
and avoids platform-conditional branches inflating the number.
Not urgent, but worth knowing
actions/checkout@main, actions/upload-artifact@main, actions/download-artifact@main
and codecov/codecov-action@main all track a moving branch. linters.yml
installs pylint unpinned, which is how a new pylint release becomes a red build
on an unrelated PR.
I found these while checking a review comment on #12. Happy to send a fix here,
or upstream first if you would rather these came back through the usual
RocketPy sync.
Two things in the coverage path report success while doing nothing. Both are
visible in the logs of run
30401988315,
which is a normal PR run on
develop.The Codecov upload fails and the job goes green
CodecovUploadis reported as success.Three separate things line up here:
files:is written as a YAML block literal, so the filename arrives with atrailing newline and the named file is not found. The uploader then falls
back to searching, which is why it still finds one file.
CODECOV_TOKENresolves to empty, so the upload is rejected. This run isfrom a branch in this repository rather than a fork, so a missing secret on
fork PRs does not explain it.
fail_ci_if_error: falsemeans none of that fails the job.So the coverage number Codecov shows has not been updated by this workflow.
Suggested shape of a fix:
files: coverage.xmlon one line,disable_search: trueso a silent fallback cannot mask a wrong path, and
fail_ci_if_error: truesothe next breakage is visible. That last one only makes sense once the token
question is settled, otherwise every run goes red.
Six jobs write the same artifact name
The test matrix is {ubuntu, macos, windows} x {3.10, 3.14}, and every leg ends
with
overwrite: truereplaces the artifact rather than merging into it, so the sixlegs race and five results are discarded. The run above produced exactly one
artifact named
coverage, 46638 bytes, andCodecovUploaddownloads that one.Whichever leg finished last is the whole picture.
Two ways out. Either give each leg a unique artifact and XML name and combine
them deliberately, or generate coverage in one canonical job and let the matrix
legs just prove the tests pass on each platform. The second is simpler to read
and avoids platform-conditional branches inflating the number.
Not urgent, but worth knowing
actions/checkout@main,actions/upload-artifact@main,actions/download-artifact@mainand
codecov/codecov-action@mainall track a moving branch.linters.ymlinstalls pylint unpinned, which is how a new pylint release becomes a red build
on an unrelated PR.
I found these while checking a review comment on #12. Happy to send a fix here,
or upstream first if you would rather these came back through the usual
RocketPy sync.