41–50 of 158 posts
Kind of odd to see the homepage show Vagrant as the install mechanism, even though it supports Docker as well. In 2017, I'd think more developers are likely to run Docker than Vagrant workloads on their machine.
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 took part in evaluating Concourse CI for the needs of my company (30+ devs). While it has amazing CI pipeline capabilities, we ultimately didn't select Concourse because it felt much more like a CI toolbox, requiring some development to put those tools to use. And what we really wanted was more of a turnkey CI product. Perhaps ironically, we ended up doing some development around the edges of the CI product we ulti…
The best CI is the one where you write code to build/deploy etc.
Wrangling with some moronic UI exposed by the CI product to abstract code is simply wrong. Don't do CI/CD like this.
UI is pretty but often breaks. Is unusable when you have a pipeline with dozens of concurrent jobs.
Concept of teams is fine, but when you have to switch between them, even with oauth authentication, it is a pain.
Job concurrency control is binary.
We never have been able to have worker pool scale down without a hiccup, always some darn worker hogging containers and atc not removing it, leading to stalled pipelines.
That overlay network it comes with, garden thingy, creates so many problems and solves just one...
Oh and not having BUILD_ vars available in tasks is rude, thank you very much, but there are cases when it is just mandatory and concourse makes it impossible to do.
At least new version has better secrets handling, previously it was a joke.
Earlier quoted context omitted.
Cool to hear you selected GitLab. We recently added multi project pipeline visualization. That was partially inspired by concourse CI. Is there anything else you would like to see?
Interesting you should mention that. Right around the time you implemented multi-project pipeline visualization, we built a bot that listens for GitLab build completion events, hits the (undocumented /unsupported) internal GitLab global code search ElasticSearch index, finds downstream dependencies of the completed build (as declared in setup.py/package.json), and triggers their builds as well.. Taking full advantage…
We do not have immediate plans to ship that yet, but I pinged our product team member there. However we do have plans to ship multi-project pipeline with an "inversion of control".
You will be able to specify pipeline relation with an upstream project, and when someone pushes a commit to it, a downstream pipeline is going to be trigger automatically. See an issue about cross-project dependencies - https://gitlab.com/gitlab-org/gitlab-ee/issues/1681!
Rather than "Rather than a myriad of checkboxes..." it should be "Rather than myriad checkboxes..."
Typo on front page. Rather than "Rather than a myriad of checkboxes..." it should be "Rather than myriad checkboxes..."
Typo on front page. Rather than "Rather than a myriad of checkboxes..." it should be "Rather than myriad checkboxes..."
> Usage Note: Throughout most of its history in English myriad was used as a noun, as in a myriad of reasons. In the 1800s, it began to be used in poetry as an adjective, as in myriad dreams. Both usages in English are acceptable, as in Samuel Taylor Coleridge's "Myriad myriads of lives." This poetic, adjectival use became so well entrenched generally that many people came to consider it as the only correct use. In fact, however, both uses are acceptable today.