xcaddy doesn't build specified version #54
Comments
|
Hmm. Just a quick hunch, didn't dig, I think this is because the latest version of the Try building from this commit instead caddy-dns/cloudflare@eda8e5a |
|
ah, that would do it — didn't expect a plugin to force an upgrade to a beta version... 🙃 |
|
Yeah I didn't think that would happen either, but alas. Is there anything we can do about this @mholt? |
|
More evidence of the problem @mholt https://caddy.community/t/cloudflare-wildcard-subdomain-issue-docker/11751 |
|
@mholt my current theory is that because this repo isn't using tagged versions, the go mod resolver is causing the main Caddy module to get bumped up. I think we should tag caddy-dns/cloudflare@eda8e5a as Edit: Oof, nevermind that won't fix it either. I can reproduce the issue with the In particular, this line is the suspiscious one 🤔 Same thing happens when running like this too (basically identical output aside from some |
|
Okay. An idea - maybe we run |
|
Just tried with cloudflare -- if the command was: i.e. no version of Caddy specified, then |
|
So Francis and I have chatted about this a bit, and I've checked with Go tooling developers, and the consensus is that the Go tool is doing Minimum Version Selection (MVS), and that this is as expected. When building Caddy with version information, we need to make both Caddy core and all other plugins equal dependencies, meaning, MVS is applied equally to all of them. In this case, the cloudflare module requires v2.4.0-beta.1, and won't build with a Caddy version less than that, so MVS upgrades caddyserver/caddy in the go.mod from 2.3.0 to 2.4.0-beta.1. I can see why this is surprising/unexpected, but if you try to build the latest cloudflare plugin with v2.3.0 of Caddy core, it will not compile. Alternatively, specify an older version of the cloudflare plugin to get an older version of Caddy. I really appreciate the effort Francis (and you) have put into investigating this. But I'm not sure there is a good way to "fix" this -- basically, your command asks for something that won't compile, so Go is using MVS to make something that compiles instead. Feel free to continue discussion if needed; I'll close this though, as it seems to be working as expected. |
That's not true though, there is a solution to the build requested. MVS is doing the wrong thing and expelling the versions the previous commands asked it to use. Then it becomes a whack-a-mole situation. There's very clearly problem with either the Go module tooling, or with the approach we're taking to build. |
You can report that to the Go team if it's a bug in the tooling. As for the approach we're taking, by all counts using |
|
The problem is that |
|
Specifically regarding compatibility for the cloudflare plugin, this should now be resolved with the release of v2.4.0-beta.2, because it now properly has the libdns changes. If you still want to keep v2.3.0 though, you'll still need to use the older commit from the cloudflare repo, but xcaddy should now yield a build with v2.4.0-beta.2 because of caddy-dns/cloudflare@964e47d |
|
@mholt after speaking with Bryan C. Mills in the gopher slack, he pointed out a potential fix for this one. We could put the Caddy module/version in every For example (as per OP), we could run this: Erroring out would probably be better than allowing Caddy to upgrade, less surprising. The user could then have a chance to look into specifying an exact version of the plugin which is compatible with the older version of Caddy they're trying to target, i.e: |
* Prevent main Caddy module from upgrading from adding a plugin Fixes #54 * Better comment
I noticed xcaddy isn't building the specified version. If I specify, for instance,
xcaddy build v2.3.0 --with github.com/caddy-dns/cloudflare, I will getv2.4.0-beta.1instead.Here's the full build log:
...and the result:
This Dockerfile builds like this:
Same problem. I'm getting a beta build, not v2.3.0.
The text was updated successfully, but these errors were encountered: