✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: 57ac826. Link to the linter CI: here}

@EdAbati what do you think of linking to https://gist.github.com/EdAbati/ff3bdc06bafeb92452b3740686cc8d7c from the comment that the bot makes? That would let contributors test/debug build issues without having to wait for a maintainer to trigger the workflow. If we do that, could you add a short instruction text to the gist's description?

@lesteve and/or @ogrisel if you want to already review this, go for it. I am leaving this as a draft for now until we make a decision on including (or not) the "test via colab" gist from the above comment.

Hi @betatim,
Happy to add some instructions!

Since this gist is becoming part of the process, we could also transfer it to the scikit-learn org (can we do that on GitHub? 🤔) if you prefer. So you all have more control and I don't become the bottleneck for updates :)

UPDATE:

The gist is updated, let me know what you think

I was wondering about moving the gist to the scikit-learn org, but not sure if that is possible? Maybe not https://github.com/orgs/community/discussions/7923?

I think it is fine to host it on your account. We can link to a particular revision of it so that you aren't on the hook for someone stealing your account on adding evil things to the gist which people then blindly run.

I think this would be more natural (and safer) to implement if we make this workflow run in a pull_request context instead of the main branch environment.

Maybe it's possible to leverage the required reviewers feature of custom environments as documented here:

• https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#required-reviewers

Alternatively we could use a label based trigger of for the workflow as we do for the .github/workflows/check-changelog.yml workflow.

I was wondering about moving the gist to the scikit-learn org, but not sure if that is possible? Maybe not https://github.com/orgs/community/discussions/7923?

We could host the notebook under a build_tools/google-colab folder of the scikit-learn repo itself instead.

I think this would be more natural (and safer) to implement if we make this workflow run in a pull_request context instead of the main branch environment.

Maybe it's possible to leverage the required reviewers feature of custom environments as documented here:

* [docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#required-reviewers](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#required-reviewers)

I kind of agrees about the pull_request context, here is what I said in internal email (mostly to have it in a public place).

It would kind of feel more natural to have the trigger be pull_request like most other CI builds, have a step that waits for manual approval, and then the approval triggers the GPU workflow. Not quite sure how to do this, but it feels like a common usage and surely someone in the world have found a way to do it ...

Searching a bit I haven't found anything clear-cut, here is what I found so far ...

• some Github actions like this: https://github.com/marketplace/actions/manual-workflow-approval
• approval for deployments which is not what we want I think https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments

About the label-based stuff I am wondering whether it has inherently the same security issues as our previous approach. Between the time you set the label and the time the worflow start there is an opportunity for someone to push a commit. Even if you do time-based checks I think there is still some small time window that is exploitable. This is super hard to exploit I know, you'd have to read the mind of the person who is about to set the label, so maybe it is still acceptable I don't know 🤔 ...

Between the time you set the label and the time the worflow start there is an opportunity for someone to push a commit.

Yes but it could happen in a pull_request github actions environment which comes with cache isolation from the main branch environment by default. It could not be used to trigger cache poisoning attacks on other workflows with more privileges (e.g. to grab token keys or inject malware into release artifacts).

I will tackle running the CUDA CI workflow in a PR context in a new PR. And either integrate this work in that or come back to this PR.

Closing