CI Configuration

Qi uses GitHub Actions to run tests, dependency checks, and test coverage reporting on every commit. It follows the recipe described in Migrating Your Racket Project from Travis to GitHub Actions.

The actual configuration can be found in .github/workflows/test.yml.

Testing things

If you need to make some change to the CI infrastructure, it would be annoying to have to test the change by actually pushing the changes to the main branch. Instead, even though your CI workflow is likely to specify triggers conditioned on main branch, for the purposes of testing, modify the triggers to look for changes on your development branch for this new feature. You could even add a dummy path containing a simple text file that you can modify, for use as a temporary trigger during testing. Once you've deployed it to GitHub a few times and verified that it's working as expected, you can change the triggers to the correct ones (e.g. main branch changes). As this kind of testing is likely to involve a lot of noisy commits, consider squashing some of these commits prior to merging the feature into main branch.

Note: If you are testing this on your own fork, it should in theory run the workflows on your fork and you could likely test most things that way. But if that doesn't work, it may be that you need to do the testing on the upstream (drym-org) fork rather than your own fork, as otherwise it may not have access to the GitHub Pages site or other production infrastructure that you'd like to test against. (If you go through this and conclude that you either need or don't need to test on the upstream fork, please update these docs with your conclusions!)