3 ms·

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 de

by jazoom 10y ago

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 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 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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      Okay. Thanks again.

by jazoom 10y ago

trcollinson 10y ago

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 10y ago
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 10y ago
  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 10y ago
    Okay. Thanks again.