Reimplement wheel-ctk-name-gen as a gha-tool

[vyasr]

This repository currently has a composite action wheel-ctk-name-gen. That action currently sets two environment variables into the GITHUB_ENV so that they are accessible in subsequent steps. This logic should instead be extracted into a new script in the gha-tools repo. Rather than setting two environment variables, we should remove the RAPIDS_PY_WHEEL_NAME altogether and simply return the suffix rather than storing it in the environment.

I also think that we should probably have the new tool return the suffix without the hyphen (e.g. cu11 instead of -cu11). The current approach leads to different parts of the workflow needing to edit that to either remove the hyphen or convert it to an underscore, so we would be better served by removing that from the initial definition of the suffix and just tacking on the extra characters where needed.

I expect that making this change will also necessitate combining more steps in the workflow since we will no longer be automatically propagating the variable across multiple steps.

[divyegala]

In terms of combining steps, would we combine these three steps into one?

1. https://github.com/rapidsai/shared-action-workflows/blob/e1355b0391fec868e0c5b2bce851f6eda251e1be/.github/workflows/wheels-manylinux-build.yml#L185
2. https://github.com/rapidsai/shared-action-workflows/blob/e1355b0391fec868e0c5b2bce851f6eda251e1be/.github/workflows/wheels-manylinux-build.yml#L191
3. https://github.com/rapidsai/shared-action-workflows/blob/e1355b0391fec868e0c5b2bce851f6eda251e1be/.github/workflows/wheels-manylinux-build.yml#L201

This will mean being able to share RAPIDS_PY_WHEEL_CUDA_SUFFIX across all steps. And if I understand the intention correctly, then we'll be able to move the combined steps into a script to downstream repos.

[vyasr]

Yes, exactly. Since it's no longer an environment variable being propagated across steps, you'll need to combine. If you'd like to stage the work, though, you could switch to using the gha-tool but then manually export in the workflow for now, then come back to make the change combining steps in a subsequent PR. That's probably the cleaner approach, but I'll leave it to you and @rlratzel to decide.

[divyegala]

I do prefer combining steps in the same PR, since there are a lot of moving pieces and many other tasks yet to be accomplished.

[vyasr]

rapidsai/gha-tools#55 added the new tool.

[vyasr]

Resolved in #91

[divyegala]

In terms of combining steps, would we combine these three steps into one?

1. https://github.com/rapidsai/shared-action-workflows/blob/e1355b0391fec868e0c5b2bce851f6eda251e1be/.github/workflows/wheels-manylinux-build.yml#L185
2. https://github.com/rapidsai/shared-action-workflows/blob/e1355b0391fec868e0c5b2bce851f6eda251e1be/.github/workflows/wheels-manylinux-build.yml#L191
3. https://github.com/rapidsai/shared-action-workflows/blob/e1355b0391fec868e0c5b2bce851f6eda251e1be/.github/workflows/wheels-manylinux-build.yml#L201

This will mean being able to share RAPIDS_PY_WHEEL_CUDA_SUFFIX across all steps. And if I understand the intention correctly, then we'll be able to move the combined steps into a script to downstream repos.

[vyasr]

Yes, exactly. Since it's no longer an environment variable being propagated across steps, you'll need to combine. If you'd like to stage the work, though, you could switch to using the gha-tool but then manually export in the workflow for now, then come back to make the change combining steps in a subsequent PR. That's probably the cleaner approach, but I'll leave it to you and @rlratzel to decide.

[divyegala]

I do prefer combining steps in the same PR, since there are a lot of moving pieces and many other tasks yet to be accomplished.

[vyasr]

rapidsai/gha-tools#55 added the new tool.

[vyasr]

Resolved in #91