Continuous Integration

How this repository sets up its own continuous integration and deployment is described here. In this document we will look at the general setup of CI.
When setting up continuous integration, we sometimes want to keep track of changes per project. To support this we need to add tag patterns for the projects we want to build, e.g.:
 :tag-patterns {:stable "stable-*"
                :release "v[0-9]*"
                :myproject "myproject-*"}
When our build is triggered, e.g. via a webhook, we can ask the poly tool what projects have changed since the last successful build:
poly ws get:changes:changed-or-affected-projects since:myproject
output, e.g.:
["invoicer" "myproject"]
If myproject is returned, which is the case here, then we know that this project needs to be built and deployed, as long as all tests also pass. After a successful build, we tag the repository, e.g.:
git tag myproject-1
We want to keep the release tags, which is the reason each tag gets its own unique tag name, e.g. myproject-1, myproject-2, and so on. It's not important that the IDs are sequential. The tool will always sort them by the order they exist in git anyway.
If the CI build is set up so that it builds all projects in one go, then we could first start by asking what projects we have:
poly ws get:projects:keys skip:dev
The skip:dev parameter tells the tool to ignore the development environment (we are not interested in deploying dev). More than one project can be ignored, e.g. skip:dev:invoicer, where both project names and aliases can be used.
Then we can ask for changed or affected projects:
poly ws get:changes:changed-or-affected-projects since:release skip:dev
Here we rely on release-* tags that mark the whole repo as released.
Last modified 1yr ago