CodeCov uploads from Azure Pipeline CI runs on the GitHub ActiveDirectoryDsc repo have been failing for the last two weeks with the error ‘Build numbers do not match. Please upload with the Codecov repository upload token to resolve issue.’. They were working previously.
Right, sorry for being unclear. 28934a337b6ac8b60ba101deec6e3278f41f5c7e is the SHA being picked up by the uploader from env variables.
467ebb76f54fc5fd2a5c4156d2878abf35612b77 is the SHA the Azure API says it is. Which is correct and can you tell me the relationship between the two SHAs?
We are encountering the same issue. In case it helps, here is some info that may help debug the issue.
PR arviz#1123 tries to merge commit 5ec1c2c3802382d4be2847053ebb1e57ef0c76cb into master (at time of writing and running CI at commit e5208d14ec89a1970b0d3be9f55e1147d97fd1e4). It looks like Azure creates an extra commit from merging 5ec... into e52...: commit 051f6d88e4d980c72cef76b0e1e6cde1758b4d7f.
The commit message from 051... is Merge 5ec1c2c3802382d4be2847053ebb1e57ef0c76cb into e5208d14ec89a1970b0d3be9f55e1147d97fd1e4. All environment variables for the Azure build are shown here.
SYSTEM_PULLREQUEST_SOURCECOMMITID and “triggerInfo.pr.sourceSha” are 5ec...
Using -C does not work for the scenario in the DSC Community repos (we have this issue over all repos in the org that we are enable this for). This DID work before. So something has change somewhere.
NOTE: This example below is from a branch, not a PR. So the error occurs for branch commits too.Testing on a fork of xFailOverCluster repo.
Using argument -C is the same as the script already does. At line 790 it does
commit="$BUILD_SOURCEVERSION"
Which when the block that is mentioned above it hits which is skipped since commit was set at line 790.
elif [ "$commit" = "" ];
Running the bash script with debug messages (a copy with added say lines) I see that both returns the same commit at the end. First run is without-C, and the second run is with -C.
Previously, $pr would always have been empty, because we never had environment variables called $PULL_REQUEST_NUMBER or $PULL_REQUEST_ID. I bet that correcting that assignment to $SYSTEM_PULLREQUEST_PULLREQUEST* broke the logic further down the page.
We’re also investigating on our side, but we believe we haven’t changed the contents/semantics of any of the variables the Bash uploader looks for.
Hi everyone, thanks for reaching out here. I’m not exactly sure what happened, but I’m no longer seeing this issue on the repositories above. I would guess that maybe there was an issue with the bash uploader that has since been resolved. Please let me know if this issue has not been resolved for you.
Also thanks @vtbassmatt for reaching out here, we always appreciate the help.
Since there was no response on this issue we had to start workaround it by adding the upload token to a few repos that really needed this. We rather see a correct fix to this issue so we can remove the upload token variable again.
@tom can you give us what you are seeing on your end? What value is Codecov API expecting in the example PR I linked to above? That would help narrowing down if the wrong value is sent or if your end is expecting the wrong value.
Yes, I think I misspoke last night. Thanks @johlju for the logs, this is extremely helpful. I need to add some logging on our side and play around to see why this is happening.