3 ms·
Thanks for sharing your use case. I think that code of the cleanup job can be in the same repo as the load test itself. Would that be a fit for you? Of course t
by sytse 10y ago
Thanks for sharing your use case. I think that code of the cleanup job can be in the same repo as the load test itself. Would that be a fit for you? Of course the load test code can have the testing code of the application as a dependency.
Maybe you prefer the load testing code in the same repo as the application. In that case it should be two jobs that are triggered periodically I think.
I think what GitLab CI still needs is periodic jobs https://gitlab.com/gitlab-org/gitlab-ce/issues/2989 https://gitlab.com/gitlab-org/gitlab-ce/issues/2989 (right now the workaround is sending a build trigger for an external task).
- aalbertson 10y agono, it does not fit the bill. It needs truly arbitrary job running. I want to be able to just drop in some arbitrary command (e.g. df -h /some/build/agent/dir/ | grep 99%) that would not be worth it to me to write a script, commit it to git, get that deployed and running. In fact, I AM a fan of this being in git, but the example I'd use is an improvement on TeamCity, where you can configure your job and project configurations to "commit to git" so that you can easily restore when you need to rebuild a server or reload a previous version. Sooooo many use cases for arbitrary jobs. Many of which may be short lived, but want them automated in some way. (speaking as a sysadmin/eng/devops/cloud dude)
- scrollaway 10y agoCan Gitlab CI do manual triggers yet? (Drone can't, last time I checked, and that was a huge turnoff) The "code" in this case really lives in the Jenkins database, as it's a shell snippet. Admittedly I'm not a fan of this. However, since you're a FOSS company as well, you may have hit the case where you want to separate the code for your infrastructure from the code you're releasing in the general repository, but still build off master. This is where Jenkins' model is quite good. I strongly dislike that it's so hard for Jenkins' metadata to be versioned in proper git repositories, but the separation of the actual code, and the CI-related code is great.
- sytse 10y agoManual build triggers for GitLab CI are possible with https://docs.gitlab.com/ce/ci/triggers/README.html https://docs.gitlab.com/ce/ci/triggers/README.html In my taste the shell snippet that is infrastructure specific should like in a small repository. An example of that for us is https://gitlab.com/gitlab-com/runbooks https://gitlab.com/gitlab-com/runbooks (although that is more process since we try to keep the code generic).