[xmatos]

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!

[wibbleywobbley]

>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.

What's the downside of deploying a review app for something that's "not ready"? It's (presumably) just deploying to a development-only environment of some kind anyway. I'd also argue that you should be pushing almost as regularly as you commit. It increases the opportunity for discussion of what you are working on and it's also useful to know "does this still successfully deploy?"

Here's an excerpt of a .gitlab-ci.yml file from one of my projects: https://gist.github.com/kelchm/fc8ca06dd3e44a42fa640ed7a8e84...

Basically, the functionality is as follows:

1. Any branch other than 'master' automatically deploys to a development environment (AKA a 'Review App'). Multiple of these review apps can exist in the development environment.

2. Merges into master are automatically deployed to staging

3. Tags which match the form '/^v.*$/' are considered production releases and result in a manual deploy job being created.

It's a really simple and powerful workflow.

[evilduck]

It's been a while since I've been on Gitlab, but you used to be able to add `[ci skip]` to a commit message and CI wouldn't run. It does litter your git history with CI information though.