CI Move label removal to a separate workflow #29456
Conversation
To remove a label from a PR we need write access to the PR which is not possible with workflows executed for a PR from a fork.
CUDA GPU seems redundant
|
Do you have an opinion @lesteve ? |
|
Do I understand correctly that basically when you add the "CUDA CI" label it gets automatically removed? This is slightly weird (wait I just added this label why does it get removed) and also I am wondering like @thomasjpfan about possible race conditions. Have you tested it on your fork by any chance? And yes, renaming the CI workflow will need adaptation in https://github.com/organizations/scikit-learn/settings/actions/runner-groups/4 otherwise we will be back again to "why does the job not find any GPU runner" 😱. |
Yes. We don't need to remove the label but then the next time you want the PR tested you have to remove it and add it again. Instead of just adding it. My hope is that further into the future when we feel more comfortable with everything
Been testing it on betatim/scikit-learn-ci#2. In the last few instances yesterday the label didn't get removed. This is because I was experimenting with the alternative Thomas proposed in his comment.
Right now it is configured to allow all workflows, so we don't need to change anything right? It is only if we find a way to restrict things right? |
|
OK let's merge and see what happens!
Yes you are right indeed. Nothing to do now, since we have Workflow access : all workflows. |
|
I tested it in #29300, looks like this is working fine. |
I don't know why, but somehow I am surprised ;) |
|
Well I guess if you miss broken stuff, you can always look at why the GPU tests are broken even when updating the lock-files: #29373 Of course, you can also decide to work on more meaningful stuff, which would be perfectly understandable 😉. |
To remove a label from a PR we need write access to the PR which is not possible with workflows executed for a PR from a fork.
The new separate workflow uses the
pull_request_targettrigger like our other labelling workflows. With this trigger the workflow runs in the context of the parent repository and as a result can havewriteaccess to the pull request. It does not checkout the code of the PR though, so you can't smuggle changes into the workflow without review.If we rename to
cuda-ci.ymlwe need to update the list of allowed workflows in https://github.com/organizations/scikit-learn/settings/actions/runner-groups/4Follow up for #29376