Depending on the CI results here, I'll be seeking advice from other sous-chefs maintainers on whether this pin, if mergeable at all, merits its own major version bump. My biggest fear is inadvertently downgrading a user's existing Jenkins install. Something Jenkins very much does not like.

A more involved solution would be doing some inspection of a currently installed Jenkins package and aborting if a downgrade would occur.

Since it's just an attribute change and it can be easily overridden I think this makes sense.

Quick look at a few of the integration failures it looks like there may need to be some work around the service management.

Quick look at a few of the integration failures it looks like there may need to be some work around the service management.

Yeah I haven't had a chance to dig into it yet, I switched gears today to handle this problem in my own open source cookbooks downstream of this one.

I think it may be the fact that I picked an LTS version and the integration tests are using the mainline / weekly repos. We may have to get a bit more sophisticated or switch the default to the LTS repos if the Jenkins project does not provide binaries for the weekly releases from that long ago. Arguably switching and pinning an LTS version is probably better but even the "LTS" release required for this cookbook is not currently supported.

One option is to deprecate RPM installations and just prefer .war based installations, which is more portable anyway, and I can confirm works well on RedHat with latest LTS releases.

tag me if you want this admin merged

Quick look at a few of the integration failures it looks like there may need to be some work around the service management.

This seems to be related to the CI system as I'm not able to replicate this on my system. I'm looking into this to see what we need to adjust.

@nuclearsandwich so unfortunately I think this will break more things than fix. We have two major issues currently with this cookbook that need to be addressed:

1. Needs support for the newer systemd packages
2. Converted to a resource based cookbook and remove attribute issues that we're having with Chef 18

I don't have enough time to tackle both of these above, so for now I'm going to focus on at least getting systemd working in a different PR but mark Chef 18 as incompatible currently. I may or may not try and resolve some of the Chef 18 issues if I need to make systemd work properly or actually go ahead and do both if it's the best option moving forward.

Un-mothballing this one.

so unfortunately I think this will break more things than fix.

Could you elaborate on what breakages there'd be. The cookbook is not functioning in its current state and there's a growing amount of bitrot to contend with (I've started on some with #808).

Here's what I was thinking as a path toward restoring this cookbook (and thus unblocking Jenkins upgrades in my own org). As I wrote up the below, I realized that I am also focusing on the stable rather than current configurations although the end-state should allow us to support both.

• Pin Jenkins back to before the systemd change, which also means that Java 8 is still supported.
• Address other bitrot to get CI working on main
• Get the cookbook working with Jenkins package-installed as a systemd unit instead of a sysvinit script.
• Move the pin forward to the last Jenkins stable version to support java 8 and java 11.
• Update this cookbook to support java11, and default to it. This may also require or recommend dropping some older platforms.
• Remove the version pin entirely allowing the cookbook to default to the latest stable or current version of Jenkins

I am not currently running Chef 18 anywhere so I think that marking it incompatible for now and redoing that work separately would be okay with me.

so for now I'm going to focus on at least getting systemd working in a different PR but mark Chef 18 as incompatible currently

Did you get underway with this work? I couldn't find any related PRs.
My approach to the work is motivated by needing/wanting to provide an upgrade path for my live infrastructure and also trying to change as things at once as possible. Launching right in to supporting the latest stable and current releases would require fixing both systemd and java8 vs java11 compatibility while tests are offline. And that's a huge scope to undertake all at once.

My persistent hope with this PR is that I'd be able to get at least smoke tests turning over again under the sysvinit scripts so I could trust that any failures when handling the systemd migration were definitely introduced by the migration efforts. But so many of the basic tests now fail on the target Jenkins version that I'm not really certain it makes sense to try.

In my local workspace, I'm moving Jenkins forward to 2.346.1, which is a systemd-based package but is the last one supporting java 8. I'll be going at it somewhat blind, but if I can get at least one set of smoke tests passing again that will be something.

Jenkins boots cleanly from the systemd unit but java and jenkins environment parameters from /etc/default/jenkins aren't respected. In the past I've converted a few /etc/default/* files to cleanly serve as systemd EnvironmentFile values but the more conventional thing to do at this stage is move that entire file's configuration to a systemd override. So I'll start there next.

@nuclearsandwich this now probably needs a rebase :(