guix: Added guix-shasums script for gathering and formatting build output checksums #33465

When a PR requires proof of Guix builds (sha256sums), the PR author or reviewer uses a not well documented command to collect the sha256sums of build outputs or manually gathers them from files:

guix describe
uname -m
find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum

This PR introduces a guix-shasums script that gathers all the sha256sums from the output directories and either outputs them on the screen or formats them as Markdown formatted output (to the screen or a file) for easy inclusion in a PR or PR comment. The script is based on the commonly used command (as displayed above)

Example of Markdown formatted output:

<details>

Guix Build Output

Host architecture: aarch64 Commit: 7d846e5aeae6

File Checksums

</details>

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33465.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Guix Build Output

Host architecture: aarch64 Commit: a6cdf0368194

File Checksums

~0. I'm not sure if 90 lines of bash, is better than documenting and using the one-liner? Note that the markdown also bloats the size of the comment dramatically (https://github.com/bitcoin/bitcoin/pull/33465#issuecomment-3325505399), compared to what is currently used (https://github.com/bitcoin/bitcoin/pull/33185#issuecomment-31968446200 (and makes it harder to copy paste).

~0. I'm not sure if 90 lines of bash, is better than documenting and using the one-liner? Note that the markdown also bloats the size of the comment dramatically (#33465 (comment)), compared to what is currently used (#33185 (comment) (and makes it harder to copy paste).

Same from me.

Firstly, thanks for sharing that one-liner. I looked everywhere for it and ended up doing it manually 😊

Approach NACK from me as well, since I think the compact code block is more legible due to not having newlines in the markdown table cells. I don't mine the one-liner in its own script, but having it documented seems necessary.

closing in favour of #33472

Thanks for the feedback