5 ms·

I'm a huge fan of Gitlab and use it at my workplace, but haven't upgraded to even 8.0 to try the continuous integration (CI) feature. Wikipedia makes it look pr

by ozborn 11y ago

I'm a huge fan of Gitlab and use it at my workplace, but haven't upgraded to even 8.0 to try the continuous integration (CI) feature. Wikipedia makes it look pretty comparable on features to more mature CI system like Jenkins but can anybody here say how the current CI in Gitlab 8.x really compares?

anthonycalabro 11y ago
Definitely a huge fan of GitLab, best open source solution and super easy to host locally.
dominotw 11y ago
I am curious about this as well. Is it a feature that has seen widespread adoption?
- sytse 11y ago
  GitLab CI has been hard to use for a long time since we didn't devote a lot of time to it (less than 1 person). But we saw it got traction nonetheless and opted to integrate it in the main GitLab application in 8.0. Since then it's popularity is growing fast, we added a lot of features (most recently build artifacts) and we have more than 2 people working on it full time.
xrstf 11y ago
[We're running a Gitlab instance and one CI instance with multiple CI runners in the Google Cloud.] Gitlab CI is great if you don't need dynamically provisioned build slaves, for which I found no integrated support. In general, Gitlab CI is much more straightforward and easy to use than Jenkins. Jenkins wins when it comes to stuff like build artifacts (getting these out of Jenkins is easy peasy (just wget them and provide basic HTTP auth if needed), but with GitLab I have not yet found a way to automatically download say the latest build results), credentials management and other "more enterprisey" features. Jenkins is easy to install on Debian-based systems; I have no real experience in setting up Gitlab other than via the official Docker images, which is nearly as easy as typing `apt-get install jenkins`. Setting up CI runners/instances is easy as well (apt-get install + one or two calls to gitlab-multi-runner). Overall I'm pretty happy with Gitlab CI. Especially the fact that every developer in our company can take advantage of automated builds by just enabling CI support and putting a .gitlab-ci.yml in the repository is great. Over are the days were admins had to manage Jenkins jobs.
- halfdan 11y ago
  Artifacts: http://doc.gitlab.com/ce/ci/yaml/README.html#artifacts http://doc.gitlab.com/ce/ci/yaml/README.html#artifacts
  - DanielDent 11y ago
    Getting artifacts into gitlab CI is pretty straightforward. But programatically pulling artifacts from gitlab CI does not seem to have a well-documented approach.
    - stuff4ben 11y ago
      shouldn't your build tool do that? If your build creates artifacts, I'd imagine you'd want to store them in an artifact manager (Nexus, Artifactory, etc) or deploy them.
    - sytse 11y ago
      We're working on an artifact browser for 8.4. I assume an API for that will be trivial after that has landed.
      - sytse 11y ago
        You can follow the work in this in https://gitlab.com/gitlab-org/gitlab-ce/issues/3426 https://gitlab.com/gitlab-org/gitlab-ce/issues/3426
        mijoharas 11y ago
        I gotta say, this is one of the killer features (for me) of gitlab. It's very actively maintained and constantly improving. (Nice to see that Mattermost is included automatically too, gonna have to enable that later and mess about with it!)
    - pliu 11y ago
      I sometimes have a similar issue with Travis CI, if I can't use one of their built in integrations or something. A simple workaround is to just upload an artifact to S3 after a successful build. Then on another system scan the bucket with a cron or listen for an S3 event notification for further processing. You can put a lifecycle policy on the bucket so it cleans up after a while too. It's sort of annoying to have to add on another system to the pipeline, but I think it's generally reasonable. Managing artifacts shouldn't really be part of the CI system anyway, I feel it's better to handle that stuff separately.
halfdan 11y ago
Gitlab CI is absolutely fantastic. I have a CI runner running on a Raspberry Pi under my desk and that thing just keeps running build jobs. The runner itself is an application written in Go that can run job locally or in a docker container.

by ozborn 11y ago

anthonycalabro 11y ago

Definitely a huge fan of GitLab, best open source solution and super easy to host locally.

dominotw 11y ago

I am curious about this as well. Is it a feature that has seen widespread adoption?

sytse 11y ago
GitLab CI has been hard to use for a long time since we didn't devote a lot of time to it (less than 1 person). But we saw it got traction nonetheless and opted to integrate it in the main GitLab application in 8.0. Since then it's popularity is growing fast, we added a lot of features (most recently build artifacts) and we have more than 2 people working on it full time.

xrstf 11y ago

[We're running a Gitlab instance and one CI instance with multiple CI runners in the Google Cloud.] Gitlab CI is great if you don't need dynamically provisioned build slaves, for which I found no integrated support. In general, Gitlab CI is much more straightforward and easy to use than Jenkins. Jenkins wins when it comes to stuff like build artifacts (getting these out of Jenkins is easy peasy (just wget them and provide basic HTTP auth if needed), but with GitLab I have not yet found a way to automatically download say the latest build results), credentials management and other "more enterprisey" features. Jenkins is easy to install on Debian-based systems; I have no real experience in setting up Gitlab other than via the official Docker images, which is nearly as easy as typing `apt-get install jenkins`. Setting up CI runners/instances is easy as well (apt-get install + one or two calls to gitlab-multi-runner). Overall I'm pretty happy with Gitlab CI. Especially the fact that every developer in our company can take advantage of automated builds by just enabling CI support and putting a .gitlab-ci.yml in the repository is great. Over are the days were admins had to manage Jenkins jobs.

halfdan 11y ago
Artifacts: http://doc.gitlab.com/ce/ci/yaml/README.html#artifacts http://doc.gitlab.com/ce/ci/yaml/README.html#artifacts
- DanielDent 11y ago
  Getting artifacts into gitlab CI is pretty straightforward. But programatically pulling artifacts from gitlab CI does not seem to have a well-documented approach.
  - stuff4ben 11y ago
    shouldn't your build tool do that? If your build creates artifacts, I'd imagine you'd want to store them in an artifact manager (Nexus, Artifactory, etc) or deploy them.
  - sytse 11y ago
    We're working on an artifact browser for 8.4. I assume an API for that will be trivial after that has landed.
    - sytse 11y ago
      You can follow the work in this in https://gitlab.com/gitlab-org/gitlab-ce/issues/3426 https://gitlab.com/gitlab-org/gitlab-ce/issues/3426
      - mijoharas 11y ago
        I gotta say, this is one of the killer features (for me) of gitlab. It's very actively maintained and constantly improving. (Nice to see that Mattermost is included automatically too, gonna have to enable that later and mess about with it!)
  - pliu 11y ago
    I sometimes have a similar issue with Travis CI, if I can't use one of their built in integrations or something. A simple workaround is to just upload an artifact to S3 after a successful build. Then on another system scan the bucket with a cron or listen for an S3 event notification for further processing. You can put a lifecycle policy on the bucket so it cleans up after a while too. It's sort of annoying to have to add on another system to the pipeline, but I think it's generally reasonable. Managing artifacts shouldn't really be part of the CI system anyway, I feel it's better to handle that stuff separately.

halfdan 11y ago

Gitlab CI is absolutely fantastic. I have a CI runner running on a Raspberry Pi under my desk and that thing just keeps running build jobs. The runner itself is an application written in Go that can run job locally or in a docker container.