Closed JessicaS11 closed 1 month ago
Weird! That should trigger a pull_request
synchronize
event and then trigger the unit tests. When this happens, until we figure out why and fix it, we can close and re-open the PR to force a run on the latest commit (that's a pull_request
reopen
event).
Turns out this isn't a new problem: https://github.com/orgs/community/discussions/25702
From this post, it sounds like commits coming from actions do not trigger further CI workflows based on tokening (GH is trying to prevent infinitely recursive workflows to the detriment of the situations where one or two recursions are needed!).
From the add-and-commit action docs:
When pushing, the action uses the token that the local git repository has been configured with: that means that if you want to change it you'll need to do it in the steps that run before this action. For example: if you set up your repo with actions/checkout then you have to add the token there. Changing the token with which the repo is configured can be useful if you want to run CI checks on the commit pushed by this action; anyway, it has to be set up outside of this action.
And specifically:
The commit from the action is not triggering CI!
That's because you're checking out the repo using the built-in GITHUB_TOKEN secret: GitHub sees that the push event has been triggered by a commit generated by CI, and doesn't run any further checks to avoid unintentional check loops. If you're sure that you want the commits generated during CI to trigger other workflow runs, you can checkout the repo using a Personal Access Token (PAT): this will make the resulting commit the same as if you made it yourself. If you're using actions/checkout, check out their docs to see how to set your repo token.
It looks like we might be able to explicitly trigger the unit tests to work after the UML action has run using a workflow_run. I'll open a PR to do that and we can see if it helps for our next PR.
Nice research, thank you!
In #609, a review triggered a UML update (as intended) which added a commit to the PR. This commit did not trigger another round of unit tests (which were previously passing), thus keeping the PR from meeting all required checks (and thus enabling merging). Retriggering the tests on the branch did not result in an updated status because they're still pointing to the commit before the auto-update. We'll have to tweak the unit test triggers to handle this.