Caddy file metadata

Help
1

Just a quick question. I was wondering if the version of Caddy be inserted into the file metadata. I’m using Windows for my OS and if I run the PowerShell command

Get-Item .\caddy2.exe | FL *
PSChildName       : caddy2.exe
PSDrive           : C
PSProvider        : Microsoft.PowerShell.Core\FileSystem
PSIsContainer     : False
Mode              : -a---l
VersionInfo       : File:             C:\Users\cirvin\Desktop\Caddy\Caddy\caddy2.exe
                    InternalName:
                    OriginalFilename:
                    FileVersion:
                    FileDescription:
                    Product:
                    ProductVersion:
                    Debug:            False
                    Patched:          False
                    PreRelease:       False
                    PrivateBuild:     False
                    SpecialBuild:     False
                    Language:

The VersionInfo is does not show up. Is it possible to have this done as part of the release process? I’m wanting to use that metadata as a way to help create a roll out and testing method of the latest release of Caddy.

2

Hi, Craig! Welcome around :wave:

Could you file a GitHub issue for that as feature request? We can discuss it further.

3

Would you be able to use .\caddy.exe version instead?

4

I’d say yes. Will look into that as well

5

I think I can work with this:

$(.\caddy2.exe version) -match "^v\d{1,2}\.\d{1,2}\.\d{1,2}" |ForEach-Object {$matches[0] -replace "v"}
1 Like
6

FYI the version may contain an optional “special” value at the end, for example v2.0.0-rc.3

Here’s the regex I’m using in bash:

SEMVER_RE='[^0-9]*\([0-9]*\)[.]\([0-9]*\)[.]\([0-9]*\)\([0-9A-Za-z\.-]*\)'
7

will there always be a space between that and the hash start h1:?

8

Yes. $VERSION $HASH will always be the format

Example from RC3:

$ caddy version
v2.0.0-rc.3 h1:z2H/QnaRscip6aZJxwTbghu3zhC88Vo8l/K57WUce4Q=
9

Will rc’s always start with a “-”? or anything else you might do?

10

Just to be clear, the output of caddy version isn’t explicitly API, so I wouldn’t depend on it too heavily if I were you…

However, the version number is likely to always be a standard semantic version - there are lots of semver parsers available - I’d wager there’s probably one available for powershell that’ll avoid complication…

2 Likes
11

Got it. So what would be the suggested method to help version lock or version protect Caddy? My thought is that if we have 10 web servers and I want to try the latest version I can just drop the version onto 1 of the 10 servers. However when our scripts run the hashes wouldn’t match and the test version would become overwritten and source always wins the mismatch unless the destination version is higher.

12

I don’t really understand the whole process, but from my outsider, ignorant perspective, I would just say … “Don’t do that?”

What is the problem with the version in caddy version? How can we help?

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.