www/caddy-custom: frequent build issues because CADDY_CUSTOM_PLUGINS doesn't specify specific versions

[maurice-w]

I'm frequently having issues with building caddy-custom because the plugins aren't pinned to specific versions in the opnsense/tools make.conf.

Plugins get updated and become incompatible to the caddy-custom version built by a specific opnsense/ports version. This can happen within days or even hours of tools and ports getting tagged. For example, mholt/caddy-l4 bumped caddy to 2.11.3 just a day after the opnsense/ports 26.1.8 tag was created (which builds caddy 2.11.2).

I'd suggest pinning the plugin versions in CADDY_CUSTOM_PLUGINS, but am open for other suggestions.

[Monviech]

I already did that before in the past but it's a lot of micro management so I removed commit hashes from these packages.

They (optional packages) do not have tagged versions, individual commit hashes could pin them, but the problem just shifts the other way since we can miss important updates or the main caddy version updates and the older commit hashes become incompatible. This is one of the main issues with go.

It goes well most of the time, unfortunate timing can always happen.

If frequent means once per year its okay in my book:
47e9c94

[maurice-w]

While it works more often than not, build issues caused by this are far more frequent than once a year. I just didn't report them every time because I know how to work around it since you told me when this happened the first time. :)
And I'm not the only one affected. It depends on when you build it. Without pinning, it's impossible to achieve reproducible builds. Even if you're not running into a build issue, you might end up with building different versions of the caddy-custom plugins without even noticing.

As far as I'm aware, pretty much everything across the OPNsense build ecosystem uses tags and commit hashes. Why would doing the same for the caddy-custom plugins be micro management?

[Monviech]

The main issue is that caddy plugins have no version tag, and only master is the known good version.

While I could add commit hashes and bump them every week, it's just a workaround for the main issue.

Over the time I have removed most of these plugin dependencies and only the handful that remains is still relevant. Over time it looks like Caddy will e.g. absorb the layer-4 plugin to become a mainline feature, which also solves this topic here.

For now I won't change anything.
If what you offer has too many issues with caddy, feel free to exclude it from the arm build for now.

[Monviech]

As side note, I also offer a caddy version where everything can be built by the user themselves, so people who rely on caddy can still build the exact version they want, even if it's not provided directly in the image.

https://github.com/Monviech/os-caddy