Gitlab CE 9.1 introduced an experimental feature that I have been waiting for eagerly for a very long time – the ability to schedule triggers to start CI runs (“pipelines” in their nomenclature). This is super exciting – it means I can more easily centralize routine scripting to CI runners, where I have repeatable environment configuration, great logging, and built-in Slack notifications on success and failure.
You can read more about using scheduled triggers on the documentation page.
The “gotcha” right now is that Sidekiq is used to run these scheduled jobs, and by default it only runs twice a day. The note at the bottom of the documentation page calls this out and shows how to fix it in non-omnibus installations of Gitlab, but is silent on the omnibus package. After some reading and tinkering, I found that the following entry in /etc/gitlab/gitlab.rb allows you to update the trigger_schedule_worker value:
gitlab_rails['pipeline_schedule_worker_cron'] = "CRON-ENTRY-HERE"
Update 5 July – the value of the above has changed from the beta! If you were testing in 9.1 you should ensure you update your gitlab.rb file to use the pipeline_schedule_worker_cron value.
For the cron entry, use standard cron format – for example, 0 */4 * * * would get you every four hours. You should make sure that this entry is at least as frequent as your most frequent scheduled trigger. Don’t forget to run gitlab-ctl reconfigure afterward!
For my Mac Admin needs, I’m working on making Gitlab CI run AutoPkg – I’ve reached the limit of using the Linde Group’s fantastic AutoPkgr GUI, and haven’t been wanting to write a full wrapper. This lets me not only take a shortcut but also level up my logging.