Bitbucket pipeline upload fail when git it not available #1521
Description
Describe the bug
The issue is that _getSha function still calls runExternalProgram, even when args.sha
is passed even if the result is discarded
function _getSHA(inputs: UploaderInputs): string {
const { args, environment: envs } = inputs
let commit = envs.BITBUCKET_COMMIT || ''
if (commit && validateSHA(commit, 12)) {
commit = runExternalProgram('git', ['rev-parse', commit])
}
return args.sha || commit || ''
}
To Reproduce
Steps to reproduce the behavior:
- Run pipeline step with
image: node:18-buster-slim
- Generate test report
- Download an run uploader
set -x
apt-get update && apt-get install curl gnupg coreutils -y
curl https://keybase.io/codecovsecurity/pgp_keys.asc | gpg --no-default-keyring --keyring trustedkeys.gpg --import # One-time step
curl -Os https://uploader.codecov.io/latest/linux/codecov
curl -Os https://uploader.codecov.io/latest/linux/codecov.SHA256SUM
curl -Os https://uploader.codecov.io/latest/linux/codecov.SHA256SUM.sig
gpgv codecov.SHA256SUM.sig codecov.SHA256SUM
sha256sum -c codecov.SHA256SUM
chmod +x codecov
./codecov \
-t ${CODECOV_TOKEN} \
-C ${BITBUCKET_COMMIT} \
--dir coverage \
--rootDir ${BITBUCKET_CLONE_DIR} \
--slug ${BITBUCKET_REPO_FULL_NAME} \
--verbose
- See error
[2024-04-08T14:50:48.136Z] ['info'] Using manual override from args.
[2024-04-08T14:50:48.137Z] ['info'] Detected Bitbucket as the CI provider.
[2024-04-08T14:50:48.137Z] ['verbose'] -> Using the following env variables:
[2024-04-08T14:50:48.137Z] ['verbose'] CI: true
[2024-04-08T14:50:48.137Z] ['verbose'] BITBUCKET_BUILD_NUMBER: 13944
[2024-04-08T14:50:48.142Z] ['error'] Error detecting repos setting using git: Error: Error running external program: Error: spawnSync git ENOENT
[2024-04-08T14:50:48.143Z] ['verbose'] Using the following upload parameters:
[2024-04-08T14:50:48.143Z] ['verbose'] commit
[2024-04-08T14:50:48.143Z] ['verbose'] name
[2024-04-08T14:50:48.143Z] ['verbose'] tag
[2024-04-08T14:50:48.143Z] ['verbose'] flags
[2024-04-08T14:50:48.143Z] ['verbose'] parent
[2024-04-08T14:50:48.144Z] ['info'] Pinging Codecov: https://codecov.io/upload/v4?package=uploader-0.7.2&token=*******&commit=d9d3d2a783ff&name=&tag=&flags=&parent=
[2024-04-08T14:50:48.144Z] ['verbose'] Passed token was 36 characters long
[2024-04-08T14:50:48.144Z] ['verbose'] https://codecov.io/upload/v4?package=uploader-0.7.2&commit=d9d3d2a783ff&name=&tag=&flags=&parent=
Content-Type: 'text/plain'
Content-Encoding: 'gzip'
X-Reduced-Redundancy: 'false'
[2024-04-08T14:50:48.293Z] ['error'] There was an error running the uploader: Error uploading to https://codecov.io/: Error: There was an error fetching the storage URL during POST: 400 - Invalid request parameters
[2024-04-08T14:50:48.293Z] ['verbose'] The error stack is: Error: Error uploading to https://codecov.io: Error: There was an error fetching the storage URL during POST: 400 - Invalid request parameters
at main (/snapshot/repo/dist/src/index.js)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2024-04-08T14:50:48.294Z] ['verbose'] End of uploader: 863 milliseconds
[2024-04-08T14:50:48.294Z] ['info'] Codecov will exit with status code 0. If you are expecting a non-zero exit code, please pass in the `-Z` flag
Expected behavior
It should accept the passed in commit, or display actual error that commit format is not valid. (if full sha is required?)
These seems to be also a weird problem where Bitbucket on first runs returns short sha (12 characters) on follow up it returns full sha (40 characters) that actually works. See second run screenshot.
+ echo ${BITBUCKET_COMMIT}
d9d3d2a783ff
--- second re-run ---
+ echo ${BITBUCKET_COMMIT}
d9d3d2a783ff39eff9ab9567cf0b7ca1b877131c
Additional context
If Codecov can only work full sha it return error, saying that sha passed in is not valid. Ideally Codecov should accept both?
- Alternatively if someone know why sha change on Bitbucket on second run?
Seems to be different behaviour on pull-request run vs manual run...
https://jira.atlassian.com/browse/BCLOUD-19393
Metadata
Assignees
Labels
Type
Projects
Status
No status