rapids-generate-version: respect RAPIDS_VERSION_SUFFIX env variable for non-release builds - #268
Merged
Merged
Conversation
…or non-release builds
This was referenced Jul 27, 2026
jameslamb
marked this pull request as ready for review
July 28, 2026 16:10
vyasr
approved these changes
Jul 29, 2026
Member
Author
|
/merge |
rapids-bot Bot
pushed a commit
to rapidsai/shared-workflows
that referenced
this pull request
Jul 29, 2026
…uild time (#603) Contributes to rapidsai/build-planning#218 Proposes adding a new workflow, `compute-build-details`, which computes information to be passed into builds. Right now this only calculates a version suffix like `.post{current-time-in-epoch-seconds}` to help with distinguishing nightlies, but proposing giving it a generic workflow name in case we want to stick other data in here in the future. ## Notes for Reviewers ### How does this solve the problem with nightlies? With this time-based version component, every new non-release run of `build.yaml` in a RAPIDS repo should produce packages with a never-before-seen version, so uploads to anaconda.org should succeed. e.g. we might see this version sequence for nightlies: ```text 26.08.00a35.post1785176675 # 35 commits past '26.08.00a' tag, CI run started at epoch time 1785176675 26.08.00a35.post1785180275 # 35 commits past '26.08.00a' tag, CI run started 1 hour later 26.08.00a36.post1785180475 # 36 commits past '26.08.00a' tag, CI run started a little later ``` These versions will only be used in pre-releases built on `main`, not releases or packages built in PR CI (rapidsai/gha-tools#268). ### What about timing problems? This workflow will run once at the very beginning of the branch/nightly workflow run, then its output is passed as input to all other build jobs. That makes the value static across an entire workflow run, so packages will have the same version even for: * builds starting at different times due to scheduling delays * builds starting at different times from clicking "re-run failed jobs" (e.g. for network failures) ### How I tested this Confirmed that versions like this are recognized as valid PEP 440 versions and sort the way we expect in `packaging.Version`. ```python from packaging.version import Version Version("2026.08.00") > Version("2026.08.00a35.post1785176675") # True Version("2026.08.00rc0") > Version("2026.08.00a35.post1785176675") # True # same commit, newer build wins Version("2026.08.00a35.post1885176675") > Version("2026.08.00a35.post1785176675") # True # later commit wins Version("2026.08.00a36.post1885176675") > Version("2026.08.00a35.post1785176675") # True ``` Also tested live with on `cugraph-gnn`, see "How I tested this" on rapidsai/cugraph-gnn#508 Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Vyas Ramasubramani (https://github.com/vyasr) URL: #603
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After this PR, if environment variable
RAPIDS_VERSION_SUFFIXis non-empty, its value is appended to the output ofrapids-generate-versionon non-release builds.Notes for Reviewers
Motivation
Helps resolve a long-standing issue where newly-built nightly packages aren't published because their version numbers match existing published packages (rapidsai/build-planning#218).
How I tested this
See more testing on these PRs: