I’ve noticed quite strange behaviour of workflows when pull request is closed and reopened, and commit was made to the feature branch during the time PR was closed.
So, the configuration of triggers is following:
on: pull_request: branches: - master
And here is the sequence of actions a developer makes:
- Create feature branch from master
- Create a PR: feature -> master (activity type -
opened, workflow is triggered)
- Update feature branch (activity type -
synchronize, workflow is triggered)
- Close PR, without removing feature branch (nothing happens, expected)
- Push to feature branch (nothing happens, expected)
- Reopen PR (2 workflows are triggered - for
Default activity types for
pull_request event are:
reopened. Also, no workflows are associated with
push event for feature branch. So, behaviour of items 1 - 5 seems correct.
But I’m not sure I understand why 2 workflows are triggered almost simoultaneously when PR is reopened and push to feature branch was made during the time it was closed.
Also, here are the things that make it even more confusing:
- Both workflows show same SHA’s
- Event though they are triggered almost simoultaneously, the exact order is different - sometimes is
synchronize, but sometimes it’s vice versa.
I would really appreciate is somebody could:
- clarify if it’s designed to be like that
- help to find a workaround (if yes)
- tell if a fix is planned (if no)
Forgot to mention what problems such behaviour creates.
- In our case each workflow, that is triggered by pull request events, is supposed to run a deployment, and one of its steps executes Terraform. So we have some kind of race condition here, when one of the workflows fails because it can’t aquire lock (we have S3 + DynamoDB as backend).
- One of the last steps executes Helm, so probably it also won’t be a perfect solution to trigger 2 Helm deployments within a couple of seconds.