4 ms·
Right now: - Self hosted Gitlab CE - Gitlab runners in pre-emptibles nodes with autoscaling Future (almost done, still in testing phase): - Phabricator (for
by maktouch 9y ago
Right now:
- Self hosted Gitlab CE
- Gitlab runners in pre-emptibles nodes with autoscaling
Future (almost done, still in testing phase):
- Phabricator (for git, code review and issues)
- Jenkins ("lightweight" CI, more details at the bottom)
- Google Cloud Container Builder ("Heavyweight" CI)
Our main repository is in Phabricator, but it has mirroring to Google Cloud Repository (for backup and faster heavyweight builds)
On commits, we run the lightweight CI in Jenkins. What I mean by lightweight is that, there's only a few runners and what it does is check what has changed. We have a mono-repository with over 30 microservices, rebuilding all of them is a waste of time and resources, so we have scripts and easy to use manifests that defines what to do. We also have a lot of small CI checks that is just not worth it to run externally, like linting.
Here's what our homegrown manifests looks like
build_graphql:
when_changed:
- graphql
- node_libraries/player-graphdb
- node_libraries/player-auth
- node_libraries/player-models
script_build: graphql/cloudbuild.yaml
script_skip: graphql/cloudbuild-skip.yaml
The script skip takes the last successful build and retag the docker images to the current one.
The build script sends the instructions to Google Cloud Container Builder to build the docker image, run the tests, and push it. We use Cloud Container Builder because managing those CI servers really sucks.
Let me know what else you want to know.