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?
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!
Comments
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:
Where as my docker build job is marked with: 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:
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.