Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The worst thing about Jenkins is that it works (2019)

twitchard.github.io

Post reply on HN
Print view View original

251–260 of 275 posts

Re: The worst thing about Jenkins is that it works (2019)

#251

Post by Tainnor »

MereInterest wrote: post #167
sevagh wrote: post #58

Earlier quoted context omitted.

>- Put all build/publish/test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well. The only interaction between a test runner and the codebase should be running `make `. This always breaks because then each platform has a specific way of defining env vars or secrets for those Makefiles and bash scripts. End result is devs still can't really run CI "proper" the way it's configure…

Maybe this is just me, but needing to define environment variables or secrets for testing seems like a massive problem in the test design. Does that mean the tests are dependent on the use of an external service, and that service can't be run locally? The only part of a CI pipeline I can imagine requiring secrets would be a release/publish step. However, those would only occur after the tests run successfully, so not…

Just to give some examples:

- your code is using private dependencies, so you can't build the code without authentication

- you have some integration tests that use test containers using private docker images, so you need to do a "docker login" before running tests

Locally, that would work because you're locally authenticated (and likely have all dependencies already installed etc.)

Re: The worst thing about Jenkins is that it works (2019)

#252

Post by skinner927 »

codethief wrote: post #233
thiht wrote: post #181

Earlier quoted context omitted.

That’s not my experience at all. You do know you can run arbitrary shell scripts, and that means they don’t need to think of every possible use case? If your CI process is so complex that YAML + arbitrary code doesn’t work, you might want to get that checked, it’s not normal

Random example: I want to define a setup job to build & push a base Docker image to our container registry. I then want to use this image as IMAGE in all subsequent jobs. This is impossible because the IMAGE field in YAML cannot be dynamic (determined at runtime) but I'd like to version/tag my image using the $CI_COMMIT_SHA.

The image may be determined at runtime, but it’s not required to exist until a runner picks up the job. So use the $CI_COMMIT_SHA in the image name and push the image in a job that runs before the other jobs that use the image.

You might also want to look into Downstream Pipelines.

Re: The worst thing about Jenkins is that it works (2019)

#253

Post by growse »

j1elo wrote: post #169
hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changi…

This is fine if you treat your CI provider as a "dumb shell runner". But good CI platforms have actually useful features and APIs (e.g. caching) and if you want to use them, a simple Makefile isn't going to work. For projects where the difference between a cold and warm cache build is tens of minutes, those features have meaningful quality of life improvements.

This may be a tradeoff you're ok with, but for a lot of people, it's not.

Re: The worst thing about Jenkins is that it works (2019)

#254

Post by Kelkonosemmel »

hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

I love GitHub actions and think gitlab is okay.

I found actions easier to use

Re: The worst thing about Jenkins is that it works (2019)

#255

Post by MereInterest »

Tainnor wrote: post #251
MereInterest wrote: post #167

Earlier quoted context omitted.

Maybe this is just me, but needing to define environment variables or secrets for testing seems like a massive problem in the test design. Does that mean the tests are dependent on the use of an external service, and that service can't be run locally? The only part of a CI pipeline I can imagine requiring secrets would be a release/publish step. However, those would only occur after the tests run successfully, so not…

Just to give some examples: - your code is using private dependencies, so you can't build the code without authentication - you have some integration tests that use test containers using private docker images, so you need to do a "docker login" before running tests Locally, that would work because you're locally authenticated (and likely have all dependencies already installed etc.)

Ah, I think I see. There is a dependency in the code that requires copying some external resource in order to build/run locally. The developer's local environment may have a different version of that resource than the CI, so a bug ends up not being reproducible. The developer may not run the CI directly, because the developer's access tokens should be separate from the CI's access tokens.

I was picturing a case where the CI was allowed privileged access to a resource to which developers were not allowed access at all.

Re: The worst thing about Jenkins is that it works (2019)

#256

Post by k_roy »

robertlagrant wrote: post #147
chologrande wrote: post #135

Earlier quoted context omitted.

How is Gitlab CI materially different from the jenkins model? I find that the only difference is that it's YAML - so even harder to debug, and maintains the same model where you must re run an entire pipeline every commit to test functionality.

You can run locally first to test functionality : - )

how dare you suggest something so pedestrian.

Re: The worst thing about Jenkins is that it works (2019)

#257

Post by j1elo »

growse wrote: post #253
j1elo wrote: post #169

Earlier quoted context omitted.

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changi…

This is fine if you treat your CI provider as a "dumb shell runner". But good CI platforms have actually useful features and APIs (e.g. caching) and if you want to use them, a simple Makefile isn't going to work. For projects where the difference between a cold and warm cache build is tens of minutes, those features have meaningful quality of life improvements. This may be a tradeoff you're ok with, but for a lot of…

C++ with templating can take a while to compile, so for caching my build system would include mounting a Docker volume with contents of ~/.ccache/. This was well integrated with the rest of the scripts, so it would work equally fine if I ran them in my laptop or in the CI runner.

My point is that I really don't believe that CI systems provide anything so unique that it couldn't be also provided by local software in a developer's laptop. If the question of "how do I build this in my laptop" is "you cannot, must use CI because we truly require some of its features", I'd consider that an ops failure.

However, I fully admit my experience comes from small to middle size projects. I cannot talk about big or huge scale projects. Maybe that's where needs grow so complex that CI features become truly necessary.

Re: The worst thing about Jenkins is that it works (2019)

#258

Post by concernedParty »

codethief wrote: post #233
thiht wrote: post #181

Earlier quoted context omitted.

That’s not my experience at all. You do know you can run arbitrary shell scripts, and that means they don’t need to think of every possible use case? If your CI process is so complex that YAML + arbitrary code doesn’t work, you might want to get that checked, it’s not normal

Random example: I want to define a setup job to build & push a base Docker image to our container registry. I then want to use this image as IMAGE in all subsequent jobs. This is impossible because the IMAGE field in YAML cannot be dynamic (determined at runtime) but I'd like to version/tag my image using the $CI_COMMIT_SHA.

Did you know that with Gitlab you can generate gitlab ci yaml in a job runtime and then run that yaml as a child pipeline using trigger:include:artifact?

This was the only way I could create dynamic terraform pipelines which changed depending on a plan output.

I'm sure could use it to achieve what you've described.

Re: The worst thing about Jenkins is that it works (2019)

#259

Post by duped »

growse wrote: post #253
j1elo wrote: post #169

Earlier quoted context omitted.

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changi…

This is fine if you treat your CI provider as a "dumb shell runner". But good CI platforms have actually useful features and APIs (e.g. caching) and if you want to use them, a simple Makefile isn't going to work. For projects where the difference between a cold and warm cache build is tens of minutes, those features have meaningful quality of life improvements. This may be a tradeoff you're ok with, but for a lot of…

Caching is the biggest reason why you shouldn't rely on CI platform "features" because they're quite bad at it. Roll your own and be happier with lower prices and no lock in.

Re: The worst thing about Jenkins is that it works (2019)

#260

Post by nblue »

devopseng85 wrote: post #223
codethief wrote: post #165

Earlier quoted context omitted.

> Gitlab CI is still the best CI in the game IMO, Oh god, if this is the best CI in the game, I don't want to be part of this game anymore. I work with (as in write pipeline code for) Gitlab CI almost every day and it's absolutely horrible. Not only does YAML lack any type safety whatsoever, but every day I run into yet another open ticket in the Gitlab issue tracker because using a declarative (YAML-based) approach…

I am surprised to hear this as well. We had Jenkins in my previous gig. It worked, but I spend all my time keeping it humming and learnt nothing else. In my current gig, we were a Drone shop. We switched to Harness CI enterprise and it’s worked really well for us. Their hosted builds are pretty speedy! We did evaluate Gitlab CI but went with Drone. Gitlab CI is not a top 5 CI vendor IMO.

Thanks to recognizing Harness! Full disclosure, I’m a harness employee, using Harness for CI/CD on a daily basis. Some of the best things in Harness to make us more productive at Harness, using Harness:

* Harness CI is the fastest CI solution on the market - through feature like ML-powered Test Intelligence, that allows running only the tests that are related to a code change, as well as other innovative capabilities. We use it heavily with our java applications and see test cycle reduction up to 80%. It can be used with Java, Ruby, .Net and other languages as well and the savings are significant. It also lowered our infra spent - lower build time means less build infrastructure costs

* Advanced CD: Advanced use cases like Blue/Green and Canary deployment, and rollbacks are available out of the box with Harness. No scripting is needed for implementing complex deployment use cases

* Visual pipeline editor, fully integrated with git - you can author pipeline as code in your git repo, but also - have a great authoring experience in Harness UI using yaml or visual editors. The visual editor make it super easy to understand existing pipelines as well as modifying them

* Plugins - harness support thousands of community plugins including Drone Plugins, Github Actions and Bitrise Steps in your CI Pipelines.

* Unbeatable Governance and Compliance - Harness provides robust, enterprise-grade governance for CI/CD processes. Using OPA-based policies and granular templates, customers can centrally enforce quality and security standards across all pipelines (for example, require security scans to be executed before deployment is allowed or which community plugins are allowed) .

* Reports and insights - looker based dashboard gives you many valuable reports out-of-the-box, but also the flexibly to create your own reports, so you can slice and dice the data based on your needs.

This is really just the tip of the iceberg , I encourage you to check out our website harness.io to get the full scope of our capabilities.

Cheers

Post reply on HN