Generate `deno_versions.bzl` from GitHub API data
@alexeagle I already have a script that can do all of the heavy lifting with the API and checksums, but not sure on how it should be used. My thinking is something like this:
- GitHub Actions workflow automatically runs the script on a normal schedule (e.g. weekly)
- Script gets updated release and hash info and regenerates
deno_versions.bzlfile (possibly exit early if last version added to repo is same as current version) - If there are changes to the file, commit the changes to the repository
Things I'm not sure about:
- How many versions should we let the file accumulate, and how often should it add new ones?
- How should the changes be committed? Maybe git-auto-commit?
- Should this also create a new release/tag whenever it commits a change? Using an untagged version of Bazel rules is awkward.
In other repos I manage like rules_nodejs we have a bot send us PRs when there's a new version to mirror, e.g. https://github.com/bazelbuild/rules_nodejs/blob/stable/.github/workflows/update-nodejs-versions.yml I think this works well enough, the volume of PRs is low enough that it's not much burden.
I think the mirroring should be orthogonal to the release process for this ruleset.
Awesome! This is super similar to the deno script I have, so I could make some small modifications to it to have behave exactly the same.
Migrated to https://gitlab.com/aspect-build/rules_deno/-/issues/12
SoT is back on GitHub