If you have contributed to the core libraries, or any other library which uses one of the core libraries’ CI configuration files as a starting point, you may have seen a failed CI job with a build log like this:
$ TAG=$(wget -q -O - https://github.com/purescript/purescript/releases/latest --server-response --max-redirect 0 2>&1 | sed -n -e 's/.*Location:.*tag\///p')
0.18s$ wget -O $HOME/purescript.tar.gz https://github.com/purescript/purescript/releases/download/$TAG/linux64.tar.gz
--2020-03-07 14:02:09-- https://github.com/purescript/purescript/releases/download//linux64.tar.gz
Resolving github.com (github.com)... 192.30.253.112
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-03-07 14:02:09 ERROR 404: Not Found.
The command "wget -O $HOME/purescript.tar.gz https://github.com/purescript/purescript/releases/download/$TAG/linux64.tar.gz" failed and exited with 8 during .
In case it’s not clear, the purpose of this step is to identify and then download the latest version of the purescript compiler.
I’ve diagnosed the issue: it’s that the web server has started sending HTTP response headers with different casing - specifically, they seem to all be lowercase now, like location: http://.... This is a problem because the script expects the Location header to be written exactly as Location.
It can be fixed by placing an I at the end of the sed command to make the matching case-insensitive, like this:
However you may find it preferable to update your CI configuration to instead install the compiler via npm and specify the version you want in package.json. That way you can upgrade when you’re ready, rather than having CI jobs just start failing when a new version is released.
@garyb ^ this may be of interest to you. Before I start updating the core libraries .travis.yml files, do you have any thoughts on installing the compiler via npm in core libraries’ CI scripts instead?
Ah excellent! I had been stumped by this. It still works like one in every 50 attempts, so it seemed, and when I did some testing to see what was going wrong with the version number it was extracting it was working .
The advantage of fetching the binary this way was that we can start releasing libraries without having to wait for the new version to be published to npm, but after the compiler release has been made on GH. That’s perhaps less of a concern now we’re in control of publishing to npm though.
For what it’s worth, I fixed this in the js-date and argonaut-core libraries with a different command — I’m away from a computer so I’m not exactly sure what it was. I can switch to yours for consistency when I’m back from vacation, though.
This approach does have the advantage of always using the latest compiler.
Yeah, yours switched it to curl, I meant to mention that in the above too. I think I used wget as originally curl wasn’t available in the CI images, so I was surprised that worked!
This seems more reliable and it’s probably safe to assume that these CI boxes will continue to provide curl, so I’m keen for starting to update libraries to use this.
If we do that, maybe we can switch the wget request that fetches the asset over to use curl then too. It seems a little strange to use both in this process
Here’s a snippet of .travis.yml I suggest we use going forward. It uses curl for both commands. I started with @thomashoneyman’s version but modified it to use long options because that makes it easier to see what’s going on, I think.
.