xref: rapidsai/gha-tools#138
@vyasr laid this out in the issue above:
Currently all our test CI jobs use rapids-download-*-from-s3 to get their artifacts (cudf example). These tools all call rapids-download-from-s3, which in turn calls rapids-s3-path. Since rapids-s3-path constructs its path based on the build type, that implicitly means that test.yaml always pulls the build from the corresponding nightly build, even if there was a more recent branch build. This is particularly problematic in light of #127 since it is now more important to be able to resolve these failures within a given day i.e. by rerunning the test workflow on a branch build. To support this use case, we should make the build type an optional input to the test.yaml workflow to customize which type of build to pull in the workflow. This will allow us to customize running a test workflow on a branch build to unblock CI once fixes are in.
I'm opening this to track the work and so we don't have the tracking over in gha-tools
Once I merge in the above, then, for the repos below, once they are targeting
shared-workflows@25.04 I can begin adding in the option for running against a
particular branch.
xref: rapidsai/gha-tools#138
@vyasr laid this out in the issue above:
I'm opening this to track the work and so we don't have the tracking over in
gha-toolsbranchoption for$BUILD_TYPE(Allowbranchoption for$BUILD_TYPEshared-workflows#275)Once I merge in the above, then, for the repos below, once they are targeting
shared-workflows@25.04I can begin adding in the option for running against aparticular branch.
test.yamlcucim#831)test.yamlcudf#17925)test.yamlcugraph#4918)test.yamlcugraph-gnn#143)test.yamlcuml#6296)test.yamlcuspatial#1541)test.yamlcuxfilter#661)test.yamldask-cuda#1444)test.yamlkvikio#620)test.yamlnx-cugraph#82)pynvjitlink(notest.yaml)test.yamlraft#2573)test.yamlrapids-cmake#766)build_typeto workflow inputs rmm#1811)test.yamlucx-py#1115)test.yamlucxx#367)