3 ms·

We're moving away from gitlab because the performance is too much to bear. We're hearing "aaaaaarg I really hate gitlab" a few times a day. The pipeline pages

We're moving away from gitlab because the performance is too much to bear. We're hearing "aaaaaarg I really hate gitlab" a few times a day. The pipeline pages takes 7 seconds to load. It's really bad. We stopped using issues because just listing them was a chore. Pushing 1 file takes at least 30 seconds to 1 minute. Anyways, the work falls on me to replace it. We're going with Phabricator and Jenkins.

josegonzalez 9y ago
Is that self-hosted Gitlab or their hosted version? Would you mind sharing details on your setup? Just curious as we're currently building out our own setup.
- 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.

josegonzalez 9y ago

Is that self-hosted Gitlab or their hosted version? Would you mind sharing details on your setup? Just curious as we're currently building out our own setup.

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.