Open bushvin opened 3 months ago
Wow. This is a great bug! Thanks for the extra diagnostics on the hashes.
I know exactly why this is happening. FoundryVTT made the decision to not use semver a couple of years ago. The releases are only identified by a release
and build
. e.g., 12.331
or 11.315
.
But in reality, when downloading the distribution archives from CDN the, release
component isn't even used in their URLs, only the build
. You can see this in your logs:
ReleaseURL | 2024-08-27 10:48:17 | [info] Fetching presigned release URL for build 331...
Which is generated by this code:
Which leads exactly to the behavior you are seeing. I'll have to think of a way to validate the release
/ build
tuple to avoid this problem. Stay tuned...
See:
Bug description
When speciying an invalid version and build number of FoundryVTT when spinning up a container, the latest version of Foundry VTT is downloaded and installed
This has been happening to me, for a while now, but I only noticed today. Every time I updated to the latest version, I mistakenly used version 11, but it would download version 12. According to the FoundryVTT Releases page 11.328, 11.330 and 11.331 do not exist.
The sha512sum has confirms the archives are identical
Steps to reproduce
FOUNDRY_VERSION
environment variable, egFOUNDRY_VERSION='11.331'
Expected behavior
I expect the process to complain about a non-existing foundry version and come to a grinding halt
Container metadata
Relevant log output
Code of Conduct