server
server copied to clipboard
nextcloud
Don't run some CI pipelines when not necessary
Whenever only JS code or the compiled JS assets have changed, exclude all PHP related tests like OCI, S3, etc.
I believe we already have something in place that detects PHP changes.
This could save some CI resources especially for all those dependabot PRs.
Reason for raising: In my case I saw PHP tests and OCI tests still running here: https://github.com/nextcloud/server/pull/33467
for Drone I found this: https://discourse.drone.io/t/how-to-only-trigger-on-changes-to-specific-file-s/10285/2
and for workflows:
- https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore
- see also: https://github.com/marketplace/actions/diff-set
seems it won't be that easy: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-including-paths
the docs state that excluding runs that are "expected" to pass will prevent merging
edit: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks
a bit cumbersome :-/
anyway, there's probably more to gain by skipping the php tests in Drone than in the workflows
The "solution" in the docs seems hacky
We can track the discussion here https://github.com/orgs/community/discussions/13690
idea: if we're ok to have some jobs as non-expected, we could also add the conditions only to those. some candidates for that:
- all Oracle jobs
- the external storage jobs, S3, primary object store, etc (they will still be triggered by PHP or storage code changes)
- the kerberos jobs
in terms of Dependabot, if we can also automate compilation, it would bring us closer to auto-merging because then Dependabot wouldn't be blocked as easily by those regularily failing S3 jobs (due to timeouts, I know we should solve these separately still)
A bit (software-)philosophical but what would help with this problem as well and is more deterministic: break the server into packages. Those can be unit tested with all crazy combinations whenever that code changes and only then. And here in the server you test integration, acceptance, etc when the system changes as a whole. The downside is that package might need to be linked during development. So this advantage comes with a cost.
