Latest dependencies update broke caddy builder

[skarekrow]

It seems the required version tag 2.7.3 does not exist for caddy builder, it only goes up to 2.7.2 which was fine until #54 a little bit ago, my build is now failing with:

#0 20.14 2023/08/07 18:00:39 [INFO] exec (timeout=-2562047h47m16.854775808s): /usr/local/go/bin/go get -d -v github.com/caddy-dns/cloudflare github.com/caddyserver/caddy/v2@v2.6.4
#0 20.94 go: downloading github.com/caddy-dns/cloudflare v0.0.0-20230807034102-74f004e1c1ab
#0 21.36 go: github.com/caddy-dns/cloudflare@upgrade (v0.0.0-20230807034102-74f004e1c1ab) requires github.com/caddyserver/caddy/v2@v2.7.3, not github.com/caddyserver/caddy/v2@v2.6.4
#0 21.37 2023/08/07 18:00:41 [FATAL] exit status 1
------
failed to solve: executor failed running [/bin/sh -c xcaddy build --with github.com/caddy-dns/cloudflare]: exit code: 1

My Dockerfile looks like so:

FROM caddy:builder AS builder

RUN xcaddy build --with github.com/caddy-dns/cloudflare

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Thanks for the project!

[mholt]

There is already an issue for this in the correct repo: https://github.com/caddyserver/caddy-docker

Since they require manual curation and review, it may be a couple days, as usual.

[skarekrow]

Hmm seems related to https://github.com/caddyserver/caddy-docker/issues/307, not specifically this plugin's issue I guess 😓

[skarekrow]

@mholt interesting I haven't run into this before and I've ran this setup for a quite a while this way. It's a bit of a problem as this isn't tagged afaict, so I can't pin it to the older version of this plugin to get my build going.

[mholt]

Hmm. Can you not use a specific commit? It has to be a tag specifically?

[skarekrow]

It seemed totally happy to directly use a commit 🤦 it's just been a Monday. Sorry for the noise! I really love Caddy, great work!

[mholt]

No worries -- thanks for chiming in and double-checking! (Sorry for the inconvenience.)

[kleo]

Leaving example here for those still having trouble on build

Dockerfile

RUN xcaddy build --with github.com/caddy-dns/cloudflare@<commit>

or

RUN xcaddy build --with github.com/caddy-dns/cloudflare@a9d3ae2690a1d232bc9f8fc8b15bd4e0a6960eec

[ubergeek77]

This is breaking automation for a lot of people. And without a reliable tagging system, we can't safely tag to "the latest" or "the previous" version of this plugin to avoid version mismatches like this, without going through the commits manually (which isn't very automation friendly).

Would it be too much to ask that this version bump to 2.7.3 is reverted until the official Caddy image is updated to 2.7.3? I don't think it's a stretch to say that the overwhelming majority of Caddy users are Docker users.

[pallebone]

Hi I am directly affected by this bug and experienced downtime unfortunately due to it :( - would love to add my name to the people affected by this :)

[mholt]

@pallebone Why do you have to take your site down to build a static binary?

[pallebone]

Its part of a docker-compose setup and I only have a single cheap server running the bare minimum unfortunately - just 1 caddy docker. No load balancing due to costs.

[skarekrow]

This is how I found it as well :D since my NAS was actually the reverse proxy host and this is part of it's compose setup after I back it up for the night.

[ubergeek77]

Apologies @mholt, I didn't intend for users of my project to add to the discussion here.

He's using a project of mine that involves Caddy, and part of the autoconfiguration of Cloudflare involves building Caddy from source with the requisite plugins, this being one of them.

It currently fails, because I did not anticipate a scenario where this build could fail, it simply has not happened before in my years of using Caddy. And since the deployment process involves using build: in a Docker Compose project, there isn't really a graceful way to revert back to the previous config.

In the future, I will now have to lock the plugin to a single commit, which means I will need to manually manage Caddy versions, and manually investigate which commit hash to use, instead of allowing the script to always grab the latest version or a preset version. This means it is not possible to gracefully automate this. If this plugin were tagged to Caddy versions, I could at least find the latest available Caddy Docker image, and then use that version as a tag for this plugin. But right now, this requires manual intervention.

I'm not sure why the Docker image is stalled for 3 days (is that something I can help with?), but it would be nice if Caddy's version and this plugin could be managed by a single version tag (i.e. @2.7.2). It would greatly reduce the complexity of the current situation if it ever happens again.

[mholt]

Ah... I see. Thanks for explaining @ubergeek77.

This is why our Docker readme says:

note: never use the :latest tag in a production site

:innocent:

Sorry for the inconvenience that was caused.

One of the main advantages of Go programs is that they are static binaries that you can build anywhere, and deploy easily as a static binary (no containers needed, in fact! -- let me clarify that I realize that people use containers for multiple reasons, but I mean that Caddy is a self-contained binary that does not benefit from containerization in the sense that doing so often adds more failure surfaces than the simplicity the container hides).

I'm not sure why the Docker image is stalled for 3 days (is that something I can help with?)

I don't use Docker myself, so I don't maintain the Docker image -- our community does -- and I don't really know what goes into the updates. Note that all official Docker images (and ours is one such image), need manual review and approval before they get released -- that is Docker's policy.

This discussion is really off-topic for a Cloudflare DNS plugin repo, so I'm going to lock this issue and redirect any other productive discussion over to the caddy-docker repo here: https://github.com/caddyserver/caddy-docker/issues/307

Thank you!