The current workflow checks if the changed files belong to the frontend or the backend and runs build checks for those parts accordingly. This can allow PRs to be merged even with failed checks in some cases.
Example:
- Push a commit with frontend changes
- Changes don't pass the frontend checks, PR is blocked from being merged
- Push a commit after that with only backend changes
- Workflow runs only the backend checks
- If the checks pass for the backend, PR can be merged despite having failing frontend checks
I've noticed this in some of my PRs but here's an example where a PR was merged to prod despite having failed checks:
In #5240, commit 3940702 fails frontend checks but the later commits involve only the backend and the checks pass allowing the PR to be merged.
Solution: Remove the check for frontend/backend and run all checks every time? This would cause the build checks to run longer but would ensure we don't merge something broken. One potential issue with this is that those checks would run even for PRs with only config/documentation changes which don't require frontend/backend checks.
The current workflow checks if the changed files belong to the frontend or the backend and runs build checks for those parts accordingly. This can allow PRs to be merged even with failed checks in some cases.
Example:
I've noticed this in some of my PRs but here's an example where a PR was merged to prod despite having failed checks:
In #5240, commit 3940702 fails frontend checks but the later commits involve only the backend and the checks pass allowing the PR to be merged.
Solution: Remove the check for frontend/backend and run all checks every time? This would cause the build checks to run longer but would ensure we don't merge something broken. One potential issue with this is that those checks would run even for PRs with only config/documentation changes which don't require frontend/backend checks.