[Feature Request] Please consider tagging this repo to Caddy versions

[ubergeek77]

I hesitate to file this issue, as my intent is to not be petty or passive aggressive, and it will probably be received that way due to how the previous discussion ended. However, @mholt, I think you missed the intent of my comment before the discussion was locked, and I believe this is a valid request for myself and many users.

Indeed, caddy:latest should not be used in production, but this plugin does not currently do any sort of version tracking at all. That means it is not possible to do this:

FROM caddy:2.7.2-builder-alpine AS builder

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

FROM caddy:2.7.2

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

Instead, I must do this:

FROM caddy:2.7.2-builder-alpine AS builder

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

FROM caddy:2.7.2

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

I could also omit the commit hash, but that will cause dependency issues the other way around.

Basically, there will be people who will want to use this plugin on a specific version of Caddy, and you do not provide a tagging scheme for those people, short of digging through the commit history of this repo, and identifying the best version to use on a version of Caddy.

You stated you do not use Docker, but this issue is not unique to Docker. It is no different than a user wanting to run xcaddy build on their own.

Will a tagging scheme for this repo be considered? Or at the very least, a table of commit hashes corresponding to the oldest versions of Caddy they are compatible with?

If users are going to be expected to dig through the commit history to do versioning, then I'd like that to be explicitly stated so there is no confusion.

[mholt]

That means it is not possible to do this:

It looks like you simply specify a commit hash instead of a tag. What's the problem exactly?

You stated you do not use Docker, but this issue is not unique to Docker. It is no different than a user wanting to run xcaddy build on their own.

xcaddy build --with github.com/caddy-dns/cloudflare works fine for me. :man_shrugging: So it apparently is different.

If users are going to be expected to dig through the commit history to do versioning, then I'd like that to be explicitly stated so there is no confusion.

:thinking: How is that different than digging through tagged releases? That'd actually end up being more clicks.

I'm not opposed to tagging, but I don't really see the benefits or necessity of it when the latest commit is, 99.99999% of the time, all anyone needs.

[ubergeek77]

It looks like you simply specify a commit hash instead of a tag. What's the problem exactly?

Finding the correct commit hash to use is the problem. Instead of being able to bump the version to a known Caddy version, users are required to come here, click on the commit history, and investigate the correct hash to use for their use case.

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

This only works because the build is grabbing the version of Caddy to use from this repo's go.mod and building with that. In Docker, this breaks the build. Outside of Docker, it forces the user to use whatever version is specified in go.mod, instead of the version they actually want to use.

Anything can happen with this sort of thing. Maybe a newer version of Caddy has a bug impacting some users, or maybe Caddy 3.x comes out and people want to remain on 2.x due to breaking changes. Whatever the reason, people should have a supported way to use this plugin at a specific version of Caddy that doesn't involve trying to find an undocumented commit hash.

🤔 How is that different than digging through tagged releases? That'd actually end up being more clicks.

I don't think you are understanding what I'm suggesting. I am suggesting a tagging scheme where this repo's tags correspond to the version of Caddy it's expecting to be compatible with.

If caddy-dns/cloudflare at a certain commit is expecting to use Caddy 2.7.3, then the tag for that commit, at this repo, should be exactly 2.7.3.

In other words, whatever version is specified here:

https://github.com/caddy-dns/cloudflare/blob/74f004e1c1ab9056288f0baf3cd4b0039d6c77f3/go.mod#L6

...should be the tag used for this repo.

This will allow my first example, where I do caddy-dns/cloudflare@2.7.3, to become possible.

I don't really see the benefits or necessity of it when the latest commit is, 99.99999% of the time, all anyone needs.

This is akin to saying use the equivalent of :latest for this plugin, which is something Caddy already recommends you avoid doing for production 😉

And as I've shown, this will greatly reduce all the issue noise you receive when there is a delay in Docker Image publication, which is understandable when dealing with Docker Hub.

[StudioLE]

In other words, whatever version is specified here:

https://github.com/caddy-dns/cloudflare/blob/74f004e1c1ab9056288f0baf3cd4b0039d6c77f3/go.mod#L6

...should be the tag used for this repo.

It's not necessarily quite that simple. How would you go about tagging two separate releases of caddy-dns/cloudflare that both depend on Caddy v2.7.3?

I'm not familiar with go but it seems this logic is just using go's module implementation so surely it has some in built dependency management for this kind of conflict?

[WillScott73]

I'm assuming that this discussion pertains to the issue that I'm having right now, without a clue as to how to resolve it?

[mholt]

Sigh. These repeated issues are throwing people off-track.

If you are having trouble building this plugin currently with Docker, please see https://github.com/caddyserver/caddy-docker/issues/307 for discussion and workaround.

Temporarily locking this discussion so we can direct people to the solution rather than away from it.

[mholt]

To reply to the actual issue at hand, though:

I don't think you are understanding what I'm suggesting. I am suggesting a tagging scheme where this repo's tags correspond to the version of Caddy it's expecting to be compatible with. If caddy-dns/cloudflare at a certain commit is expecting to use Caddy 2.7.3, then the tag for that commit, at this repo, should be exactly 2.7.3.

I don't think that will solve the problem you're having. The problem is that the Docker container requires a manual review process which takes longer, and that version isn't always in sync with every plugin's go.mod. (So even if we do use a tag scheme like you're suggesting, every plugin would have to do this in order to be effective.)

And there's this point by @WillScott73 :

It's not necessarily quite that simple. How would you go about tagging two separate releases of caddy-dns/cloudflare that both depend on Caddy v2.7.3?

I agree this is not really tenable. We cannot reuse tags with different hashes. It will break the security checks for Go's module tooling, which mitigates supply chain attacks.

In general, there is a many:1 ratio of commits/tags that are expected to work with any given version of Caddy. So we can't assume 1:1 tag scheme like what you're proposing.

This is akin to saying use the equivalent of :latest for this plugin, which is something Caddy already recommends you avoid doing for production wink

This package, which is essentially finished, is very different from Caddy itself which has lots of moving parts. This package isn't what broke: it was a separate tooling problem that needs to be handled downstream.

Again, sorry for the inconvenience, hopefully this helps clear things up.