Perhaps an elegant approach is to work with two branches,
one containing the source templates (e.g. main) and another containing the release (e.g. release). The GitHub Action then compiles and commits only the resulting files to the release and tag that commit.

This way, we can always see what is part of a release and what is not.

chocolatey/choco#1803

Hello! Thank you for including Gleam in Chocolatey!

Unfortunately this package is now very out of date and no longer works after a fresh install. Because of this we in the Gleam community are getting almost daily complaints from people thinking that the language doesn't work due to this broken package, which is both causing support work and giving people a very poor first impression of the project.

The person who was previously maintaining this package is no longer able to do so as he no longer has a Windows computer.

Would we be able to deprecate or otherwise remove this package, or at least the already released versions? This would make things easier for us in the Gleam team.

Thanks,
Louis

According to @lpil in the Gleam discord, we can assume the new naming convention for Gleam releases is based on LLVM's / Rust's target triples.

This means we will always be able to replace %GLEAM_VERSION% here and get the correct result (e.g. with v0.24.0):

• Release ZIP: https://github.com/gleam-lang/gleam/releases/download/%GLEAM_VERSION%/gleam-%GLEAM_VERSION%-x86_64-pc-windows-msvc.zip
• SHA512 hash: https://github.com/gleam-lang/gleam/releases/download/%GLEAM_VERSION%/gleam-%GLEAM_VERSION%-x86_64-pc-windows-msvc.zip.sha512

This potentially allows for automating some tasks:

1. We could create a script that automatically replaces the version numbers in the package declaration.
2. We could also create a GitHub Action or bot that periodically checks for updates, runs aforementioned script and create a PR.

See: https://github.com/HarryET/gleam-chocolatey/actions/runs/4112491248/jobs/7097469762

Found that Chocolatey 504s from VMs will need to investigate