Optimize image create in Bluebox for use with Test Kitchen
In my previous post I described how to use GitLab labels to easily triage. @shochdoerfer asked me:
@boc_tothefuture how can @gitlab labels be applied automatically for issues or merge requests?
We use GitLab webhooks to automatically apply labels to incoming MRs. To process the webhooks, we wrote a simple webrick server whose process is supervised by runit and the incredibly well written runit cookbook.
Using the Webrick as a base it’s fairly easy to get labels added to your MRs when they are opened. When the request comes in to your webrick server, look at the GitLab “object_kind” to see if its an MR.
If the code is a merge request, the next step is calculate the labels that should be applied to the MR. In our case that is a ‘Needs Review’ label if the MR is just being opened. Then because we use semver and thor-scmversion we just scan all the commit messages for ‘#patch’, ‘#minor’ and ‘#major’ to apply the appropriate semver tag to the MR.
You will need a valid GitLab API key to modify and or request data about an MR.
You will need to do some extra work to make this work on updates. For updates you will need pull the current labels and merge them where appropriate. This is necessary to update the labels when a subsequent commit to the MR takes it from a #patch to a #minor or #major.
You should thread your webrick server so the processing of the updating of incoming requests is in an different thread than the accepting of webhooks from GitLab. If you don’t do multi-thread you may run into issues where GitLab resends the webhooks because of a timeout. The default timeout in GitLab is 10 seconds. Simple threading with ruby thread and a queue should be sufficient.
Thanks to my colleague Cameron McAvoy who added the label processing to the original webhook server I wrote.