Local CI build prompts twice when requesting build information

[davidwendt]

Following Reproducing CI Locally instructions recently has started to prompt twice for the RAPIDS_BUILD_TYPE, RAPIDS_REPOSITORY, and RAPIDS_REF_NAME.

Example running ci\build_docs.sh (though any script that requires artifacts also does this):

...
[rapids-download-conda-from-s3] Local run detected.
[rapids-download-conda-from-s3] NVIDIA VPN connectivity is required to download workflow artifacts.

Enter workflow type (one of: pull-request|branch|nightly): pull-request

Suppress this prompt in the future by setting the 'RAPIDS_BUILD_TYPE' environment variable:
export RAPIDS_BUILD_TYPE=pull-request


Enter org/repository name (e.g. rapidsai/cudf): rapidsai/cudf

Suppress this prompt in the future by setting the 'RAPIDS_REPOSITORY' environment variable:
export RAPIDS_REPOSITORY=rapidsai/cudf


Enter pull-request number (e.g. 1546): 15375

Suppress this prompt in the future by setting the 'RAPIDS_REF_NAME' environment variable:
export RAPIDS_REF_NAME=pull-request/15375


Using HEAD commit for artifact commit hash. Overwrite this by setting the 'RAPIDS_SHA' environment variable:
export RAPIDS_SHA=77...c9

[rapids-download-from-s3] Downloading and decompressing https://downloads.rapids.ai/ci/cudf/pull-request/15375/77337ac/cudf_conda_cpp_cuda12_x86_64.tar.gz into /tmp/cpp_channel
[rapids-download-conda-from-s3] Local run detected.
[rapids-download-conda-from-s3] NVIDIA VPN connectivity is required to download workflow artifacts.

Enter workflow type (one of: pull-request|branch|nightly):

One prompt is from rapids-download-conda-from-s3 and the 2nd is from rapids-download-from-s3.
Both export the variables so I'm not sure why the 2nd one does not see them.

After filling out both sets of prompts, the process completes successfully.
Simply workaround is to set these 3 variables locally before launching the script.

[vyasr]

Yeah I run into this sometimes too. The problem is that the tools aren't actually exporting those variables, they just forward them along via calls. I'd support setting them the first time they're provided to prevent this kind of thing unless there's a problem with that approach that I'm not aware of.