One problem is GHs auto-merge when ready button. It will merge when there are still tests running unless they are required. It would be much better if the auto merges took into account all checks and not just required ones.
If you have folderA and folderB each with their own set of tests. You don’t need folderAs tests to run with a change to folderB. Most CI/CD systems can do this easily enough with two different reports. But you cannot mark them both as required as they both wont always run. Instead you need a complicated fan out pipelines in your CICD system so you can only have one report back to GH or you need to always spawn a job for both folders and have the ones that dont need to run return successful. Neither of these is very good and becomes very complex when you are working with large monorepos.
It would be much better if the CICD system that knows which pipelines it needs to run for a given PR could tell GH about which tests are required for a particular PR and if you could configure GH to wait for that report from the CICD system. Or at the very least if the auto-merge was blocked for any failed checks and the manual merge button was only blocked on required checks.
You can have certain jobs run based on what directories or files were modified. If projectA was the only one modified, it can run just projectA’s tests.
The real problem is merging before waiting for that one slow CI pipeline to complete
One problem is GHs auto-merge when ready button. It will merge when there are still tests running unless they are required. It would be much better if the auto merges took into account all checks and not just required ones.
It tests passing is a requirement of merging, then you should set the tests as required.
If you have
folderAandfolderBeach with their own set of tests. You don’t needfolderAs tests to run with a change tofolderB. Most CI/CD systems can do this easily enough with two different reports. But you cannot mark them both as required as they both wont always run. Instead you need a complicated fan out pipelines in your CICD system so you can only have one report back to GH or you need to always spawn a job for both folders and have the ones that dont need to run return successful. Neither of these is very good and becomes very complex when you are working with large monorepos.It would be much better if the CICD system that knows which pipelines it needs to run for a given PR could tell GH about which tests are required for a particular PR and if you could configure GH to wait for that report from the CICD system. Or at the very least if the auto-merge was blocked for any failed checks and the manual merge button was only blocked on required checks.
Both GitHub Actions and GitLab CI let you specify filepath rules for triggering jobs.
You can have certain jobs run based on what directories or files were modified. If projectA was the only one modified, it can run just projectA’s tests.
Exactly; the OP image is saying that there’s no point to doing that.
gitlab has a feature where you can set it to auto-merge when and if the CI completes successfully