Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
Test run of this on my own fork here: https://github.com/mdboom/cuda-python/actions/runs/21956196329/job/63420782798 |
The tag-push-trigger approach doesn't have that downside. According to what Cursor explained to me, we can even tag cuda-pathfinder, cuda-bindings, cuda-core concurrently and it'll all work. |
There was a problem hiding this comment.
I think this file alone (without the change in the other file) is composable with #1606.
- We run this new workflow to generate a tag
- The tag creation triggers the CI
There was a problem hiding this comment.
That works for me. It's a bit on the heavy-handed side just for the tagging, but if we fold in some easy safety features I can see good value:
- pull-down for: cuda-pathfinder, cuda-bindings, cuda-core
- pull-down for: bump patch, bump minor, bump major
- compute the version number
- validate that X.Y.Z-notes.rst exists
- validate that corresponding the nv-versions.json entry exits
That would prevent oversights like we had in the release of cuda-bindings 13.1.0 (missing release notes under cuda-python).
There was a problem hiding this comment.
@leofang: At a minimum we need to update this so it doesn't create an empty commit (which is no longer needed after #1606). And if we do that, we also have ways to fix the race condition problem.
The race condition is: I wanted to create a release, so I go to the page to trigger this workflow, and then someone else merges a PR while the workflow is waiting to run. Now we've made a release with unintended content.
If we require the user of this workflow to specify a commit hash to tag, we avoid the race condition.
FWIW, even those the GitHub UI for creating a release tag doesn't do everything we need, has the ability to specify a commit in their design since it's a real issue:
And then the other thing to test is:
- The tag creation triggers the CI
There are a bunch of rules about GitHub workflows triggering other workflows (to prevent infinite loops etc). This may not work -- we will need to test.
There was a problem hiding this comment.
As I think about this further, another downside is that this workflow could only ever /validate/ the kinds of things @rwgk is suggesting. (If it needs to add a commit to add content to the repo, we are back to the problems outlined in the OP). Is it really useful to have a workflow just to validate these things when instead we could write a local script that could actually /do/ those things and then add the tag? (and the push would correctly and helpfully fail if main had been updated in the meantime)?
There was a problem hiding this comment.
- The tag creation triggers the CI
There are a bunch of rules about GitHub workflows triggering other workflows (to prevent infinite loops etc). This may not work -- we will need to test.
Isn't this just handled by #1606?
There was a problem hiding this comment.
#1606 is triggered by adding a tag either locally or from the GitHub UI. Having a workflow create the tag may not work, because of the infinite loop avoidance rules. It's a little hard to tell from the docs -- we will just have to test it.
|
Not a huge fan of release steps being split. It makes debugging releases more difficult because you have to follow two workflows (or maybe three if we split docs). Not to mention that we now have another github actions feature to understand: workflows triggering other workflows. Why can't we do everything in a single workflow? Tag -> draft release -> test pypi -> pypi -> docs -> undraft release? |
4 participants
This is a suggested solution to workaround the issue we ran into with the recent
cuda_pathfinderrelease.(Initial revision created with Claude -- be extra cautious about its errors).
This adds a tag to the repo by first creating a new empty commit and then tagging that. This will force
CIto rerun with a tagged commit and create wheels and tarballs that have a proper tagged version, which then should be handled correctly when theCI: Releaseworkflow is used to upload to PyPI etc.This also acts as a starting point to put more automation steps for things we want to do when we tag a release.
An important downside of this approach is that you can't specify a specific commit to tag for release -- it needs to be the tip of main right now. (Because we need to create a new commit, and we need to put the new commit somewhere). This is a subtle "race condition" because things could be merged during the moment the user is trying to tag a release. I thought I would put this up to create some discussion around this. One nice solution would be to create a branch, then create the new commit and tag on that branch, which leaves a nice branch around to create bug fix releases from in the future. But that would no longer put tags on main as we currently do.
This also updates the
CI: Releasetask so it takes a component and a version, rather than a git tag, to be inline with this new workflow and reduce the ability to create an invalid tag. I thought having these two workflows be different would cause a lot of confusion.