151–158 of 158 posts
I'm late to the party. Concourse is difficult to come to from other CI tools. A little more aloof. There have been real, serious implementation difficulties. But I kinda love it, because it's a handful of simple ideas that unlock incredible power. It goes beyond "build and test each commit" to becoming a full project automation tool, a software manufacturing robot. When I talk to people about Concourse, I tell them:…
I'm late to the party. Concourse is difficult to come to from other CI tools. A little more aloof. There have been real, serious implementation difficulties. But I kinda love it, because it's a handful of simple ideas that unlock incredible power. It goes beyond "build and test each commit" to becoming a full project automation tool, a software manufacturing robot. When I talk to people about Concourse, I tell them:…
Why not put it up on youtube?
Earlier quoted context omitted.
> We also need the VMs to survive across build steps. You might represent them as a pool resource, so they can be safely handed from job to job. A lot of teams do this for stuff where they want to share an expensive, long-lived, stateful resource. Disclosure: I work at Pivotal.
The VMs are per job - once the CI run tests that the orchestration has created the right system config on the VMs, and that basic integration tests work, we destroy the VMs. I have worked in two companies now with Cloud Foundry distros, and both of them have started using Concourse, and then moved to Jenkins (for non Cloud Foundry projects - I shudder to think what would happen to a distro that attempted to not use C…
The Concourse->Jenkins thing will definitely happen without better docs, examples and widespread understanding. Concourse is non-obvious to newbies and the error messages need a lot of love. Or any love.
I don't quite understand the parenthetical, could you elaborate?
Refused to execute script from 'http://127.0.0.1:8080/public/index.js?id=932c553753eec4ef375... because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
Avoid! Concourse looks good on the surface but it's really not that great. The UI is clunky. The abstraction layer is too low and leads to a lot of repeated YAML. Which leads to YAML programming. There are simple scenarios like deployment rollbacks who are hard to do. For some reason they decided to develop their own container engine which leads to all sorts of trouble and maintenance issue. It's generally slow and w…
> Concourse looks good on the surface but it's really not that great. I've used teamcity, jenkins, gocd, circleci, concourse, and travisci. For multi-project systems, concourse is king. (I like travisci for by-itself, non-system projects) > The UI is clunky. What? You just said the UI looks good... It's simple and clean; everything is async javascript (no page loads). > The abstraction layer is too low and leads to a…
I meant that when just looking at the website, Concourse looks good in terms of what it has to offer. For example it offers proper build pipelines, something that is lacking in most other CIs.
Maybe it's clean to you, I found that our developers where generally confused by how the releases were working.
> Which is an intentional choice. If you don't like YAML, use one of the MANY yaml abstraction layers of your choice...
I don't mind YAML too much but adding a templating language on top is generally clunky. Gitlab CI also uses YAML, can also build pipelines and doesn't require to generate the YAML.
> Also I call rubbish on your 100% CPU.
It might have been due to a misconfiguration (we were using c4.4xlarge). I bet that you have deployed Concourse using BOSH, the only truly tested deployment method.
All things will break horribly if the conditions are right. It's unreasonable to assume that the things which work in [insert your current CI] will work in Concourse. It's still a new and relatively immature product, but it works well in most cases.
Half the secret to a good Concourse experience is not upgrading it in-place - stand up fresh deployments. The other half is gradually transitioning between Concourse deployments, because bad versions have been and will continue to be released - mistakes are only human. As long as you share the Concourse vision and are willing to keep up with the pace of change - not everyone can or wants to - then it's an amazing CI.
Concourse still makes me excited, even after many years of hard lessons, because it is a genuinely innovative approach to building better software. Most miss this, and I understand why, but give it time - the ideas behind it will mature and become the norm.
Even though Concourse can work really well, it's not always the best choice. Make it better if you can & want to, use something else if it's easier. There is no right or wrong, just preferences : )
Mostly off-topic but I've been looking for more than a CI for some quite time, more on the CD side. How are you guys handling some of these cases? Bonus points for hosted options. - Truly a pipeline based stages. No messing around with git branches/tags for each environment release. - Ability to combine multiple builds together. - Build dependencies. Ability to trigger project-B build when project-A build succeeds. (…
I used Octopus Deploy for .Net, it was amazing. It did releases as first-class objects (a collection of versioned packages pulled from a repository), per-environment configs, parallel execution of steps, rolling windows (for bouncing a few hosts at a time), pre- & post- activate scripts, and great IIS integration. There was talk of Python + Linux support a few years back, a shame that didn't take off.
You can do Linux today actually - you can connect to machines over SSH, run bash scripts, etc. Today there's a Mono dependency, but in the next couple of weeks we'll be rolling out a beta that removes that dependency.
Python scripting support is on the roadmap - :-)
I evaluated concourse CI and I was impressed by the concept. Pros - Setup was really easy.(I didn't use bosh). - Both server and build pipeline configuration (Yaml file) are easy to backup and recreate. Cons - When I evaluated it , it had a few bugs which forced me to restart the server almost daily to keep it working. It should be more stable now. -
Did your evaluation happen a long time ago? Or, another question... did you run the binaries and appropriately screen them? I had the same problem until I realized I sucked at making a binary live a long time, and my eyes were opened to screen :)