I’m not sure if this belongs in Help or Coding–putting it here because I’m not coding anything myself. I’m trying to build Caddy from source in preparation for building a RPM for EL7/CentOS7, and running into an error that I don’t see has been discussed here. Following the README, I run:
➜ ~ mkdir caddy
➜ ~ cd caddy
➜ caddy wget https://github.com/caddyserver/caddy/raw/master/cmd/caddy/main.go
--2021-02-01 07:27:43-- https://github.com/caddyserver/caddy/raw/master/cmd/caddy/main.go
Resolving github.com (github.com)... 140.82.114.3
Connecting to github.com (github.com)|140.82.114.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/caddyserver/caddy/master/cmd/caddy/main.go [following]
--2021-02-01 07:27:44-- https://raw.githubusercontent.com/caddyserver/caddy/master/cmd/caddy/main.go
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.204.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.204.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1364 (1.3K) [text/plain]
Saving to: ‘main.go’
100%[==========================================================================================>] 1,364 --.-K/s in 0s
2021-02-01 07:27:44 (27.2 MB/s) - ‘main.go’ saved [1364/1364]
➜ caddy go mod init caddy
go: creating new go.mod: module caddy
➜ caddy go get github.com/caddyserver/caddy/v2@v2.3.0
go: downloading github.com/caddyserver/caddy/v2 v2.3.0
go get: github.com/caddyserver/caddy/v2@v2.3.0 requires
github.com/dustin/go-humanize@v1.0.1-0.20200219035652-afde56e7acac: invalid pseudo-version: git fetch --unshallow -f origin in /var/lib/nethserver/home/dan/go/pkg/mod/cache/vcs/17fdefb1e921a172c3f2f6b61872a0d235c8c8a670d821d79d6b6ec4828bfe89: exit status 128:
fatal: git fetch-pack: expected shallow list
Predictably, go build then fails:
➜ caddy go build
go: finding module for package github.com/caddyserver/caddy/v2/modules/standard
go: finding module for package github.com/caddyserver/caddy/v2/cmd
go: downloading github.com/caddyserver/caddy v1.0.5
go: found github.com/caddyserver/caddy/v2/cmd in github.com/caddyserver/caddy/v2 v2.3.0
go: found github.com/caddyserver/caddy/v2/modules/standard in github.com/caddyserver/caddy/v2 v2.3.0
go: github.com/caddyserver/caddy/v2@v2.3.0 requires
github.com/dustin/go-humanize@v1.0.1-0.20200219035652-afde56e7acac: invalid pseudo-version: git fetch --unshallow -f origin in /var/lib/nethserver/home/dan/go/pkg/mod/cache/vcs/17fdefb1e921a172c3f2f6b61872a0d235c8c8a670d821d79d6b6ec4828bfe89: exit status 128:
fatal: git fetch-pack: expected shallow list
Google finds this issue which seems similar, but it also only appears to affect Go 1.13, while I’m running 1.15:
➜ ~ go version
go version go1.15.5 linux/amd64
Another apparent solution to that issue mentioned upgrading git (I’m running 1.8.3.1, the latest available for CentOS7), but that would break other tools on my build system. Other thoughts on this?
(1) because I didn’t know it was there–there’s no mention of it on the Download page, and the only packages listed with the GitHub release are .deb, not .rpm; (2) because I want to include the DNS plugins that I suspect would not be included in the “official” one (though not having installed it yet–as I just learned of it–I can’t say for sure).
I wasn’t really wanting to build the build tool each time I built the RPM, but it seems a reasonable diagnostic. But it doesn’t seem that xcaddy’s README has complete installation instructions; it only has you run go get -u github.com/caddyserver/xcaddy/cmd/xcaddy. But once that was addressed (go build -o ./xcaddy github.com/caddyserver/xcaddy/cmd/xcaddy), it looks like I’m getting the same sort of issue:
➜ caddy ./xcaddy build --output ./caddy
2021/02/01 09:43:16 [INFO] Temporary folder: /tmp/buildenv_2021-02-01-0943.444452034
2021/02/01 09:43:16 [INFO] Writing main module: /tmp/buildenv_2021-02-01-0943.444452034/main.go
2021/02/01 09:43:16 [INFO] Initializing Go module
2021/02/01 09:43:16 [INFO] exec (timeout=10s): /usr/bin/go mod init caddy
go: creating new go.mod: module caddy
2021/02/01 09:43:16 [INFO] Pinning versions
2021/02/01 09:43:16 [INFO] exec (timeout=0s): /usr/bin/go get -d -v github.com/caddyserver/caddy/v2
go: github.com/caddyserver/caddy/v2 upgrade => v2.3.0
get "google.golang.org/protobuf": found meta tag get.metaImport{Prefix:"google.golang.org/protobuf", VCS:"git", RepoRoot:"https://go.googlesource.com/protobuf"} at //google.golang.org/protobuf?go-get=1
go get: github.com/caddyserver/caddy/v2@v2.3.0 requires
github.com/dustin/go-humanize@v1.0.1-0.20200219035652-afde56e7acac: invalid pseudo-version: git fetch --unshallow -f origin in /var/lib/nethserver/home/dan/go/pkg/mod/cache/vcs/17fdefb1e921a172c3f2f6b61872a0d235c8c8a670d821d79d6b6ec4828bfe89: exit status 128:
fatal: git fetch-pack: expected shallow list
2021/02/01 09:43:19 [FATAL] exit status 1
You’re right, the download page should cross-link to the “install” page as well.
Regarding github releases, we use a tool called goreleaser to build our binaries, and since we have our own apt repo (not affiliated with debian/ubuntu) it’s easiest to build via CI pipeline. The .rpm via COPR is maintained separately, not via our CI pipeline, by Carl George.
Managing distribution is complicated business.
Yeah, that’s correct. The recommended way to build from source is to use xcaddy, or if you don’t want to set up a Go environment, using the download page on the website (which just uses xcaddy under the hood to produce builds).
You can see the instructions here:
You can grab the latest release of xcaddy from here:
Yeah, so it seems like your outdated version of git is the problem, according to this:
That link gives instructions for using xcaddy to build Caddy, not instructions to build xcaddy–which xcaddy’s README also lacks.
But it appears it’s impossible to use xcaddy under CentOS7 unless you’re willing to get git from a third-party repo, in the process breaking any other package that depends on git (because for some odd reason, the replacement package is called git222 rather than git, it isn’t marked as providing git, so therefore removing git and replacing it with git222 removes anything that depends on git). If that’s the case, it is what it is, but somewhat unfortunate.
That’s not Caddy’s fault though, that’s just how Go behaves. Unfortunately we can’t really do anything about that. Maybe use docker to make your builds for you, or something, so you’re isolated from your weirdly configured platform. See Docker for instructions on using the builder image variant.