Disable gpuCI (Jenkins/legacy) webhooks

[fjetter]

gpuCI is currently not very reliable and it's been a source of friction. Some of this is being discussed here and here. The summary is that the current infrastructure is not reliable and the conversation about new infrastructure is only moving along slowly.

Therefore, I am proposing to disable the existing gpuCI webhooks this Friday, November 15th.

This does not mean that gpuCI is gone forever. There's a proposal to introduce a new gpuCI GH actions runner here #348 There is still some work to be done to align on the final version of this but I'm open to continue this conversation.

cc @dask/gpu

[rjzamora]

I am proposing to disable the existing gpuCI webhooks this Friday, November 15th.

Thanks for the heads up Florian.

Yes - I think this is fine. I'm sorry for not suggesting it earlier in the week. The legacy/Jenkins infrastructure is having serious issues, and we are in the process of standing up something within RAPIDS to run the GPU tests in dask/dask and dask/distributed until a suitable GHA gpuCI solution is available.

Related Note: The @pytest.mark.gpu marker will still be very important to RAPIDS when gpuCI isn't running :)

This does not mean that gpuCI is gone forever. There's a proposal to introduce a new gpuCI GH actions runner here #348 There is still some work to be done to align on the final version of this but I'm open to continue this conversation.

Great - Thanks for being open to this. Having (reliable) gpu-CI is very helpful.

[fjetter]

this is done

[charlesbluca]

Had I not been on PTO in the short period I could've objected to this, I would've asked if we could've waited until after some kind of makeshift solution was put in place to do this.

But now that it's done, and I'm assuming there is no going back, I would suggest we go a step further than what @jrbourbeau is doing in dask/dask#11545 dask/distributed#8945 and just outright remove all the gpuCI infra files from the respective repos, as it is unlikely these will be used for whatever replacement we put together and we likely want to decouple that replacement as much as possible from the Dask/Distributed repos to avoid the frictions we saw with Jenkins