wildcards/latest for github release?

[ahornby]

Congrats on the release!

Any interest in contributions supporting wildcard/latest matching for github releases? e.g. specify a pattern like 7.0.* for bazel, call the github api to see what is available, then download the metadata (hash etc) and content for the latest one matching (currently 7.0.2)

This would allow using dotslash to replace "get and run latest matching X" usages of bazelisk and similar downloader/caching tools.

Essentially would be adding a "find url and other metadata" step for cases where people trust the release stream to do the right thing for them given the pattern

[bolinfest]

Hi @ahornby, if I'm understanding your question correctly, the answer is a definite no.

A key design principal of DotSlash is reproducibility. This is why you have to specify the hash and digest of the artifact.

If a DotSlash file could be defined to mean "run v7.0.* of Bazel," that would mean the behavior of that DotSlash file could change over time even if the content of the file does not change. That will absolutely not be supported.

[ahornby]

Is gh release support only present so the gh client can handle login for enterprise or private repos? For public repos the url for the artefact suffices if not doing any pattern matching

[bolinfest]

Yes, I think this is addressed directly in:

https://dotslash-cli.com/docs/dotslash-file/#github-release-provider

[ahornby]

Thanks. Perhaps a still immutable way to help people coming from a bazelisk 6.x style pattern matching workflow might be automating the check for matching releases and resulting edit of the dotslash files.

One could list the source release pattern in the dotslash file and have "dotslash update" or similar edit the file based on discovered size/version/hash/name metadata?

[bolinfest]

@ndmitchell is there anything about how we release buck2 internally that can be of use here?