Reports from codeship are no longer uploaded.
private
Codeship
I’ve attempted with several different uploaders: all of the bash, python and node uploaders fail to upload.
It seems that the hash that is coming from codeship is now a 12 character value, but codecov wants the 40 character hash.
Hi @schinckel, are you still experiencing this issue? We had an issue with upload here. If so, can you provide the Codecov output?
I worked around it by overriding the CI_COMMIT_ID variable with the longer hash from git.
That’s running okay, and I have been a bit too busy to check back.
Hi @schinckel, I made a pretty simple project, and I made a build here. Let me know if I’m doing something wrong trying to reproduce.
I can’t access that build @tom.
We updated to Codeship Pro a few months ago, and my workaround of sending the long commit hash is no longer possible.
As such, I’m no longer able to upload reports.
The uploader page fails on the “Pinging Codecov” step, and the HTML response indicates that the commit hash (12 chars) is invalid: it expects either (\d+:\W{12}) or (\W{40}).
I can prefix the short hash with an integer, but that then breaks linking reports back to bitbucket (and I’m not able to browse anything).
It gives me a full HTML response, but the error message (which is masked in a console by the fact that there is 80k of data) is:
# commit must match pattern ^\d+:\w{12}|\w{40}$This is from line 1750 of the uploader (VERSION=“20210115-cec3c92” seems to be the one it’s delivering right now).
I can, but I’m not sure that will help resolve this issue.
The problem is not with the bash script, it’s with the URL that is being hit to get the S3 bucket that the report(s) should be uploaded to. At that point, the request that is being made is rejected because the commit id is a 12 character hash, instead of a 40 character hash (or a number of digits followed by a colon followed by the 12 character hash).
I was able to fix this at the codeship end before moving to Codeship Pro by generating the long hash instead, but in Codeship Pro, we don’t have access to the git repository inside the containers that are running the code, only the environment variables that are provided.
What is the purpose of the leading \d+: on the short hash? Is that intentional? It’s not something I’ve ever come across in git, although it does look a bit like what mercurial revision:hash used to look like.
@schinckel, sorry this is driving me a little crazy to hunt down. I’m really just curious as to what IS getting sent to Codecov as the commit SHA, or if it’s anything we’re doing wrong on the bash uploader side, thus the ask for verbose mode.
So, I finally got around to getting a build running on codeship that had the -v. I’m not sure you need the whole log (it’s 2.6M), but the first section contains the setting of variables:
+ getopts a:A:b:B:cC:dD:e:f:F:g:G:hJ:k:Kn:p:P:Q:q:r:R:s:S:t:T:u:U:vx:X:Zz:N:- o
+ codecov_flags+=("$o")
+ case "$o" in
+ exit_with=1
+ getopts a:A:b:B:cC:dD:e:f:F:g:G:hJ:k:Kn:p:P:Q:q:r:R:s:S:t:T:u:U:vx:X:Zz:N:- o
+ codecov_flags+=("$o")
+ case "$o" in
+ '[' '' = '' ']'
+ search_in_o=/coverage/
+ getopts a:A:b:B:cC:dD:e:f:F:g:G:hJ:k:Kn:p:P:Q:q:r:R:s:S:t:T:u:U:vx:X:Zz:N:- o
+ codecov_flags+=("$o")
+ case "$o" in
+ commit_o=bfd2b49e3e09
+ getopts a:A:b:B:cC:dD:e:f:F:g:G:hJ:k:Kn:p:P:Q:q:r:R:s:S:t:T:u:U:vx:X:Zz:N:- o
+ say '
_____ _
/ ____| | |
| | ___ __| | ___ ___ _____ __
| | / _ \ / _` |/ _ \/ __/ _ \ \ / /
| |___| (_) | (_| | __/ (_| (_) \ V /
\_____\___/ \__,_|\___|\___\___/ \_/
Bash-20210128-d4071a2
The commit id is correct, that’s the (correct) short SHA hash for the commit.
@schinckel apologies it really would be useful to get the whole log. Although we set the commit variable there, it does possibly change. You are welcome to DM me if you are comfortable with that.
… but I can see that this value (the short SHA hash) is being sent to the server in the Pinging Codecov step, and this is what is failing. The error message that this page returns indicates that it is indeed the problem - it is looking for a hash that matches (\d+:\W{12})|(\W{40}), which this value does not.
When I run that step manually, and supply either the long hash, or a digit followed by a colon followed by the short hash, it uploads. In the latter case, this doesn’t associate correctly with bitbucket, but I am unable to get the long hash in the codeship pro system.
@schinckel, I’ll open an issue with the product team here. The reason for \d+: is actually mercurial SHAs.
@schinckel, sorry for the delay here. We’ve updated our uploaders and some issues with Codeship in the past few months. Would you be able to try the new uploader and see if you run into this issue?