4 ms·

Concourse is an amazing project, but sadly is very if you are trying to build around a docker type of workflow. This[1] is for us a showstopper atm, so we are

Concourse is an amazing project, but sadly is very if you are trying to build around a docker type of workflow. This[1] is for us a showstopper atm, so we are sticking to go.cd, although Jenkins seems to be improving a lot lately. [1] https://github.com/concourse/concourse/issues/324 https://github.com/concourse/concourse/issues/324

Roritharr 10y ago
Thats interesting, GitLabs recent focus on the Docker workflow was one thing that irked me, since we won't be using Docker for the foreseeable future and I'm missing quite a few features to replace Jenkins completely. Has concourse good options for manual deployment?
- fuzzyninja 10y ago
  It surely does. Also, their learning materials are great too. I found to be able to get a basic pipeline in a matter of a couple of hours. If you don't have a docker heavy type of dev workflow, I think it is a great alternative. Totally worth checking it out.
- jobvandervoort 10y ago
  Note that with GitLab CI, you can having anything run your build. It's just that we typically use Docker as an example and use it ourselves most intensely. GitLab Runner (the 'slave' that runs your code), is just a Go binary, so it runs on anything you can run a Go binary on, which is pretty close to all major platforms. Read more on Runner here: http://docs.gitlab.com/ce/ci/runners/README.html http://docs.gitlab.com/ce/ci/runners/README.html And congrats to the Jenkins team! This looks amazing. A majority of our customers uses Jenkins. I'm sure they'll be excited to update.
  - gearlles 10y ago
    My problem with Gitlab CI is that it's not as smart as Jenkins for Java projects. Jenkins beautifully handles maven multi-module projects and knows how to install the dependencies. All other CI-systems are available in Gitlab CE, but Jenkins integration is only available on Gitlab EE. That's the only reason my team doesn't use Gitlab as code repo.
- jacques_chester 10y ago
  You don't have to "use docker" to use Concourse. It runs docker images under the hood. It only becomes relevant when you define which container image to use to run things. After a little while you'll realise you want something a bit different, at which point the docker-image resource that's supported by the Concourse team makes it embarrassingly easy. You just tell Concourse "yo, push to this image" and it does the rest.

Roritharr 10y ago

Thats interesting, GitLabs recent focus on the Docker workflow was one thing that irked me, since we won't be using Docker for the foreseeable future and I'm missing quite a few features to replace Jenkins completely. Has concourse good options for manual deployment?

fuzzyninja 10y ago
It surely does. Also, their learning materials are great too. I found to be able to get a basic pipeline in a matter of a couple of hours. If you don't have a docker heavy type of dev workflow, I think it is a great alternative. Totally worth checking it out.
jobvandervoort 10y ago
Note that with GitLab CI, you can having anything run your build. It's just that we typically use Docker as an example and use it ourselves most intensely. GitLab Runner (the 'slave' that runs your code), is just a Go binary, so it runs on anything you can run a Go binary on, which is pretty close to all major platforms. Read more on Runner here: http://docs.gitlab.com/ce/ci/runners/README.html http://docs.gitlab.com/ce/ci/runners/README.html And congrats to the Jenkins team! This looks amazing. A majority of our customers uses Jenkins. I'm sure they'll be excited to update.
- gearlles 10y ago
  My problem with Gitlab CI is that it's not as smart as Jenkins for Java projects. Jenkins beautifully handles maven multi-module projects and knows how to install the dependencies. All other CI-systems are available in Gitlab CE, but Jenkins integration is only available on Gitlab EE. That's the only reason my team doesn't use Gitlab as code repo.
jacques_chester 10y ago
You don't have to "use docker" to use Concourse. It runs docker images under the hood. It only becomes relevant when you define which container image to use to run things. After a little while you'll realise you want something a bit different, at which point the docker-image resource that's supported by the Concourse team makes it embarrassingly easy. You just tell Concourse "yo, push to this image" and it does the rest.