“Leeroy Jenkins” is what my backend guys say right before the huck a major DB upgrade into prod without testing it in staging.
Who is this "Jenkins" and what now has broken him?
Submitted 1 year ago by the_artic_one@programming.dev to programmer_humor@programming.dev
https://programming.dev/pictrs/image/2dc67e8f-5106-441b-a0c1-4572ffefcc5e.png
Comments
Ghostalmedia@lemmy.world 1 year ago
intelati@programming.dev 1 year ago
Always Friday at 16:59 right?
Ghostalmedia@lemmy.world 1 year ago
Right before a long weekend where Monday is a government holiday.
Also, Leeroy tried to optimize his PTO and hooked a backpacking trip onto the long weekend. He will be out all week and will have no phone reception.
CodeBlooded@programming.dev 1 year ago
Real talk- I agree with this meme as truth.
The more and more I use CICD tools, the more I see value in scripting out my deployment with shell scripts and Dockerfiles that can be run anywhere, to include within CICD tool.
This way, the CICD tool is merely a launch point for the aforementioned deployment scripts, and its only other responsibility is injecting deployment tokens and credentials into the scripts as necessary.
Anyone else in the same boat as me?
I’d be curious to hear about projects where my approach would not work, if anyone is willing to share!
synae@lemmy.sdf.org 1 year ago
You’re not advocating against CI like the meme seems to be, but rather for CI builds to be runnable on human’s machines and the results should be same/similar as in when running w/in the CI system. Which is what CI folks want anyway.
xilliah@beehaw.org 1 year ago
What about related tools such as viewing artifacts such as for example total memory usage, and graphing that in the browser.
And sending emails, messages etc in case of a failure or change.
CodeBlooded@programming.dev 1 year ago
Most of those things mentioned aren’t bona fide needs for me. Once a developer is deploying their project, they’re watching it go through the pipeline so they can quickly respond to issues and validate that everything in production looks good before they switch contexts to something else.
I see what you’re saying though, depending on what exactly is being deployed, the policies of your organization, and maybe expectations that developers are working in another context once they kick off a deployment, it could be necessary to have alerting like that. In that case it may be wise to flex some features of your CICD platform (or build a more robust script for deployment that can handle error alerting, which may or may not be worth it).
gandalf_der_12te@feddit.de 1 year ago
Honestly, CI is only meaningful on bigger projects (more than 100 man-hours invested in total). So I most often go without.
But I do see its point.
devious@lemmy.world 1 year ago
I don’t think there is a single right or wrong answer but to play devils advocate making your CI tooling lightweight orchestration for your scripts that do the majority of the work means you lose the advantages of being able to easily add in third party tools that you want to integrate with your pipeline (quality, security, testing, reporting, auditing, artefact management, alerting, etc). It becomes more complex the more pipelines you are creating while maintaining a consistent set of tooling integrations.
killabeezio@lemm.ee 1 year ago
Then you would probably enjoy concourse
LOLjoeWTF@lemmy.world 1 year ago
Ah, good 'ol Jenkins. It’s on my list of software I never want to use again, twice.
One feature was really sweet though: being able to edit the Jenkinsfile script inline and run it. On the other hand, that encouraged the wild cowboy lands. Contrasted to GitHub Actions, you get to see how many commits it took to get right 🙃
countsickness@kbin.social 1 year ago
Nobody will see me force push to "bugfix/gitlabCI" the 10th time today...
astral_avocado@programming.dev 1 year ago
What’s wrong with Jenkins? Works pretty great for automated scripts that need to run on a schedule, but I imagine you and this post specifically mean in reference to CI/CD
xedrak@kbin.social 1 year ago
I work for a very large company which uses Jenkins for CI/CD and it’s an absolute nightmare. Granted, some of these issues may be related to how my company has it setup. I’m not in DevOps so I wouldn’t know. But these are my complaints:
-
Can have incredibly long queue times in some cases. It takes forever to spin up additional build agents to meet demand. In one case we actually had to abort a deploy because Jenkins wasn’t spinning up more build agents, and our queue times were going to put us outside of our 3 HOUR maintenance window.
-
Non-standard format for pipeline configuration files. It could just be JSON or YAML, but noooo, I have to learn something completely different that won’t transfer to other products.
-
Dated and overly complicated UI with multiple UX issues. I can view the logs in a modal from the build page, but I can’t copy from them? Fuck off Jenkins.
I’m actively pushing my team to transition to GitHub actions, because it’s just better in every single way.
-
Lanthanae@lemmy.blahaj.zone 1 year ago
Counterpoint: watching little green checkmarks appear when my PR passes a pipeline step gives me dopamine
synae@lemmy.sdf.org 1 year ago
Allow me to blow your mind: my Jenkins build calls build.sh because I’m not a fuckin idiot
argv_minus_one@beehaw.org 1 year ago
If you want to take Cargo away from me, you’ll have to pry it from my cold, dead claws. 🦀
sip@programming.dev 1 year ago
I don’t think cargo is the problem. it’s idiomatic and it’s like “build.sh”
argv_minus_one@beehaw.org 1 year ago
Cargo fetches dependencies, runs a variety of build tasks, can build a typical Rust project with little or no build scripting, and is configured with a straightforward TOML file. It’s not at all like a hand-written shell script. It’s also much more pleasant to use than any other build system I’ve seen, including shell scripts.
r00ty@kbin.life 1 year ago
Joke's on you. I have a Jenkins hook from github to trigger build.bat! :P
Sigmatics@lemmy.ca 1 year ago
Yeah sure. Try building anything more complex than helloworld.c with a build.sh
jcg@halubilo.social 1 year ago
More complex build systems are just build.sh calling other build.sh in different configurations and using different software. It’s build.sh all the way down.
Sigmatics@lemmy.ca 1 year ago
The point is that “build.sh” implies a single time, which becomes an absolute nightmare to maintain on larger projects
cupcakezealot@lemmy.blahaj.zone 1 year ago
He just wanted his priest tier 0 set.
YurkshireLad@lemmy.ca 1 year ago
If I break our master build in CI, I get multiple emails and people saying “fix this”!!! I wouldn’t have to fix it if you stopped letting people commit directly to master and stopped using git rebase! 😁
GlitchSir@lemmy.world 1 year ago
The build system issue is getting out of control. Just look at cmake
When your build system is a build system for build systems you know something went wrong years ago
MonkderZweite@feddit.ch 1 year ago
build.sh is no build system?
MattTheProgrammer@kbin.social 1 year ago
I've been using Gearset for Salesforce CI/CD for a while and it's pretty simple to get up and running and it just kind of works. I'm looking into integrating it with Azure for our .net stack but not sure how smoothly that will go.
fkn@lemmy.world 1 year ago
I know this is a meme, but just in case someone doesn’t actually know. CI saves literally thousands upon thousands of dev hours a year, even for small teams.
CoderKat@lemm.ee 1 year ago
As annoying as it is when someone else breaks the CI pipeline on me, it is utterly invaluable for keeping the vast majority of commits from being able to break other people (and from you breaking others). I can’t imagine not having some form of CI to preventing merging bad code.
csm10495@sh.itjust.works 1 year ago
You should have seen my last job.
Eufalconimorph@discuss.tchncs.de 1 year ago
Even better is when you restrict merges to trunk/main/master/develop (or whatever you call it) to only happen from the CI bot *after all tests (including builds for all supported platforms) pass. Nobody else breaks the CI pipiline, because breaking changes just don’t merge. The CI pipeline can test itself!
TheBananaKing@lemmy.world 1 year ago
I often wonder if there isn’t some goodharty kind of local-maximum trap hiding in this…
devious@lemmy.world 1 year ago
Why waste time with CI when you can save on thousands of dev hours by limiting yourself to only one giant fuck off release every year!
/Taps forehead so hard it causes brain damage
Jajcus@kbin.social 1 year ago
And a lot of users' frustration, especially on more niche platforms (Linux, ARM, etc.) - things look much better on release when the code have been regularly compiled and, hopefully tested, on all platforms, not just the one the lead developer uses.
Dasnap@lemmy.world 1 year ago
It wouldn’t surprise me if this meme was made by an ops guy.
synae@lemmy.sdf.org 1 year ago
Ops loves CI systems, if the artifact doesn’t come from Jenkins (or friends) it simply doesn’t exist to us.
engineZ@lemmy.today 1 year ago
Probably also causes lots of hours of maintenance and troubleshooting…but it’s a net gain in the end.
fkn@lemmy.world 1 year ago
I can’t even imagine not having a ci pipeline anymore. Having more than a single production architecture target complete with test sets, Security audits, linters, multiple languages, multiple hour builds per platform… hundreds to thousands of developers… It’s just not possible to even try to make software at scale without it.