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