Earlier quoted context omitted.
Jenkins BlueOcean is one of the best "fancy UIs"
Thanks! My team and I made that and it was a lot of fun :)
No, thank you! It's fresh, it's infomation dense, it's fast, it works!
The worst thing about Jenkins is that it works (2019)
101–110 of 275 posts
Re: The worst thing about Jenkins is that it works (2019)
#102The part about using Docker is wrong. You can use the docker plugin and just run any image you want, and then run the code inside that specified image. You can pass additional parameters to also run it within the context of any particular docker build stage.
I use the same Dockerfile for production builds and for running all the CI related tasks, without any problems. And the same single pipeline is used for PR hooks and releases.
Post also mentions Blue Ocean UI, but that one is deprecated and should not be used at all.
Jenkins is far from perfect, but unless you can use Gitlab (and sadly you can not in every case), it is the most feature rich self-hosted tool out there. Just make sure you set it up with Jenkins Configuration as a Code plugin out of the box.
Re: The worst thing about Jenkins is that it works (2019)
#103Earlier quoted context omitted.
PHP dev here, we have extensions for development that make no sense in production, xdebug for example. You need it for breakpoints and debugging in general but it should not be installed in production. So we extend our production image and install it on top of it. Similarly, we include Composer (package manager) in the dev image only as we only need the installed dependencies in production but not the package manager…
Would multi-stage Docker builds not help here? Composer executes in one step and the result artefacts are copied into a "clean" PHP image without Composer installed.
Based on the description they are doing a multi stage build, but using the prod container as a base and then building the dev container atop that. But yes you could easily go the other way with dev building an artifact and adding it to a secure locked down container. This is less typical with dynamic languages that don't typically create a single binary, but still comes up. The downsides are that your prod container is now significantly different and for dynamic languages the fast feedback loop now has a slowish build step
Re: The worst thing about Jenkins is that it works (2019)
#104[deleted]
Re: The worst thing about Jenkins is that it works (2019)
#105The most interesting part IMO was at the end when op was noting his new company doesn't have teams/engineers create and maintain their own jobs. I've worked lots of different places now and something that's always frustrated me is how reticent engineering orgs are to reevaluate their processes and policies. Like it looks like his first org could have moved on from this problem by adopting the second org's policy. The…
There are tradeoffs. What happens when the CI team is a bottleneck? What happens when you have to frontload tasks you might not need because you’re afraid your release could be compromised?
What happens when the CI team says no and it introduces complexity in your system? Or you end up doing “shadow CI” on your machines to avoid conflict and escalation?
The complexity has to live somewhere. It is always worth evaluating the optimum place for your organization at any given stage.
Re: The worst thing about Jenkins is that it works (2019)
#106Earlier quoted context omitted.
PHP dev here, we have extensions for development that make no sense in production, xdebug for example. You need it for breakpoints and debugging in general but it should not be installed in production. So we extend our production image and install it on top of it. Similarly, we include Composer (package manager) in the dev image only as we only need the installed dependencies in production but not the package manager…
Would multi-stage Docker builds not help here? Composer executes in one step and the result artefacts are copied into a "clean" PHP image without Composer installed.
This what we are doing for the prod container that does not have Composer installed yes.
But in development it's much easier to have it in the image. Additionally we do not bundle the code in the dev image but bind mount it in Docker Compose, which is much faster than rebuilding the image to test changes in development; PHP not being compiled allows us to do that to reduce the feedback loop duration.
Re: The worst thing about Jenkins is that it works (2019)
#107Earlier quoted context omitted.
Gitlab is 29/month. It’s hard to stomach 29 + the money for GitHub and Jira, depending on the features you need. (Minimum 11/mo)
OP's company is paying for a dedicated CI team. Unless they have special needs, they probably aren't concerned about the CI hosting costs themselves.
I’ve worked at some places that were pretty huge, but the finance department absolutely fucking nickle and dime over everything.
Even the smallest EC2 instances had to be accounted for with a business reason that they would accept, with audits happening every few days.
Asking for a licence for something upfront was like pulling teeth.
Re: The worst thing about Jenkins is that it works (2019)
#108Interesting, the side snipe about Docker > One of the mostly-false promises of Docker, as it was sold to me by the true believers who introduced me to it, was that, if you do it right, you can run the same docker image, and therefore have basically the same environment in production, in CI, and on your local development machine. I literally have never worked anywhere that hasn't used the same container in dev/test/pr…
I think it's common (and important!) to build your "production" image once and deploy it into a dev/staging environment first. This means there are no re-builds between deploys to each environment.
However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments.
This is challenging because you probably don't want to include any build/test related packages in your production image (or layer) but you still want some level of confidence that your CI and Prod environments are the same.
I have often see builds pass automated testing but fail after deployment because our production Dockerfile/layer was missing packages or shared libraries that were present in the CI environment.
Re: The worst thing about Jenkins is that it works (2019)
#109Avoid Jenkins, and if you can, try https://www.jetbrains.com/teamcity "TeamCity Professional is free – even for commercial use – and has no limitations on features, number of users, or build time. It allows you to configure up to 100 builds and run up to 3 builds in parallel, which is more than enough for most projects"
The responses to this post are hilarious.
Re: The worst thing about Jenkins is that it works (2019)
#110All of the test runners have their issues. I've had as much problems with Jenkins as I've had with Github Runners and similar solutions. The best way out of this is to subdivide responsibilities: - 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 `. - Put all permis…
I totally agree. Make sure developers can run the same tasks locally as well.