Build: Travis CI - Test and Deploy Your Code with Confidence
The goal is to upload the Windows compiled artefacts to a GCS bucket.
Because this is a Go project with C++ extensions, the build uses the msys64\mingw64 environment.
Despite the fact that the log says it has installed Python exec (lines 489+), the deploy step fails (see log bottom).
Is it a bug or am I missing something here?
thanks,
EMM
That python.exe is in a location that is not in the PATH of the default Git Bash environment that Travis uses (see line 38). Add it with: export PATH=$PATH:/c/tools/msys64/mingw64/bin.
Hi @tanzislam , thank you for replying.
Your suggestion is what appears to be already on line 62 of my config: Travis CI - Test and Deploy Your Code with Confidence
Where in my config should I add the export PATH=.... ?
So added the line to the end of the script (which is just before deployment start).
This helped but resulted in a different error 
'~' is not recognized as an internal or external command
Apparently this has been mentioned before. Not sure whether PR#1106 will fix it.
This is usually due to a spacing issue when it comes to PATH, observing @emicklei’s .travis.yml some issues I seen within seconds were:
local-dir: $TARGET
Should be:
local_dir: $TARGET
Usually wrong hooks wouldn’t verbosely give this error, but it’s feasible in this case. See if that helps with the issue, if not I’ll be glad to help more.
Happy building!
Montana Mendy
Travis CI Staff
@Montana thank you for spotting this.
I made the change but the recent build does not show an improvement (still the ~ problem).
Hello @Montana ,
That result is misleading ; the untagged builds do not take the deploy step. ( tags: true)
See Travis CI - Test and Deploy Your Code with Confidence for the latest failed one.
Unless there is another change to try, I write revert back to my initial AWS S3 deploy which has shown to work.
Hey @emicklei, I’ll do some tests myself on GCS, and see what I can come up with for you.
Hi @Montana , did you find the time to do some testing? thanks for looking into this.
Hey @emicklei,
It seems to stem from this.
Specifically:
it { expect { subject.validate_runtimes(runtimes) }.to_not raise_error }
end end
describe 'satisfied (2.7.13)' do
let(:version) { 'Python 2.7.13' }
it { expect { subject.validate_runtimes([[:python, ['>= 2.7.9']]]) }.to_not raise_error }
end
describe 'satisfied (3.6)' do describe 'satisfied (3.6)' do
let(:version) { 'Python 3.6' } let(:version) { 'Python 3.6' }
it { expect { subject.validate_runtimes(runtimes) }.to_not raise_error } it { expect { subject.validate_runtimes(runtimes) }.to_not raise_error }
This answer has been formed from me doing hours (personally) of AB testing, digging, verbosing logs, etc, then finally figuring out where the error is coming from (at least within Travis).
Have you looked into using the Boto configuration file?
It seems to me gcloud isn’t available for authentication and since there’s some issue with CI platforms in this particular issue. So what you can do is add a .boto configuration file. BOTO_PATH points to {YOUR PROJECT_DIR}/.boto. So technically, you’re doing a ci: skip.
A sample boto:
# Travis CI
import os
BOTO_TEMPLATE = """\
[Credentials]
gs_service_key_file = {gcs_service_account_path}
[Boto]
https_validate_certificates = True
[GSUtil]
content_language = en
default_api_version = 2
default_project_id = {google_cloud_project}
"""
def main():
boto_filename = os.path.abspath(os.environ["BOTO_CONFIG"])
google_cloud_project = os.environ["GOOGLE_CLOUD_PROJECT"]
build_dir = os.path.dirname(boto_filename)
gcs_service_account_path = os.path.join(build_dir, "key.json")
boto_contents = BOTO_TEMPLATE.format(
gcs_service_account_path=gcs_service_account_path,
google_cloud_project=google_cloud_project,
)
with open(boto_filename, "w") as file_obj:
file_obj.write(boto_contents)
if __name__ == "__main__":
main()
I’m still looking into this, and going to push this internally as well, I definitely want to get this sorted out for you.
Montana Mendy
Travis CI Staff
Any progress on this topic?