Better Support Release Management

[blaggacao]

To work around the limitation of NixOS/nix#3838.

In CI only - to support RM

• Preprocess any CI run with something like nix eval --raw .#sourceInfo > sourceInfo.json && git add sourceInfo.json
• jq '. += { ref: $GITHUB_REF }' <<< sourceInfo.json > sourceInfo.json _(pseudocode)
• Let std pick this file up via builtins.pathExists and restore the original sourceInfo (now with ref) into inputs.self.sourceInfo & inputs.self.

Now a Release workflow, wherever a tag value should be used instead of a commit would be as simple as: inouts.self.ref or inputs.self.rev.

Additional Considerations

Since a release is not expected to be cut outside of CI, the limitation that this is a CI-only contract is not only fully acceptable, but may be even regarded as a feature.

Of course in GH actions, we can check and condition the logic on if a tag is also a release and other such niceties.

[blaggacao]

Even more wild ideas

We have the problem of sub-package rebuilds triggerd by laconic commits via self.rev.

At least in CI, we may be able to create an environment where ${src}/HEAD is read if it exists providing access to a git log --pretty=format:'%h' -n 1 -- subfolder > subfolder/HEAD-generate rev that represents the last known commit into that particular subfolder.