• travis: move script sections to files in .travis/ subject to shellcheck #13863 (travis: move script sections to files in .travis/ subject to shellcheck by scravy)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

This will upload the binaries for every travis job that runs. Maybe limit it to pull requests on the bitcoin repository?

@ken2812221 Can the binaries be downloaded from Travis CI console currently? Please update the PR description with scenarios that could be achieved post merge that cannot be achieved pre merge :-)

This will upload the binaries for every travis job that runs. Maybe limit it to pull requests on the bitcoin repository?

People may want to test the master branch.

Can the binaries be downloaded from Travis CI console currently?

Yes, it prints out the URL at the end of each build.

Please update the PR description with scenarios that could be achieved post merge that cannot be achieved pre merge :-)

What do you mean?

@ken2812221 Oh, sorry I think I misunderstood you. The binaries are not available from download directly from Travis CI, but by uploading them to transfer.sh they are made available? If so it makes sense. I think the text "Download it from travis-ci console" fooled me into thinking the binaries were downloadable directly from Travis CI :-)

People may want to test the master branch.

@ken2812221 fair enough, but it will also run for every fork (other peopls repositories), every branch, every push that anyone does, right?

I think the curl version in the travis image is quite an old one (the one shipped with ubuntu 14.04 trusty probably).

I see in the logs:

0.38s$ test ! -z $OUTDIR && for file in $(find $OUTDIR/bin -executable -type f); do curl --retry 3 --retry-delay 0 -m 60 --connect-timeout=10 --upload-file $file https://transfer.sh/$(sha256sum $file | cut -d' ' -f1)-$(basename $file); echo; done
curl: option --connect-timeout=10: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
curl: option --connect-timeout=10: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
curl: option --connect-timeout=10: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
curl: option --connect-timeout=10: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
curl: option --connect-timeout=10: is unknown
curl: try 'curl --help' or 'curl --manual' for more information

But I think after_script sections don't fail the build (?) hence all checks passed.

@scravy I should not use =. That's my mistake.

but it will also run for every fork (other peopls repositories), every branch, every push that anyone does, right?

I can't see any downside of doing this.

Hmm, we could really limit this to pull requests on our repo. Otherwise, the hoster might exclude travis ips for spamming, no?

Note that for the master branch, we already have nightly builds: https://bitcoin.jonasschnelli.ch/#nighly
And for release branches, we have our usual gitian builds: https://bitcoincore.org/en/download/

we could really limit this to pull requests on our repo. Otherwise, the hoster might exclude travis ips for spamming.

You really convinced me. I don't want to get any ban by any host.

This is the easiest way to test and verify what PR do.

I feel that the correct way to do that is to checkout and build the PR branch. It's common to tweak the code while testing, especially the corresponding tests.

At the moment, from the reviewer/tester point of view, I don't see advantages of this and for that reason NACK.

@promag It's easy to do testing and tweak the code for Linux, but it's complicate for Windows and cross compile things. No body want to do cross compiling, I think this PR is good for that.

This has been discussed before, and I don't think it's a good idea. Uploading binaries for pull requests automatically gives e.g. malware authors a way to make and host semi-genuine-looking executables easily (and gives incentive to use our repository for this!).

Furthermore, the Travis executables aren't really intended to be distributed. They might, at least theoretically, be specially adapted for testing in a specific environment. It's not a gitian build.

I think @jonasschnelli / @MarcoFalke 's solution is better - have a real gitian build be triggered by a tag or otherwise, by maintainers.

@laanwj Thanks for your comment. Although this PR was rejected, I can still provide my own gitian build result in my PR, right?

but I can still provide my own gitian-build result in my PR, right?

Sure, you can do what you want in your own PRs. My argument is only against doing it automatically for PRs in a "centralized" way.

It is still good to have to code around. If someone really wants to debug the travis binaries, they can lookup this pull and cherry-pick this patch into their travis yml.