Do you use it for building docker images? I can't work out how to tag my images with versions. They all become "latest". Do I have to change the gitlab config file every push?

I came to second Gitlab CI. I build all of my docker images in Gitlab CI and tag them. The trick is to use the gitlab ci environment variables (I tag with with the git tag or the git branch name depending using this method). If you would like to get a bit more help, feel free to email me. My username here at gmail.

That's very kind of you. Thanks. I think I understand how you do it. You just tag the git commit and get that value in the build by using $CI_BUILD_TAG?

The description for that variable says it's only available when building a tag. Does that just mean the commit needs to be tagged before a push?

Update: I just found this, which is probably exactly what I want to do: https://github.com/gitlabhq/gitlab-ci/issues/637

Update 2: Wait. What? This doesn't sound right. Now I'm confused: https://docs.gitlab.com/ce/ci/yaml/#tags

Update 3: It seems those are 2 different types of "tag", both mentioned in the same configuration subobject. Crazy.

So yes, you got it! They use the word "tag" in two totally different ways which is confusing.

When you create a gitlab-ci runner you can "tag" the runner. Basically, this is like a named server. For instance, I have a general gitlab-ci runner which I use to run most of my builds. However, I found that I need a special runner just for building docker images. So most of my jobs in my gitlab-ci are marked with:

  tags:
   - general

Where as my docker build job is marked with:

  tags:
   - docker-builder

This basically pushes the job to a specific runner and has nothing to do at all with the git ref (which could be a branch name or a tag or whatnot).

Now when do I build docker containers? I actually don't use "git ref tags" (i.e. git tag v.1.16.001 or something). I have a development branch, a staging branch, and a production branch which tie to my environments (dev, staging, and production). So my job runner looks something like this:

  stages:
   - test
   - build
   - deploy
  
  docker_build:
    stage: build
    script:
     - do some stuff
     - docker tag container-name:$CI_BUILD_REF_NAME $AWS_ACCOUNT_ID.$AWS_ACCOUNT_REGION.amazonaws.com/container-name:$CI_BUILD_REF_NAME
     - docker push $AWS_ACCOUNT_ID.$AWS_ACCOUNT_REGION.amazonaws.com/container-name:$CI_BUILD_REF_NAME
    tags:
     - docker-builder
    only:
     - development
     - staging
     - master

So basically once the tests pass, and IF the branch is development, staging, or master, it will build the docker container, using the CI_BUILD_REF_NAME as the tag and then push that to my private aws container storage system. The AWS_ACCOUNT_ID and REGION are both environment variables I have injected previously. If that succeeds it moves to the deploy stage.

Thanks for taking the time to share your experience. What's the difference with your docker runner? I've been building docker images just fine without specifying a runner.

I run most of my runners as Docker runners and I was having issues with a Docker runner building a docker image. So I swapped to a different method. But I haven't tried it in a while. I might be able to use the same Docker runners now. Seems like a good time to test it!

Okay. Thanks again.

What do you with your docker images after they are build? This is the one thing missing from my CD pipeline.

Good question! So first I build the docker container with a Dockerfile I keep at the root of my project. I also have an aws private docker repo. (Read more about it here: https://aws.amazon.com/ecr/). So in my gitlab-ci I have a statement like the following:

  - docker build -t container-name:$CI_BUILD_REF_NAME .
  - docker tag container-name:$CI_BUILD_REF_NAME $AWS_ACCOUNT_ID.$AWS_ACCOUNT_REGION.amazonaws.com/container-name:$CI_BUILD_REF_NAME
  - docker push $AWS_ACCOUNT_ID.$AWS_ACCOUNT_REGION.amazonaws.com/container-name:$CI_BUILD_REF_NAME

This builds my container, tags it, and pushes it to my ec2 container registry. I do most of my deployments using AWS ECS (EC2 Container Service, you can read more about it here: https://aws.amazon.com/ecs/)

My secret sauce is in the deployment stage of my ci. I basically run a command which deploys to a ECS environment. This is a custom script which is part of my overall AWS process. I have scripted out the creation of everything on AWS (from building the environment, spinning up EC2's, security and security groups, auto scaling groups, container registry, deploying jobs into an ECS). In the current project I am in we are using Ruby so the command is just a rake task and looks like:

  stages:
   - test
   - build
   - deploy
  
  docker_deploy:
    stage: deploy
    script:
     - do some stuff
     - rake awsenv:redeploy[$CI_BUILD_REF_NAME]
    tags:
     - general
    only:
     - development
     - staging
     - master

The rake task logs into the awsapi securely, runs some commands, verifies the work, and calls the task complete in gitlab-ci. If you have any further questions, feel free to email me. It's my username at gmail.

Thank you for giving such a comprehensive answer.