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?
3 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.