Support release-candidate builds as a first-class mode

[msarahan]

Why

The release platform builds final-version artifacts before their source tags are published. This is a new build type that is different from existing behaviors.

The behaviors are:

• we skip devcontainer builds to save resources, because they don't produce our release artifacts
• we exclude rapidsai and rapidsai-nightly channels when solving, which is for isolating our release candidate artifacts, ensuring that they are a self-consistent working set
• we skip upload steps to anaconda.org. The artifacts we produce go to a private S3 bucket instead. This is both for isolation, as well as to avoid confusion that the artifacts represent any kind of official release. The artifacts in this system have the final version, without any prerelease indicators.

What changes

• rapids-generate-version accepts RAPIDS_RELEASE_CANDIDATE_VERSION and returns that exact final, three-component numeric version without requiring a published Git tag.
• Candidate versions are checked against the source repository's major/minor version. RAPIDS_RELEASE_CANDIDATE_SOURCE_VERSION preserves that source value when a build script writes generated output back to VERSION.
• rapids-is-release-build recognizes RAPIDS_BUILD_TYPE=release-candidate, allowing shared workflows to pass the mode through directly instead of shadowing this command at runtime.
• rapids-rattler-channel-string gives candidates explicit channel policy: use caller-prepended frozen candidate channels and conda-forge, with neither public RAPIDS channel added.
• rapids-github-run-id recognizes candidate runs as build.yaml runs.
• The local configuration prompt documents release-candidate as a supported build type.

[msarahan]

Thanks for the review, @gforsyth. I got the LLM to make a few corrections, but I'm going to take a closer look myself tomorrow. I'll ping you when I think it's ready.

[gforsyth]

Looks good overall -- just the comment about some new env-vars and needing to document them.

[gforsyth]

I think RAPIDS_RELEASE_CANDIDATE_VERSION and RAPIDS_RELEASE_CANDIDATE_SOURCE_VERSION need to be documented at the top of this script.

Additionally, this error message should clarify what RAPIDS_RELEASE_CANDIDATE_SOURCE_VERSION is

[gforsyth]

Candidate versions are checked against the source repository's major/minor version. RAPIDS_RELEASE_CANDIDATE_SOURCE_VERSION preserves that source value when a build script writes generated output back to VERSION.

On reflection, I don't think I understand this. I get RAPIDS_RELEASE_CANDIDATE_VERSION, but I'm unclear of the problem that the SOURCE_VERSION variant is solving.

Are both of these env-vars being passed to rapids-generate-version?

[msarahan]

From Codex:

The second variable exists because many repositories run:
rapids-generate-version > VERSION
The shell truncates VERSION before the script starts, so the script cannot read the original value. The variable preserves that value so the script can reject building, for example, a 26.10.01 candidate from 26.12.00 source.
I agree the documentation currently makes these sound like equivalent user-facing knobs. A clearer description would be:
RAPIDS_RELEASE_CANDIDATE_VERSION:
Target artifact version to emit.

RAPIDS_RELEASE_CANDIDATE_SOURCE_VERSION:
Optional snapshot of the source checkout’s VERSION before it is overwritten.
Used only to verify that the target belongs to the same release line.
Longer term, we could remove the second variable by changing every direct-redirection caller to generate the version before overwriting VERSION. For this PR, keeping it is the compatibility path that avoids coordinated changes across many RAPIDS repositories.

[msarahan]

It's a safety check. The new release platform has the final tag as an input parameter. This safety check is asserting that the input parameter matches the VERSION file that's in our source code. So the question is whether we would ever want an emitted package version that does not match the VERSION file. I'm inclined to say "no" to that, so I'm going to work on simplifying this stuff using that assumption.

[gforsyth]

I'm inclined to say "no" to that, so I'm going to work on simplifying this stuff using that assumption.

👍 agree with that assumption

[gforsyth]

I still don't understand how we arrive at this gate, but if it does ever happen, I think the handling here is correct.

[msarahan]

/merge