dev/ci: make PR pipeline construction purely additive
Created by: bobheadxi
Right now, if we make a PR that only affects Go files, we get the Go-only pipeline. However, if we then write some docs in the same PR, you get the entire test suite because you are no longer "go-only".
This starts work on deconstructing the core tests pipeline so that we start with a bare-minimum pipeline and add steps only if affected parts of the codebase are changed. Special-case branches (e.g. main) should still run the full set.
This is a continuation of https://github.com/sourcegraph/sourcegraph/pull/24657
Summary
- changedFiles only has
affectsXYZ
, and neveronlyXYZ
- all PR operations are set up in
CoreTestOperations
, which has limited parameters intentionally to reduce the scope of things that can be modified here. If it can't be expressed using these parameters, it should be set up separately within the GeneratePipeline function. I think just changedFiles should be sufficient for most cases.- tried to just have
changedFiles
, but there wasn't an ergonomic way to provide the chromatic tests with info about whether or not it should autoAcceptChanges (which seems to only happen on main) so I added an options struct as a parameter. This parameter should only be used to adjust steps, and not conditionally add them. Can't really enforce this except by review though
- tried to just have
- operations should target parts of the codebase based on the above
affectsXYZ
- currently the base steps are only Prettier (since I think that's allowed to lint non-ts/js stuff) and some static checks
- all other tests are added based on changedFiles
- e.g. split up Lint steps to frontend and graphql so they can be added separately
- we're currently losing some of the sorting-by-runtime of the steps, but I think the clarity here is far more valuable and I'm not sure the ordering was that much of a gain anyway
Followups
After this PR: https://github.com/sourcegraph/sourcegraph/issues/25202
Example
In this PR, I've added Go changes and docs changes. I get a pipeline that just performs the relevant checks for the two: