Update trigger #31
Update trigger #31
Conversation
| @@ -9,6 +9,11 @@ on: | |||
| branches: | |||
| - 'master' | |||
| - 'main' | |||
| pull_request: | |||
There was a problem hiding this comment.
I think the problem is that the same workflow is used as this repository workflow and as a ruleset workflow. This will potentially bring more issues in the future.
Even in this case I expect this workflow to be also triggered on pull_request in another repository from the ruleset when the pull request will change any of files below in that repository.
Maybe moving this to become reusable workflow and then calling it from the workflow of this repo on pull_request and CLA ruleset workflow on pull_request_target would work better.
There was a problem hiding this comment.
I think the problem is that the same workflow is used as this repository workflow and as a ruleset workflow. This will potentially bring more issues in the future.
What other issues do you see? I don't think there is a way of disabling it. The bigger issue I see is that the PR is not blocked when the workflow is broken, but that is a general github actions issue.
Even in this case I expect this workflow to be also triggered on pull_request in another repository from the ruleset when the pull request will change any of files below in that repository.
What if I switch it to .github/workflows/check_cla.yml? Other teams would have no reason to change this file.
Maybe moving this to become reusable workflow and then calling it from the workflow of this repo on pull_request and CLA ruleset workflow on pull_request_target would work better.
This sounds very complicated and given that reusable workflows are being deprecated, I don't think it's a good idea to rely on them.
There was a problem hiding this comment.
I can't name specific issues in advance, but I expect them to happend because of this: the way it is currently done causes this workflow to be called two completely different ways. So you'll regularly have issues because those two different ways are not the same, and because the purpose of these two different ways is different, and just because the person editing it will be often only thinking about one of these purposes.. I was expecting to have issues because of this and now they are.
Switching it to only run on very specific file will be just limited mitigation - next time it will break because some other file will be changed.
This is the first time I hear that reusable workflows are deprecated. Do you have link?
There was a problem hiding this comment.
This is the first time I hear that reusable workflows are deprecated. Do you have link?
Maybe I am getting confused with all the terminology - required workflows are being deprecated in favor of rulesets. By reusable workflows, is this what you are referring to? https://docs.github.com/en/actions/using-workflows/reusing-workflows If so, I think I understand what you mean, I can put together a PR.
Looks like I accidentally broke the workflow. How this happened:
pull_request_targetand run on the master branch it succeededBecause we don't expect external contributors to make any changes to the workflow itself, this filtering logic should enable internal developers to still make changes and test the workflow when necessary.