Not super high priority but a helpful project that will require a somewhat creative solution:
Currently we require 5 actions to run before merging into dev (see .github/workflows/build-and-test.yml), which make up a firebase build/deploy/test and a frontend build/test. However for many PR's, one of those two sequences is unnecessary, per no changes having been made. I.e. often we're just working on the frontend, and so there's no reason to build/deploy/test the firebase cloud functions of that PR.
To solve this, we can design some system that checks we're running on a CI server (probably some environment variable), and then if so checks whether the current commit that's being tested has any diff from the current dev branch's cloud-functions/ or client directories, and then based on that either triggers the full build/[deploy]/test or not.
One tricky aspect is that we still want to make each of these tests "required" tests in Github, and it doesn't give us programatic flexibility there (i.e. we can't say a test is required only if some condition is met). So the solution will need to account for that, probably by having a way for the actions that we decide don't need to run on some particular commit just return "success" immediately.
colbymorrison
commented
4 years ago
Not super high priority but a helpful project that will require a somewhat creative solution:
Currently we require 5 actions to run before merging into dev (see
.github/workflows/build-and-test.yml), which make up a firebase build/deploy/test and a frontend build/test. However for many PR's, one of those two sequences is unnecessary, per no changes having been made. I.e. often we're just working on the frontend, and so there's no reason to build/deploy/test the firebase cloud functions of that PR.To solve this, we can design some system that checks we're running on a CI server (probably some environment variable), and then if so checks whether the current commit that's being tested has any diff from the current dev branch's
cloud-functions/orclientdirectories, and then based on that either triggers the full build/[deploy]/test or not.One tricky aspect is that we still want to make each of these tests "required" tests in Github, and it doesn't give us programatic flexibility there (i.e. we can't say a test is required only if some condition is met). So the solution will need to account for that, probably by having a way for the actions that we decide don't need to run on some particular commit just return "success" immediately.