[jazoom]

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.

[trcollinson]

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.

[jazoom]

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.

[trcollinson]

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!

[jazoom]

Okay. Thanks again.