GitLab's CI runs on every branch push, which I dislike, since you can push a branch that isn't ready yet 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.

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's feature branch 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.

Unfortunately, that's not how it works. It might be achievable through GitLab's web hooks and api, but i don'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 / close status. We could use labels instead and parse the task description to extract the branch info.

What I've done in the past and worked great is use git hooks for deployment. That would handle deployment's heavy lift, but I'd still like to automate branch merging, by linking it to task status.

Has anyone done that? Is it a good idea? Are there any caveats?

Any tips or ideas would be highly appeciated. Thanks!