`caddy upgrade` can downgrade Caddy

[basilhendroff]

trafficstars

Two issues:

1. Caddy upgrade downgrades to 2.3.0 2.. Backup file caddy.tmp is not created.

For details, please refer to https://caddy.community/t/caddy-2-4-0-beta-1-is-now-available/11519/17?u=basil

[xdevs23]

I'm guessing that the currently installed version is not checked in https://github.com/caddyserver/caddy/blob/f6bb02b303d4a24c6932fd832f7aa9de224b6833/cmd/commandfuncs.go#L582 and thus it just downloads the stable and installs it?

[mholt]

@xdevs23 Correct. The problem I'm currently wrestling with is, I'm not sure how to know what the new version will be before Go builds it. Without an explicit version passed into the go command, it uses latest which is kind of mysterious. We could just go ahead with the upgrade anyway and then check its resulting version string by running caddy version on the new binary, but this is not ideal if the resulting binary isn't even wanted in the first place; it adds pressure to the Caddy build server and takes time, etc.

As for:

Backup file caddy.tmp is not created

This is not actually the case, as discussed in the thread; it just gets cleaned up afterward after a successful upgrade. We can consider leaving it though.

[xdevs23]

Would it be possible to have an API endpoint (or maybe just a file in each GitHub release) containing its own version? For example:

https://github.com/caddyserver/caddy/releases/download/latest/version.txt

And then just parse the semver and check if it's newer (and not a version that has an extra string at the end like -beta.1)

This could be incorporated into the cmdUpgrade function so that checking for a new version is just a simple GET call with a text response.

[mholt]

Someone showed me how to get the version that the go tool will resolve to, like which version will be used when latest is specified:

$ go list -m -json github.com/caddyserver/caddy/v2@latest

[francislavoie]

@mholt apparently this could work too (note the >):

$ go list -m -json github.com/caddyserver/caddy/v2@>{current_version}

e.g.

$ go list -m -json github.com/caddyserver/caddy/v2@>v2.4.0-beta.1

But unfortunately I don't think we can actually test this right now because the latest version happens to be a stable version, since we just released v2.4.0 🤦‍♂️

[Caligatio]

I stumbled into this issue and accidentally opened duplicate issue #4159

Another thing to think about is whether a plugin update should ideally trigger an upgrade. I don't know how any of this is managed on the back-end but, if Caddy isn't updated and one of the requested plugins has an update, should this trigger an upgrade?

Would this be more easily solved with an upgrade web service? I'm imagining something like:

• Some server-side code periodically checks the Caddy and plugin repositories to see if there are new commits/releases.
• When upgrade is called, Caddy sends its version as well as all plugin versions to the upgrade web service.
• Said web service evaluates whether new versions of any of the requested parts are available:
  • If there are new parts, the web service acts as a pass-through to the current download system.
  • If there are no new parts, it returns something like a HTTP 304 to indicate no action is required.

[jant90]

I always run caddy upgrade before actually starting Caddy to keep my install up-to-date and I would like to see a version check before upgrading as well, so Caddy won't upgrade itself (and download the binary) on every run even when it already is on the latest version.