
Ask HN: GitLab Continuous Integration - xmatos
We use GitLab at my job (goread.com) and I&#x27;ve been taking a look at its continuous integration feature. I wanted to see if we could automate our deployments, specially to our staging environment.<p>Today, we use git feature branches and handle deployment to both staging and production using python&#x27;s fabric.<p>By default, GitLab&#x27;s CI runs on every feature branch push, which I dislike, since you can push a feature branch that isn&#x27;t ready for testing, for backup purposes. Although, it can be configured to automatically deploy only to staging, while having production deployment manually triggered. It can also run only on specific branches, like staging and master.<p>I was after a way to integrate deployment with task status updates, so once we updated a task status to Staging, for example, it would trigger a job to merge that task&#x27;s feature branches to staging and deploy it. Once it gets tested and approved, we would update the task status to Approved, which would trigger a master merge and a push to production. To me, this would be the perfect solution.<p>Unfortunately, that&#x27;s not how it works. It might be achievable through GitLab&#x27;s web hooks and api, but i don&#x27;t think it has a way to add a custom field to a task to store the related git branches and it only has an open &#x2F; close status. We could use labels instead and parse the task description to extract the branch info.<p>What I&#x27;ve done in the past and worked great is use git hooks for deployment. Basically, we would add the fabric tasks functionality to the post_receive git hook, so once we push the staging or master branch, it would automatically trigger deployment. That would handle deployment&#x27;s heavy lift, but I&#x27;d still like to automate branch merging, by linking it to task status.<p>In short, what I&#x27;d like to achieve is deployment based on task status updates.<p>Has anyone done that? Is it a good idea? Are there any caveats?<p>Any tips or ideas would be highly appeciated. Thanks!
======
bikebilly
If you could extract branch information from fabric tasks, and then merge the
branch with associated deployment handled by GitLab CI, the workflow would be
the simplest one. For that reason maybe you could investigate more on your
idea of parsing the task description, it could be a single point that solves
the matter.

As a side note, if you want to disable CI for a specific commit you can just
use [skip ci] or [ci skip] in the commit message and no pipeline is created
for that specific case.

