Closed zeke closed 3 years ago
hypothetically, you could write a really simple cli to handle the conditional test suites, have that cli run the tests and aggregate the results somehow then publish them. allowing conditionality & an almost guarantee of the commit passing all the tests if the conditions are well defined
That's a good idea @KieranHolroyd! I'll explore some options on this.
I think this is solved by this! https://github.com/github/docs/commit/c76bf47ea566f47e62e50abe454e078acb8c7a3c. Cool if I close @zeke?
We currently run all tests on every pull request. This is a good practice because it gives us confidence that our changes won't break anything. The downside of this setup is that even the smallest of pull requests have to run the whole test suite, including changes that don't affect the codebase, like the README or the contributing docs.
Some of our tests are still pretty slow:
[ci skip]
won't workIt's common for some projects to support a pattern like
[ci skip]
that can be added to commit messages to exempt the commit from triggering a new test run, but there are a few problems with that:what about detecting changed files?
There are lots of GitHub Actions out there for collecting a list of changed files in a pull request. This looks like a particularly nice one: https://github.com/futuratrepadeira/changed-files#readme
Using such an Action we could conditionally skip certain steps in our test suite. For example, we could skip the
content
test group if there have not been any changes tocontent/
ordata/
. We could also probably skip thelinks-and-images
test in this case too.The drawback of this approach is that we wouldn't have 100% confidence that every single PR is passing every single test, but I think that might be worth losing in exchange for a faster release cycle. 🚀
cc @github/docs-engineering