Caddy: linux/arm7 build server is broken: "provisioning build environment: go get: exit status 1"

[comp500]

1. Which version of Caddy are you using (caddy -version)?

Caddy 0.11.2 currently, trying to upgrade to 1.0.0.

2. What are you trying to do?

Update Caddy using the bash script to version 1.0.0.

3. What is your Caddyfile?

N/A

4. How did you run Caddy (give the full command and describe the execution environment)?

Bash on Raspbian: curl https://getcaddy.com | bash -s personal dyndns,http.filebrowser,http.filter,http.forwardproxy,http.git,http.gopkg,http.jwt,http.login,http.proxyprotocol,http.webdav,tls.dns.cloudflare

5. Please paste any relevant HTTP request(s) here.

N/A

6. What did you expect to see?

Caddy installed with all the plugins I use.

7. What did you see instead (give full error messages and/or log)?

I tried to install (update) Caddy through the bash file, which resulted in the following error:

curl: (22) The requested URL returned error: 500 
Aborted, error 22 in command: curl -fsSL "$caddy_url" -u "$CADDY_ACCOUNT_ID:$CADDY_API_KEY" -o "$dl"

I then selected my build configuration (linux/arm7, personal, some plugins) in the download page, and tried to download the resulting file directly, but the following error was printed:

provisioning build environment: go get: exit status 1

It works without plugins, but breaks with any plugin. The smallest URL I have found to reproduce this is https://caddyserver.com/download/linux/arm7?plugins=dyndns&license=personal.

8. Why is this a bug, and how do you think this should be fixed?

It's a bug because this has always worked with previous versions of Caddy, and plugins should be usable on linux/arm7.

9. What are you doing to work around the problem in the meantime?

Using the old version of Caddy I already had installed.

10. Please link to any related issues, pull requests, and/or discussion.

This has happened before when Caddy has updated, see #2159.

Bonus: What do you use Caddy for? Why did you choose Caddy?

I use it to secure a web terminal behind a Google OAuth login page (using login and jwt), so I don't have to manage another password just to type some commands. I also use it to host files so I can share them with other people easily, and to proxy various websites on restricted internet connections. I chose it because it's easy to configure, has many useful plugins, and is written in Go.

[adriel]

I just hit upon the same issue. For me, it was just the http.filter plugin causing the error, tls.dns.cloudflare and http.git work fine for me.

[triaqu]

I have same issue with curl https://getcaddy.com | bash -s personal http.filebrowser

[gegehennb]

The same problem, using plugins=http.filebrowser.
HTTP request sent, awaiting response... 500 Internal Server Error
2019-04-25 08:47:55 ERROR 500: Internal Server Error.

[mholt]

Thanks for the report.

I need to look into it more (e.g. the actual logs, but I don't have time tonight, and I'm graduating tomorrow...) but I'm afraid that some plugins might not yet build with Go modules. I'll look into it, but it might take some time to fully resolve it with all plugins, since it _might_ require the plugin authors making updates.

[wmark]

I can confirm that my plugin http.upload builds with Go modules. Indeed, it even did so with the downloads' page and _Caddy_ v1.0.0-beta2.

Although I did not change anything in my plugin, using the page since _Caddy's_ v1.0.0 release results in above error.

Meanwhile I've removed the plugin because I don't agree with the impression given it were the plugins, or negligence of its authors. Once the buildsrv or whatever the cause is fixed feel free to re-list the plugin again.

[mholt]

@wmark Because you removed the plugin, I cannot debug it now.

[wmark]

Nothing is preventing you from relisting—the source code is on Github—or holding back from debugging using a different plugin, or the http.filter mentioned here.

We plugin authors don't get any info about why a build fails with the buildsrv. In future, you could automate and make available a sample of log outputs to us. Naturally our hands still will be bound if it's not caused by a plugin.

[mholt]

@wmark I know this, of course. I need to see how the plugin's release was configured on the build server in order to debug the issue. By removing it, that configuration is gone and now I can no longer see if there was a bug in the build server or not.

[wmark]

If it worked with v1.0.0-beta2 and didn't change, but Caddy to v1.0.0, then it's likely Caddy or the buildsrv that introduced breaking changes.

In any case, plugin authors cannot configure more than three things (excl. some documentation strings): Actual and nominal location, and tag/commit. I didn't see anything else.

I can only guess what could've went wrong, and my first guess were go.mod entries didn't match anymore, v0.0.0 has not been used, or directories have not been configured polluting the buildsrv's build environments. That's where I would start an undistracted examination in good faith.

[mholt]

I can only guess what could've went wrong

Same here, after you removed your plugin from the site. Simply re-add it to the site (you can hide it without removing it completely, which would be the proper, mature way to handle this) and I can take a look at why it's failing. I've been able to fix a number of other plugins already, and it was because of how their release was configured: nothing in their code or repo, per-se. For example, plugins can't be released at origin/master anymore; it has to be an actual semver tag (the site will soon be updated to reflect this). But without any releases on the site to check, I can't debug this, unfortunately.

We'd welcome your plugin back on your site when you want to be cooperative, but this issue is resolved.