Hi all,
At the moment every push and pull request triggers the full CI suite: the backend gets compiled in several configurations, the Docker image is built, and both integration test runs execute - regardless of what was actually changed. A one-line CSS tweak in architect-html costs the same CI time as a change to the workflow engine.
This has a few downsides worth considering:
- Long feedback loops on small changes, which discourages small, focused pull requests
- Significant runner time spent on work that cannot possibly be affected by the change
- Noise: a failure in an unrelated area on an unrelated PR is hard to interpret
GitHub Actions supports deciding, per pull request, which jobs need to run based on which paths were touched. In principle a frontend-only change could skip the backend compilation and the C# test runs entirely, and a change confined to one of the frontends could skip the other two.
I don’t think this is entirely trivial - some suites genuinely need a backend even when the change is frontend-only, and we’d need to be careful that required status checks keep behaving correctly so pull requests don’t get stuck. There’s also a question of where the boundaries should sit: which areas are truly independent, and which ones we’d rather keep coupled out of caution. Build caching might be a complementary angle worth looking at alongside this.
Before anyone invests time in it, I’d like to hear whether this direction makes sense to you, and whether there are constraints I’m not seeing - for instance, checks that must always run for release or compliance reasons.
Thanks!