push wheel-built binaries to GH release

[j2kun]

This PR updates the release process so that the heir-opt and heir-translate binaries built during PyPI wheel generation are pushed to the GH release instead of the binaries built during the release.yml.

[edit]: As a cleanup-byproduct, I merged the wheels.yml and release.yml workflows into a single (release.yml) workflow that handles all the steps.

Context: I knew that the existing binaries released to GH were problematic. For one, they are built using whatever glibc is available on the GH runner, and so when you try to run these binaries on certain systems and CI environments, you get errors like

heir-opt: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found
heir-opt: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found
heir-opt: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found

Because the PyPI wheels are built in manylinux_2_28 containers, they are forced to have glibc 2.28 which is the most widely supported glibc version. So we should always be uploading those binaries to the GH release.

The reason this came up now is that I am releasing rules_heir on the BCR, and for rules_heir@v0.0.4 I added openfhe and lattigo macros, and the resulting BCR presubmit integration tests won't run because the CI env there has an older glibc. In particular, rules_heir was (and still is) fetching its heir-opt and heir-translate binaries from google/heir's GH release.

At the same time, I also want rules_heir to support other platforms, not just linux_x86-64, so this PR will ensure that there are supported heir-opt and heir-translate binaries on the top three platforms (same as the PyPI wheels) that I can fetch into rules_heir.

Once I merge this PR and push a new release of HEIR, j2kun/rules_heir#5 will be updated to have the latest binary urls and shasums.

Along the way, I felt that, based on our gradually reduced support for CGGI, the GH release should no longer have the abc_bin or techmap.v files attached. Users who want to do CGGI can build HEIR from source or use the PyPI wheel.

[j2kun]

As with all GHA PRs, I don't have a good way to test this before merging.

[AlexanderViand]

Ohhh, this a great idea ❤️ And, yeah, not being able to test GH actions easily is such a pain.... I'm trying to wrap my head around this, but struggling a bit:

• If the binaries are now coming from the wheels, why is release.yml still doing a bazel build? If it's there to ensure we don't publish broken/non-building releases, I feel like that should be caught/handled by the wheels workflow already?

• Doesn't GitHub auto-generate the source archives? Why do we now manually generate them? I have been informed by 🤖 that it's probably because of BCR stuff, if that's the case I think it'd be good to add a comment explaining this."

• How does the wheels run get triggered by release? I asked the 🤖 and it says the softprops/action-gh-release run will have a default GITHUB_TOKEN and therefore its tag creation will not trigger new workflows, such as wheels.yaml. Instead, wheels.yaml should apparently run on: workflow_run: workflows ["release"], types ["completed"]?

[j2kun]

All good questions

• If the binaries are now coming from the wheels, why is release.yml still doing a bazel build? If it's there to ensure we don't publish broken/non-building releases, I feel like that should be caught/handled by the wheels workflow already?

The release workflow still creates the GH release so the wheels workflow has somewhere to upload the wheels, so I wanted the build to succeed before that step. In theory we could merge the two workflows into one and create the release at the very end. I'm open to this.

• Doesn't GitHub auto-generate the source archives? Why do we now manually generate them? I have been informed by 🤖 that it's probably because of BCR stuff, if that's the case I think it'd be good to add a comment explaining this."

GH by default doesn't generate immutable archives with a shasum, which is a good practice and which BCR doesn't strictly require, but prefers.

• How does the wheels run get triggered by release? I asked the 🤖 and it says the softprops/action-gh-release run will have a default GITHUB_TOKEN and therefore its tag creation will not trigger new workflows, such as wheels.yaml. Instead, wheels.yaml should apparently run on: workflow_run: workflows ["release"], types ["completed"]?

I believe it does not, and I wasn't sure how to get it to reliably trigger on completion of the release workflow. We had a few attempts at this over the last month and didn't get it to work. This may be another case in favor of merging the two workflows.

[AlexanderViand]

This may be another case in favor of merging the two workflows.

That does sound like the right call!

[j2kun]

Ok, I updated the PR to merge the two workflows. Same caveat as before: can't really test it before merging and will cut a release tomorrow to test it properly.

[AlexanderViand]

👍 Let's see what happens :)

[asraa]

crossing my fingers this will work otherwise!