PyGithub deprecated this a while back. An earlier patch attempted to fix
all the deprecations, but it looks like my grep expression missed a
bunch of cases. This patch should catch the remaining ones (minus libc++
which have been split for review by libc++ maintainers).
These are no longer provided as of llvm 22:
https://discourse.llvm.org/t/llvm-22-1-0-rc1-released/89479
> Please note: since the last release the subproject tarballs have been
> removed and are no longer provided. See RFC: Do "something" with the
> subproject tarballs in the release page for more details.
There are now only llvm-project and llvm-test-suite archives.
For the 21.x release, download links were supposed to be revealed once
all the release builds had completed successfully. 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
after the release build step has finished (in whatever state that might
be).
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)) -->
```
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 will be revealed. This means we can run this at the end
of release-tasks.yml, where it will be atomic.
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.
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 adds download links to the GitHub release pages for common
platforms. The automatically built packages' links are automatically
revealed once the builds are complete. For packages built by hand,
hidden links are included in the text for release uploaders to reveal
later.
The approach taken:
* "LLVM x.y.z Release" becomes the title for this links section.
* Automatically built packages are commented out with special markers so
we can find them to uncomment them later.
* There is placeholder text for the time between release creation and
release tasks finishing.
* Hand built packages have release links but these will need to be
un-commented by release uploaders.
* I have used vendor names for the architectures, that casual users
would recognise.
* Their signature file is linked as well. I expect most will ignore this
but better to show it to remind people it exists.
* I called it "signature" as a generic term to cover the .jsonl and .sig
files. Instructions to use these were added to the text in a previous
change.
Background:
https://discourse.llvm.org/t/rfc-explaining-release-package-types-and-purposes/85985
So that users can understand which they should use, particularly for
Windows. The original text about community builds is kept, after
explaining the main release package formats.
In addition, explain how to use gpg or gh to verify the packages.
After aa02002491333c42060373bc84f1ff5d2c76b4ce we started passing the
user name to the create_release function and this was being interpreted
as the git tag.
The default GitHub token does not have read permissions on the org, so
we need to use a custom token in order to read the members of the
llvm-release-managers team.
* Split out the lit release job and the documentation build job into
their own workflow files. This makes it possible to manually run these
jobs via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
Summary:
This script can be used for uploading relases sources and binaries
to github.
Reviewers: hans
Reviewed By: hans
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64841
llvm-svn: 366977
