4 ms·

I'm using GitLab CI. I use GitLab.com for the free private git project hosting. GitLab.com has free CI servers available (even for private projects) that work w

I'm using GitLab CI. I use GitLab.com for the free private git project hosting. GitLab.com has free CI servers available (even for private projects) that work well if you don't need to run builds all the time. A lot of people use their shared CI runners, so your jobs/builds might take several minutes before they start running. If you have a larger need, you can always host your own runners (software is FOSS). GitLab's CI has a pipeline design, so (like Jenkins) you can have some jobs wait for other jobs to complete and use their build artifacts (e.g. have a single build job that downloads deps and compiles everything so later jobs don't need duplicate that work), and you can have jobs only be triggered manually instead of on every push. It's not perfect, though. For instance, unlike TravisCI, you don't have a build matrix, but you can use YAML tricks to define template jobs (see GitLab's own CI file [0] and a resulting pipeline [1]). If you use GitLab.com, you should be aware that they have downtime a few times each month, both planned and unplanned. For their planned downtime, it is often during the work day in the US timezones, and usually lasts between 10-30 minutes (though it has been longer before). GitLab.com is also used as a "testing in production" environment for their monthly releases, so you will occasionally run into bugs (usually nothing showstopping though; mostly minor annoyances). I think that what you choose greatly depends on what you need. GitLab CI is a little opinionated, but it is still pretty flexible and usable for a large number of work cases. If you need a ton of customizability, Jenkins could be a better option (with plugins). GitLab CI is a lot easier to setup, however. GitLab CI also has CD features that you can look into (I don't use them myself). They are also constantly (i.e. every 22nd of the month) releasing new versions, and most of their features are open source. [0]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-... [1]: https://gitlab.com/gitlab-org/gitlab-ce/pipelines/6014043 https://gitlab.com/gitlab-org/gitlab-ce/pipelines/6014043

jazoom 10y ago
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?
- trcollinson 10y ago
  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.
  - 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

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?

trcollinson 10y ago
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.
- 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.