AWS CodePipeline with CodeBuild supports GitHub webhooks, export artifacts between stages, many types of caching (S3 artifact caching, Docker caching, file/volume caching), Secrets Manager environment variable integration, queueing between stages, pipeline retries, stage retries, manual approval steps, integration with CloudWatch and many of services like Lambda, and provisioning all of the above via API, CLI, SDK, or CloudFormation.
Jenkins Is Getting Old
191–200 of 340 posts
Re: Jenkins Is Getting Old
#192See https://build.gocd.org/ for the live instance of GoCD used to build Gocd (apache licensed CD orchestration tool backed by Thoughtworks).
Re: Jenkins Is Getting Old
#193AWS CodePipeline with CodeBuild supports GitHub webhooks, export artifacts between stages, many types of caching (S3 artifact caching, Docker caching, file/volume caching), Secrets Manager environment variable integration, queueing between stages, pipeline retries, stage retries, manual approval steps, integration with CloudWatch and many of services like Lambda, and provisioning all of the above via API, CLI, SDK, o…
And the beauty of CodeBuild is that if you need a custom build environment just for your special snowflake build, it’s as easy as creating a Docker container and it won’t interfere with anyone else’s build environment.
Re: Jenkins Is Getting Old
#194Earlier quoted context omitted.
I assumed OP felt that the background UI's fictional butler (a metaphor) is what offended them so I asked why this was the case. Many downvotes ensued.
Pretty sure they meant the UI is so ugly it's offensive.
If it was only ugly. No, Jenkins UI is the dumpster fire that you would have gotten 20 years ago throwing a bunch of ActiveX components onto a VB panel. Like, let me just drag this Camera component to my snazzy program.
Any one click can be a gateway into a one million miles deep rabbithole of unbridled mediocrity and brokenness.
Re: Jenkins Is Getting Old
#195Earlier quoted context omitted.
Last place I was at had their unmanaged Jenkins servers get compromised and used to run crypto miners.
Were they using an older version of Jenkins on the public internet? There's been a randomized GUID applied to the initial Jenkins admin password, which you can only access if you have direct access to the Jenkins install. I think this was added in 2016.
It was an older version with a vulnerability but as far as I know not a default password.
Re: Jenkins Is Getting Old
#196Earlier quoted context omitted.
Could I ask you to elaborate on the downstream build issues? Thanks!
We had the problem that whenever we built a project it would trigger builds of any project that transitively depended on that module. So if you have e.g. 26 projects depending on each other in a line and you make a change to the first one, in jenkins this will run 26 builds as it builds A, then B, then C, .... . Whereas in Teamcity it will run 26 + 25 + 24 + ... builds: it'll build A, then B-Z immediately, then the b…
It sounds like those builds weren’t quite set up correctly. I’ve used TeamCity’s build chains quite a bit and haven’t seen this behavior. Depending on exactly how the builds are triggered it will sometimes enqueue redundant builds, but as the duplicates come to the top of the queue the server realizes they’re unnecessary and doesn’t run them.
Re: Jenkins Is Getting Old
#197Hello, I see a lot of great feedback in this post. I am a product manager working at CloudBees, the primary corporate sponsor of Jenkins. Jenkins is now in the Continuous Delivery Foundation as well. While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part o…
> While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part of their daily work activities AND also in their off hours.
I've been using Jenkins heavily over the past year since a client of our purchased the enterprise version. It was billed to me as a mature open source product that has been refined over the years by people trying to optimize their dev operations. While I'm sure some people really care about it, the user experience is so utterly disappointing it's almost impossible to imagine how it got to this state without neglect.
Even if you ignore all the complicated stuff, the web UI is embarrassing. While I don't suggest a "pretty" UI is necessary for devops, I would think you'd have a quick win just by having some people re-style the existing UI to make it look and feel like something built this century and not require a dozen clicks to get to important information. There are also bugs that are so painfully obvious it makes me wonder how they still exist. An example is if your Github branch has a slash in it (eg. feature/something) you get a 404 error if you try to navigate to that builds' results.
There are also features that appear to have almost no value yet are in the core UI and clearly took some time to build. The weather icons representing various permutations of previous build states is one ridiculous example that comes to mind.
I would respectfully suggest you run through some real world Jenkins experiences like the ones mentioned in the article. Also setting up a new server, configuring non-trivial SCM settings, debugging Jenkinsfiles, etc. To echo the article's sentiment - it feels like I'm constantly fighting with Jenkins to do what I need instead of being guided into a mature set of features.
Conversely - Octopus Deploy is a related product I have been using alongside Jenkins which has been an absolute joy to work with. Everything from initial setup to configuring its agent software on host servers has been straightforward. It has a simple, elegant UI that provides access to important information and actions where you would hope to see them. And most importantly - everything works. I have yet to encounter a bug or experience any broken UI states.
I'm glad to hear CloudBees is making some effort to improve things and I hope PMs like you continue to be involved in the community and solicit feedback, even if it's hard to hear sometimes.
Re: Jenkins Is Getting Old
#198Of all the undifferentiated heavy lifting you can offload to your cloud provider, CI makes a lot of sense:
- You probably want to store artifacts in its object store anyway.
- Rent exactly the right amount of compute for the concurrent builds running in any given minute.
- If your projects have sufficiently simple build-and-test entrypoints i.e. "make" then you're highly portable and not too worried about lock-in. You don't even need to be deploying to the cloud provider you're building on.
Re: Jenkins Is Getting Old
#199Earlier quoted context omitted.
You can definitely do all of your requirements, but likely as a result of recent features 1) you can customise the git checkout depth and style: https://docs.gitlab.com/ee/ci/yaml/#shallow-cloning https://docs.gitlab.com/ee/ci/yaml/#git-strategy 2) https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic 3) https://docs.gitlab.com/ee/ci/yaml/#tags I'm not associated with gitlab at all but happy to give pointers if anyone…
2) was released in October, about six months ago [0]. I'd also like to add: as a user of GitLab for about a year now, their steady rate of feature releases has bene pretty pleasant, even if I can't take advantage of some right away. [0] https://about.gitlab.com/2018/10/22/gitlab-11-4-released/#ru...
I'm not sure that's what I needed. For example, I wanted to trigger a job only for a merge request, and only if the target branch of the merge request is e.g. master. Is that possible? Trigger a job only for a MR is possible, but I don't know how to further do the later branch filtering.
Re: Jenkins Is Getting Old
#200Earlier quoted context omitted.
Both work ?
No, the key difference is that Nagios has perfectly viable alternatives (Zabbix admin here and it's not the only one). Jenkins however has no alternatives. Bamboo or whatever it is called now is typical Atlassian crapware. Expensive as fuck, eats more resources than the stuff it builds, and did I mention it is yet another half assed product that got shoddily integrated into the usual Atlassian lineup? Gitlab CI is gr…
Teamcity?