Hi… how long before a release is available for download? I know I can build it myself but easiest to download from site with the plugins I need. I did set upgrade to true but it only built 2.4.0 still as well…
Depends on the installation method you’re using.
The debian repo has it available immediately due to being pushed directly from github via the CI release process, there’s also builds available in the Releases page on github.
All other installation methods require manual work though.
- The
/download
page needs @matt to change a thing by hand right now (I think he just forgot to do it tonight? but he’s also working on a big rewrite of the download page which should make this unnecessary I think) - The docker official image requires a couple PRs by Dave, first to the caddy-docker repo (which we tried to automate but that broke) then one to the GitHub - docker-library/official-images: Primary source of truth for the Docker "Official Images" program repo which must be done manually (I don’t think we could automate creating a PR on a repo we don’t own tbh)
- Builds for RPM, Alpine, Arch repos are handled by hand by the package maintainers of those repos – we ping them when we do releases but they’re busy people too
Guilty as charged. The download page should actually pick it up IF I clear the build cache – you’re probably getting a cached build because the configuration is the same. But any new builds will automatically use the latest version. I’m currently reworking the download page, pretty intensely at the moment, in preparation for other future site upgrades, so I’m a bit behind right now, but it’ll be much better when it’s all said and done.
Ok so I downloaded it again and it’s the same file as I downloaded for 2.4.0 a month ago. It’s not downloading 2.4.1 (From the download page with the lego-deprecated plugin for Linux AMD64)
I also used the upgrade flag and all 3 files are identical - Checking the SHA-1 checksum…
Bit of a hack, make a URL by hand like this:
https://caddyserver.com/api/download?os=linux&arch=amd64&p=github.com/caddyserver/caddy/v2@v2.4.1
But that’s not going to make it with the lego-deprecated dns plugin otherwise I would have already just downloaded it from Github
Just add another &p=
to that URL, for each additional plugin you need.
so:
https://caddyserver.com/api/download?os=linux&arch=amd64&p=github.com/caddyserver/caddy/v2@v2.4.1&p=github.com/caddy-dns/lego-deprecated
Well that seems to have worked. I’m going to build via xcaddy as well just for shits and giggles and see if I end up with the same result…
xcaddy
is the same as that, except without the build cache layer that sits in front of it. So it will work.
So… couple of things.
Downloaded go for linux AMD64 and installed via instructions here Download and install - The Go Programming Language no problems
I then installed xcaddy from the debian instructions:
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/xcaddy/gpg.key' | sudo apt-key add -
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/xcaddy/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-xcaddy.list
sudo apt update
sudo apt install xcaddy
This installed xcaddy to /usr/bin and it took forever to find it. I then copied it to /usr/local/go/bin otherwise it couldn’t find xcaddy. I note the website says to make sure xcaddy directory is in the path but the github I was using to install xcaddy didn’t mention that.
I then ran:
xcaddy build \
--with github.com/caddy-dns/lego-deprecated
Maybe this makes it clear for someone else…
Which created caddy in my home directory. It has a different checksum to the one I got via the URL hack above… I guess one has an extra CR or something like that in it and either will work though?
Is /usr/bin
not in your user’s PATH? It should always be…
You could’ve just ran it with /usr/bin/xcaddy build ...
Yep, that’ll work.
FYI, you can follow these instructions to get all the meta files from the Caddy debian repo, but with your custom build (the instructions haven’t been pushed to the docs site yet, but will be in not too long):
My Path is
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/go/bin
So it’s there but couldn’t run it.
david@debian-pm:~$ which xcaddy
/usr/bin/xcaddy
david@debian-pm:~$ xcaddy
go: cannot match "all": go.mod file not found in current directory or any parent directory; see 'go help modules'
2021/05/21 10:37:21 [ERROR] exec [go list -m -f={{if .Replace}}{{.Path}}=>{{.Replace}}{{end}} all]: exit status 1:
david@debian-pm:~$
Maybe I misinterpreted the message and it was a go.mod it couldn’t find…
I was trying xcaddy version - maybe that’s not a valid command - wanted to be sure it was installed but the error threw me. Just removed the xcaddy from the go directory and it works when i run the build command.- anyway it’s less than intuitive IMO.
Thanks for the link to the new docs.
Yeah, xcaddy
without any options is meant as a development tool for plugin authors, for building the contents of the current directory as a plugin against the latest version of Caddy. That’s working as expected (albeit confusing for non-devs, I admit).
This topic was automatically closed after 90 days. New replies are no longer allowed.