ensure nightly builds always produce new packages

[jameslamb]

Contributes to rapidsai/build-planning#218

• uses the new patterns for versioning nightly packages (see builds: add support for computing a date-based version component at build time shared-workflows#603), to ensure they're always uploaded on new builds.

For wheels:

# before
26.10.0a55 

# after
26.10.0a55.post260803200854

And for conda:

# before
26.10.0a55[build=cuda12_260803_9da146ef]

# after
26.10.0a55[build=cuda12_260803200854_9da146ef]

Other changes:

• updates changed-files lists to avoid triggering test jobs in PR CI when only .github/workflows/{build,test}.yaml are changed

Notes for Reviewers

How I tested this

round 1: epoch seconds versions (click me)

Triggered a build from this branch.

gh workflow run \
  build.yaml \
  --ref nightly-versions \
  --repo rapidsai/cugraph-gnn \
  -f branch=nightly-versions \
  -f build_type=branch \
  -f date=2026-07-27 \
  -f sha="$(git rev-parse HEAD)"

That started this: https://github.com/rapidsai/cugraph-gnn/actions/runs/30321225539

Then did a second run, to show that new packages would be published from the same commit: https://github.com/rapidsai/cugraph-gnn/actions/runs/30322425531

Then triggered a testing run.

gh workflow run \
  test.yaml \
  --ref nightly-versions \
  --repo rapidsai/cugraph-gnn \
  -f branch=nightly-versions \
  -f build_type=branch \
  -f date=2026-07-27 \
  -f sha="$(git rev-parse HEAD)"

Build link: https://github.com/rapidsai/cugraph-gnn/actions/runs/30323823418

That all looks good!

The second build uploaded new packages with the same beginning version (26.10.0a21) but different suffixes (.post1785203206 vs. .post1785204732).

All packages from all jobs within a run had the same version (26.10.00a21.post1785204732).

The newer packages were successfully pulled by all the test jobs. e.g. output like this in a conda job:

...
  + libwholegraph                     26.10.00a21.post1785204732  cuda12_260728_9fc66978             /tmp/tmp.bcD2HOYsle      49MB
...
  + pylibwholegraph                   26.10.00a21.post1785204732  cuda12_cp311_abi3_260728_9fc66978  /tmp/tmp.GAjTiyLk9l     298kB
...

And this in a wheels job:

Successfully installed ... libwholegraph-cu13-26.10.0a21.post1785204732
... pylibwholegraph-cu13-26.10.0a21.post1785204732 ...

(build link)

round 2: YYMMDDhhmmss versions (click me)

During review, we switched to YYMMDDhhmmss-formatted versions strings (rapidsai/shared-workflows#603 (comment)), so I repeated the testing above with that new version format.

• build.yaml 1: https://github.com/rapidsai/cugraph-gnn/actions/runs/30396789538
• build.yaml 2: https://github.com/rapidsai/cugraph-gnn/actions/runs/30399476266
• test.yaml : https://github.com/rapidsai/cugraph-gnn/actions/runs/30402598280/job/90422013211
  • just 1 conda job failed, and the failure looks unrelated to these changes

After more review, we switched away from updating versions for conda packages, towards just replacing the YYMMDD component of build strings with a more precise date-time (#508 (comment)), so repeated the testing again.

• build.yaml 1: https://github.com/rapidsai/cugraph-gnn/actions/runs/30648937831
• build.yaml 2: https://github.com/rapidsai/cugraph-gnn/actions/runs/30652238487
• test.yaml: https://github.com/rapidsai/cugraph-gnn/actions/runs/30653529575

[copy-pr-bot]

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.

[bdice]

I should've realized this earlier, but this suffix only makes sense for wheels (it contains .post) and yet its name doesn't indicate anything about wheels.

We aren't going to suffix conda versions, we're just going to use build strings, so I don't want to imply that this is generic to all build types.

We should name this something like RAPIDS_DATETIME_STRING (to align with conda's usage of RAPIDS_DATE_STRING) and then use .post${RAPIDS_DATETIME_STRING} for wheels and insert ${RAPIDS_DATETIME_STRING} into the conda recipes where we currently use RAPIDS_DATE_STRING.

[jameslamb]

We aren't going to suffix conda versions, we're just going to use build strings

As written, I AM proposing using this suffix conda packages too and that's how it's working right now:

...
cugraph-pyg                         26.10.00a21.post260728210952  260728_9fc66978                    file:///tmp/tmp.vYeKSGpHdu
...

(example from the test runs linked in the description)

Because:

1. I wasn't sure how the build string participates in sorting (would the latest nightly always be preferred?)
2. I didn't want to mess with the existing YYMMDD component in the build strings and break the test-nightly-conda-env stuff in integration (code link) and anything else that might be relying on that formatting.

Fine with me to change the naming of these things and try what you're suggesting, and I'll happily patch integration and anything else that needs to change as a result of changing the build string.

[bdice]

I think there may be issues with conda solvers with both pre- and post- suffixes. I am not 100% sure about that. I do think we should stick to the status quo for conda, aside from adopting the same build string date format proposed for wheels.

The only place we explicitly rely on that date format string is in the integration repo's parser, to my knowledge.