81–90 of 106 posts
When I started using Travis I immediately got a fan of it. Not having worked with Jenkins before, when I first tried it (pre-blue ocean), I was shocked by the unnecessary complexity. Since then, I've settled with a self-hosted drone.io for private projects, it offers a very similar experience to Travis, while I don't feel like I'm lacking anything compared to Jenkins.
Does anyone have Jenkins in production and found it to be reliable and pleasant to use? I had to do lots of Jenkins integrations some time ago, and even though I tried to minimize the number of plugins and make things as simple as possible, things would randomly break from time to time or exhibit weird behaviour etc. I had the impression that Jenkins is deeply conceptually confused about some of its concepts, e.g. ho…
Pleasant? Never. I absolutely hate every time I have to launch a webpage to dig around and find out why my build failed. Automating jobs is a nightmare. I can cURL a request to kick off a build and do you know what it returns? NOTHING a 201 response with NO information to link to the build in progress. Oh there's a JSON API to see running jobs, but without some sort of ID, it's useless. Scripting is in Groovy. Want t…
To make it work, they had to cripple Apache Groovy so you can't use its functional collections-based functions. Not sure if you can really call it "Groovy" with that handicap.
It's not completely clear to me from reading the site - does this run a non-dockerized app build in kubernetes, or does it also work for building and deploying my app as a docker container itself? This usually requires things like being able to spin up a cluster of containers per build - one with my app, one with a database to run against, maybe one with memcached or elasticsearch for integration tests, etc. And does…
https://cloudplatform.googleblog.com/2018/04/introducing-kan...
Earlier quoted context omitted.
I actually think Jenkins is way too flexible for most use cases. We moved to GitLab CI which isn't perfect, but it provides safety rails/structure/opinions that pretty much provides an answer for everything you want to do, apart from maybe obscure corner cases that might not make sense for a CI/CD tool anyways. Also you get the close integration of your CI tool and your git repos, which is very nice from a visibility…
Thanks for using GitLab. We want to be supportive of cherry picking GitLab features. For example we just release CI/CD with GitLab for GitHub https://about.gitlab.com/features/github/ Is there something we can add to GitLab to make it more composable?
We are going to start experimenting with the new cloud native GitLab chart, but it would need to gain some maturity before we use it in production.
Do you know if the new GitLab cloud native helm chart will allow you to turn-off certain things like mattermost and prometheus? That was something that we didn't like about the omnibus chart because it exposed several extra services/ports that we didn't really want to manage/think about at the time.
Earlier quoted context omitted.
How are you liking GoCD? I've been looking for an alternative to GitLab for a while.
What can we improve in GitLab that would make you stay?
With regards to your question: I agree with user kerny.
Stop packing stuff on top.
What I want from Gitlab is to use it to manage my repos. If you improve that aspect (which is already fine though IMO), you'll make me happier.
If you improve Gitlab integration with other CI tools, you'll make me happier.
If you improve your CI solution (which I found lacking when I evaluated it 1.5 years ago -- no idea how it's now), I still won't use it -- I explicitly don't want to rely on one, integrated solution.
In my experience, such integrated solutions are fine for a while, until they aren't. My use cases tend to expand to things the integrated solution doesn't provide, and them I'm stuck.
Do one thing, and do it well. Doing yet more things detracts from Gitlab's appeal. Personally, I wouldn't mind you utterly removing Gitlab's CI tool (I know, not gonna happen, and that's fine -- just saying).
Looks interesting, * I use one namespace per env (staging, prod, etc), is this supported or must I go with the default (slightly wacky) staging and prod releases side-by-side in the same namespace? * How are bugfix releases handled? If I pushed 1.2.0 to staging, and want to hotfix the prod release 1.1.0 with 1.1.1 (a common bugfix flow), can I promote releases from the hotfix branch? * Is there a permission model? Do…
Promotion is either automatic or manual. By default Staging is automatic and production is manual. You can manually promote any version to any environment whenever you wish: http://jenkins-x.io/developing/promote/
For promotions we're delegating to the git repository for RBAC; so you can setup whatever roles you want for who is allowed to approve promotions & if you need code reviews etc
It's not completely clear to me from reading the site - does this run a non-dockerized app build in kubernetes, or does it also work for building and deploying my app as a docker container itself? This usually requires things like being able to spin up a cluster of containers per build - one with my app, one with a database to run against, maybe one with memcached or elasticsearch for integration tests, etc. And does…
Some useful work on building Docker containers without root: https://cloudplatform.googleblog.com/2018/04/introducing-kan...
It's not completely clear to me from reading the site - does this run a non-dockerized app build in kubernetes, or does it also work for building and deploying my app as a docker container itself? This usually requires things like being able to spin up a cluster of containers per build - one with my app, one with a database to run against, maybe one with memcached or elasticsearch for integration tests, etc. And does…
Yes we can support things like parallel steps & tests spinning up separate clusters, namespaces or environments (we do this ourselves to test Jenkins X).
We delegate to an OSS tool called Skaffold to actually build docker containers that gives us the flexibility to use different approaches for docker image creation (e.g. kaniko or Google Container Builder or use the local docker daemon etc) https://github.com/GoogleContainerTools/skaffold
Using Kubernetes as an engine for orchestrating containers works very well - thats kinda what Kubernetes was designed for. Though you are free to extend & integrate tools like ActiveMQ into Kuberenetes if you think it'll help your use cases.
Does anyone have Jenkins in production and found it to be reliable and pleasant to use? I had to do lots of Jenkins integrations some time ago, and even though I tried to minimize the number of plugins and make things as simple as possible, things would randomly break from time to time or exhibit weird behaviour etc. I had the impression that Jenkins is deeply conceptually confused about some of its concepts, e.g. ho…
Tolerable? Yes.
If using proper DSLs https://github.com/jenkinsci/job-dsl-plugin , https://github.com/hmrc/jenkins-job-builders, etc. you can at least version control, quickly clone/rebuild servers, create new builds and in general automate most of the CI/CD process.
But do I recommend Jenkins? No.
I can't find this in the docs; but what happens when a promotion fails? Do things get rolled back to previous known state? The reason I ask is because I"m trying to replicate similar functionality in our much simpler environment.