Launchpad's snap builder can't access

Asked by NeoTheThird on 2020-10-03

I'm building the ubports-installer snap through the snap builder, which uses launchpad. For a couple days now it has had problems accessing, which i need to download additional files.

Here's a build:
And here's the failing part of the log:

[03/Oct/2020:16:43:07 +0000] "GET HTTP/1.1" 200 57470 "-" "axios/0.20.0"
[03/Oct/2020:16:43:09 +0000] "GET HTTP/1.1" 302 96 "-" "axios/0.20.0"
Error: Error: Download Error: Error: getaddrinfo ENOTFOUND
    at /build/ubports-installer/parts/ubports-installer/build/node_modules/progressive-downloader/lib/module.cjs:222:14
    at process._tickCallback (internal/process/next_tick.js:68:7)
Failed to run 'override-build': Exit code was 1.
Build failed

Question information

English Edit question
Launchpad itself Edit question
No assignee Edit question
Solved by:
Colin Watson
Last query:
Last reply:
NeoTheThird (neothethird) said : #1

Huh!? I tried to exchange the target url to my sftp, because i figured that'd be in-house so it shouldn't be a problem. Turns out downloads just fail, period. From

[04/Oct/2020:08:04:58 +0000] "GET HTTP/1.1" 403 1927 "-" "axios/0.20.0"
[04/Oct/2020:08:04:58 +0000] "GET HTTP/1.1" 403 1933 "-" "axios/0.20.0"
Error: Error: Download Error: Error: Request failed with status code 403
    at /build/ubports-installer/parts/ubports-installer/build/node_modules/progressive-downloader/lib/module.cjs:222:14
    at process._tickCallback (internal/process/next_tick.js:68:7)

I *really* don't want to have to re-work my snap build to be different from the others. Any chance we can get this addressed?

That being said, i did recently switch to a new download library that uses the npm package axios rather than the deprecated request package, but it works EVERYWHERE else, so i still think this is a problem with launchpad. Any weird proxy configs in http_proxy or https_proxy going on, maybe?

Best Colin Watson (cjwatson) said : #2

Launchpad snap builds are required to go through a proxy, yes, and we set http_proxy and https_proxy accordingly; they have a limited DNS view, so if they fail to use the proxy correctly then things will go wrong. This is because many of the build types that share the same build farm are by policy not allowed to use the general internet at all; the proxy setup allows us to make internet access available only for certain build types, while also making it harder for it to be used as e.g. a botnet host.

In fact, we can see in your build log that the proxy itself is working fine, because it logged a 302 response:

[03/Oct/2020:16:43:09 +0000] "GET HTTP/1.1" 302 96 "-" "axios/0.20.0"

But then you have the progressive-downloader failure immediately after that. I think this axios library you're using has buggy proxy handling and fails to pass redirects through the proxy correctly. I'm not sure if it's quite the same thing, but there's a long-standing bug about axios proxy/redirect handling ( Maybe consider if there's some more robust alternative?

Your attempt to use failed because the proxy generally forbids access to resources within Canonical's datacentre unless they've been specifically allowed (to avoid potential problems with old internal sites that might assume that requests from within our datacentre are implicitly OK, which would obviously be bad design but we'd rather not find out the hard way). We can certainly add a rule allowing, but it wouldn't help - you'd still run into the same problem with your HTTP client library failing to handle redirects properly. And there was absolutely no point in changing the URL for heimdall, because the log indicates that the proxy returned a 200 response for that already.

On the other hand, a workaround that should actually work would be to manually chase the redirect returned by, and instead temporarily set the URL to (currently) until you can get your HTTP client library fixed.

NeoTheThird (neothethird) said : #3

Thanks Colin Watson, that solved my question.