search

shibayan / keyvault-acmebot

Automated ACME SSL/TLS certificates issuer for Azure Key Vault (App Service / Container Apps / App Gateway / Front Door / CDN / others)
Apache License 2.0
891 stars 233 forks source link

deployment always uses `latest.zip` #728

Closed jimdigriz closed 2 months ago

jimdigriz commented 2 months ago

When deploying a specific tag the value of WEBSITE_RUN_FROM_PACKAGE is always the hardcoded value latest.zip:

https://stacmebotprod.blob.core.windows.net/keyvault-acmebot/v4/latest.zip

This means if I install v4.1.2 (ie. https://raw.githubusercontent.com/shibayan/keyvault-acmebot/v4.1.2/azuredeploy.json) I get the deployment template for it but I get (today) the codebase for v4.1.8 which could cause problems if the code expects the deployment it runs in to be different.

I have noticed though (through guesswork) you also upload as well as the other versions:

https://stacmebotprod.blob.core.windows.net/keyvault-acmebot/v4/4.1.8.zip

Could WEBSITE_RUN_FROM_PACKAGE be updated to reference the version it actually is tagged for?

shibayan commented 2 months ago

The reason for fixing latest.zip is to make sure that the latest version is always available to users, so we do not plan to fix it to a specific version.

Although a zip is created for each version, this is in case the user wants to manually revert to a specific version or fix it.

jimdigriz commented 2 months ago

Where are there instructions to revert? I cannot find any? Not sure how a user is to know they can do this?

As a final plea, it is somewhat 'unexpected' that when someone installs v4.1.2 they get (parts of) v4.1.8 installed. As a comparison, it would cause grief if the version specifiers in KeyVault.Acmebot/KeyVault.Acmebot.csproj were ignored.

Maybe my use case is special, but I deploy your project as a deployment template in my main template using a reference to the tag (well commit ID to get a free checksum) I want to install. By using a tag I would argue there is an expectation that is what should be installed?

This might explain a breakage I experience where for a deployment (using v3.6.0) that had been running fine for years then stopped working (caused by a separate DNS delegation problem). So I redeployed it and still nothing worked. I was forced to nuke all the resources of this project and redeploy using v3.6.12...then things worked. Could a v3.6.0 template running v3.6.12 code caused this?

If latest.zip is to stay, could some documentation be provided to explain that the user will need to manually carry maintaining their own template that replaces latest.zip with X.Y.Z.zip?