Skip to content

Conversation

@DavidSpickett
Copy link
Collaborator

@DavidSpickett DavidSpickett commented Nov 12, 2025

For the 21.x release, download links were supposed to be revealed once all the release builds had completed. In reality, MacOS never had a successful build so I had to hand edit the release messages.

This PR fixes this by focusing instead on what is in the release assets.

  1. Links are now built from a format string, with the linked files being format arguments for that string. This is a balance between ease of editing the format, and having the file names for use later.

(I tried regex-ing file names out of the final links, which can work but is error prone and will be hard to debug in production)

Here's an example line:

  <!-- LINUX_X86 * [Linux x86_64](https://github.com/llvm/llvm-project/releases/download/llvmorg-vX.Y.Z-1/LLVM-vX.Y.Z-1-Linux-X64.tar.xz) ([signature](https://github.com/llvm/llvm-project/releases/download/llvmorg-vX.Y.Z-1/LLVM-vX.Y.Z-1-Linux-X64.tar.xz.jsonl)) -->
  1. uncomment_download_links now looks at the release assets to decide whether to reveal a given link line. If all the files that line links to are present, it can be revealed.

This means we can still run this at the end of release-tasks.yml, where it will be atomic.

Initially I was going to accumulate the statuses from the release build matrix job, but this does not seem to be possible (https://github.com/orgs/community/discussions/17245).

Workarounds for this often include uploading artifacts from each job, which for us, is the same as checking the release's assets.

This process is done for all assets we would like to link to, not just the ones currently built in GitHub.

So if some become automatically built, they will "just work". If we want to hand edit the links in, that's still an option because the full links are in the release message, but hidden from view.

As we are looking for <!-- SOME_TAG, the script can be run multiple times on the same release and it will not try to edit anything already revealed.

As it's possible no link lines have all their files, the text immediately after the links has been updated to make sense when there are no links.

For the 21.x release, download links were supposed to be revealed
once all the release builds had completed. In reality, MacOS never
had a succesfull build so I had to hand edit the release messages.

This PR fixes this by focusing instead on what is in the release
assets.

1. Links are now built from a format string, with the linked files
   being format arguments for that string. This is a balance
   between ease of editing the format, and having the file names
   for use later.

   (I tried regex-ing file names out of the final links, which
   can work but is error prone and will be hard to debug in
   production)

2. uncomment_download_links now looks at the release assets to
   decide whether to reveal a given link line. If all the files that
   line links to are present, it can be revealed.

   This means we can still run this at the end of release-tasks.yml,
   where it will be atomic.

   Intially I was going to accumulate the statuses from the release
   build matrix job, but this does not seem to be possible
   (https://github.com/orgs/community/discussions/17245).

   Workarounds for this often include uploading artefacts from each
   job, which is for us, the same as checking the release's assets.

This process is done for all assets we would like to link to, not
just the ones currently built in GitHub.

So if some become automatically built, they will "just work". If
we want to hand edit the links in, that's still an option because
the full links are in the release message, but hidden from view.

As we are looking for "<!-- SOME_TAG", the script can be run multiple
times on the same release and it will not try to edit anything already
revealed.

As it's possible no link lines have all their files, the text
immediately after the links has been updated to make sense
when there are no links.
" These files are not present:",
files.difference(release_assets),
)
print(" Link line will remain hidden.")
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm leaving the prints in for logging purposes, they're not leftover debug prints.

Some example output:

Found release assets:  {'clang+llvm-vX.Y.Z-1-aarch64-pc-windows-msvc.tar.xz', 'LLVM-vX.Y.Z-1-Linux-X64.tar.xz.jsonl', 'LLVM-vX.Y.Z-1-Linux-X64.tar.xz'}
Found link line "LINUX_X86":
  Files required: {'LLVM-vX.Y.Z-1-Linux-X64.tar.xz.jsonl', 'LLVM-vX.Y.Z-1-Linux-X64.tar.xz'}
  All files present, revealing link line.
<...>
Found link line "WINDOWS_ARM64":
  Files required: {'clang+llvm-vX.Y.Z-1-aarch64-pc-windows-msvc.tar.xz.sig', 'LLVM-vX.Y.Z-1-woa64.exe', 'LLVM-vX.Y.Z-1-woa64.exe.sig', 'clang+llvm-vX.Y.Z-1-aarch64-pc-windows-msvc.tar.xz'}
  These files are not present: {'clang+llvm-vX.Y.Z-1-aarch64-pc-windows-msvc.tar.xz.sig', 'LLVM-vX.Y.Z-1-woa64.exe', 'LLVM-vX.Y.Z-1-woa64.exe.sig'}
  Link line will remain hidden.

Either this will never go wrong and no one will see any of it, or, more likely, it will, and this will be helpful to have in the log.

@DavidSpickett
Copy link
Collaborator Author

The script is currently run from here:

uncomment-download-links:

Right after the release binaries jobs have finished (with whatever status).

@DavidSpickett
Copy link
Collaborator Author

Below is a set of generated links for a release vX.Y.Z-1. So you can see that the format is the same as before. If you were to manually edit the release message, you'd have the full link content there. No need to re-run the script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant