Possible duplicate of #241?

Please merge and issue a new release ASAP

FYI passing builds produce an Incrementals link.

I am not a maintainer. I am not sure if this plugin even has one. My standing advice is to not use it; instead run docker commands explicitly from sh.

@car-roll , @dwnusbaum , @rsandell , can someone take a look at this? This fix is pretty urgent, and is definitely worth pushing an update out to the public repo so that Jenkins users can easily get the fix.

@roncemer What makes this urgent? #241 was opened in September. Did something change for all users recently? And who exactly is affected? Only users running Jenkins itself using Docker? For now, there is an incremental build of the plugin based on your PR here (click on the green checkmark next to your latest commit and then follow the link to the Incrementals check) which you (and anyone else) can run.

In general there is no one actively maintaining this plugin, especially the docker Groovy DSL. As Jesse mentioned, we recommend that you avoid using it and prefer sh('docker ...'). Recent updates are essentially all minor infrastructure-related changes or security fixes.

I think we are long past overdue updating this plugin to officially discourage direct use of the docker DSL and to indicate that the plugin will not be updated for compatibility with future Docker changes going forward in a timely manner, if at all, and that users should not use it in new Pipelines.

@dwnusbaum Thanks for the suggestions! I committed your suggested changes, rebuilt the plugin, and tested. It still works great.

I would add that compared to running docker commands in sh in a Jenkins pipeline, this plugin is super-convenient, because it handles all of the Jenkins-inside-Docker logic for you. Because of that, I really think it still has value. Without it, if you had a scenario where you wanted to run the same Jenkins pipeline in both Jenkins running under Docker and Jenkins running directly on metal or a virtual machine, each Jenkins pipeline would need to have logic to figure out how to mount the jenkins_home folder under the target Docker container to do the build. This plugin takes care of that for you, and turns all of that into a one-liner. I think it's a pretty slick plugin.

If you guys want me to take over maintaining it, I'd be happy to do that. I'm no stranger to that kind of thing. I'm just a little rusty with Java code (used to be a Java expert, but it's been 15 years since I used Java in earnest, and a lot of new language features have been added since then).

I recently took over this project, as it was abandoned: https://github.com/roncemer/spark-sql-kinesis and am approved by Sonotype to deploy Maven artifacts. With a little coaching, I could learn how to deploy a Jenkins plugin, and would be happy to take this one over and address any or all of the outstanding issues and pull requests. I would just need to have the permissions on this repo, or I could have GitHub unlink the link between my fork and the original, and you guys could mark the original as abandoned in favor of my repo. Let me know if that's something you're interested in doing.

Hi, I am the author of #241.
I don't see any urgency as well, nothing changed since January 2021 and there was not a big interest in that finding: https://issues.jenkins.io/browse/JENKINS-64608
A handful of people commented, but not much more.
I personally rely on this plugin as well, so since I proposed the PR I use my changes in production, works out fine.
I guess this plugin really is only required for small build systems, I predict that anyone with some realistic workload will be inside a kubernetes cluster or similar.
Whatever solution for the problem would be fine for me, but I assume no PR will be merged and this plugin dies eventually...

Ok, so it appears that no one wants to maintain this plugin except for me. I'll have GitHub unlink my fork from this repository, and release an independent version of this plugin with my fixes. The new official, and actually maintained, repository will be here: https://github.com/roncemer/docker-pipeline-plugin

Please do not fork Jenkins plugins to other orgs.

Discussions are under way about who could take responsibility for merging this and tracking any reported regressions. If you would like to offer to maintain this plugin going forward, please see https://www.jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/

I decided not to use this plugin, nor to take on maintaining it myself. Out of courtesy for people who might stumble upon this plugin and try to use it, as I did, please unpublish it so that it doesn't show up in the list of available plugins in Jenkins. I lost a lot of man-hours on this one. At this point, just wondering where I should send the bill for my wasted time.

Also, I don't want to join an exclusive country club just to get my fixes into an open source project.

As far as my PR goes, use it, don't use it, I don't care. But that forked repo in my GitHub account isn't going to live there indefinitely. So get while the getting is good...or don't.

I must add that the gross negligence in not properly and timely dealing with this and other PRs, from genuinely concerned users, is a black eye on the reputation of Jenkins and the team who are maintaining it. The "it's not urgent" excuse betrays a lackadaisical approach to managing this project. The time spent making lame excuses could have been spent merging the PR and releasing a new version, saving potentially many man-hours for people who stumble upon this plugin and end up trying to use it. Shameful.

We are deploying a gitlab+jenkins server in the company I work for. We are facing this same problem and I would like this or the other pull request to be merged so we can use jenkins with cgroup v2.

Try https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/docker-workflow/523.v69dde87b_2243/docker-workflow-523.v69dde87b_2243.hpi from #280?