[n4bz0r]

Cons:

  - DSL is harder to get into.
  - Hard to reproduce a setup unless builds are in DSL and Jenkins itself is in a fixed version container with everything stored in easily transferable bind volumes; config export/import isn't straightforward.
  - Builds tend to break in a really weird way when something (even external things like Gitea) updates.
  - I've had my setup broken once after updating Jenkins and not being able to update the plugins to match the newer Jenkins version.
  - Reliance on system packages instead of containerized build environment out of the box.
  - Heavier on resources than some of the alternatives.

Pros:

  - GUI is getting prettier lately for some reason.
  - Great extendability via plugins.
  - A known tool for many.
  - Can mostly be configured via GUI, including build jobs, which helps to get around things at first (but leads into the reproducibility trap later on).

Wouldn't say there is a lot of hate, but there are some pain points compared to managed Gitlab. Using managed Gitlab/Github is simply the easiest option.

Setting up your own Gitlab instance + Runners with rootless containers is not without quirks, too.

[maratc]

CASC plugin + seed jobs keep all your jobs/configurations in files and update them as needed, and k8s + Helm charts can keep the rest of config (plugins, script approvals, nodes, ...) in a manageable file-based state as well.

We have our main node in a state that we can move it anywhere in a couple of minutes with almost no downtime.

I'll add another point to "Pros": Jenkins is FOSS and it costs $0 per developer per month.

[bionsystem]

I have a previous experience with it. I agree with most points. Jobs can be downloaded as xml config and thus kept/versioned. But the rest is valid. I just don't want to manage gitlab, we already have it at corp level, just can't use it right now in preprod/prod and I need something which will be either throwaway or kept just for very specific tasks that shouldn't move much in the long run.

[n4bz0r]

For a throwaway, I don't think Jenkins will be much of a problem. Or any other tool for that matter. My only suggestion would be to still put some extra effort into building your own Jenkins container on top of the official one [0]. Add all the packages and plugins you might need to your image, so you can easily move and modify the installation, as well as simply see what all the dependencies are. Did a throwaway, non-containerized Jenkins installation once which ended up not being a throwaway. Couldn't move it into containers (or anywhere for that matter) without really digging in.

Haven't spent a lot of time with it myself, but if Jenkins isn't of much appeal, Drone [1] seems to be another popular (and lightweight) alternative.

[0] https://hub.docker.com/_/jenkins/

[1] https://www.drone.io