Run containers with --init by default to avoid leaking zombie processes.

[Romain-Geissler-1A]

People running containers manually usually run with pid 1 being a $SHELL, in which case waiting for child termination is something implemented already as it's the core job of a $SHELL. However with this jenkins plugin the command run is usually "cat" on Linux, which doesn't wait at all for children. To have in jenkins a situation a bit like during interactive container experience, start containers with --init so zombie processes are correctly reaped.

Testing done

Your CI still works (and it was broken before, as I had to fix it in #313 that I included in this pull request to have a green build).

Submitter checklist

Edit tasklist title

Beta Give feedback Tasklist Submitter checklist, more options

• Rename
• Copy markdown
• Delete tasklist

Delete tasklist

Delete tasklist block?

Are you sure? All relationships in this tasklist will be removed.

Cancel Delete

1. Make sure you are opening from a **topic/feature/bugfix branch** (right side) and not your main branch!

   Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
2. Ensure that the pull request title represents the desired changelog entry

   Ensure that the pull request title represents the desired changelog entry
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
3. Please describe what you did

   Please describe what you did
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
4. Link to relevant issues in GitHub or Jira

   Link to relevant issues in GitHub or Jira
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
5. Link to relevant pull requests, esp. upstream and downstream changes

   Link to relevant pull requests, esp. upstream and downstream changes
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
6. Ensure you have provided tests - that demonstrates feature works or fixes the issue

   Ensure you have provided tests - that demonstrates feature works or fixes the issue
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove

Add item to Submitter checklist

[Romain-Geissler-1A]

@MarkEWaite @jglick Now that you have merged the pre-requisite pull request, what do you think about the principle of that one (which actually was my reason for trying to fix the unit tests in the first pull requests) ;)

[jglick]

I have no opinion and prefer not to merge any behavioral changes to this plugin ever again unless required for test suites to continue passing. Its use should be avoided. Someone else who purports to maintain the plugin is free to review and merge.

[MarkEWaite]

@Romain-Geissler-1A I'm not a maintainer of this plugin. I think that the other people who are listed as plugin maintainers are the ones that would need to decide if they are willing to support this change and continue to maintain this change after it is released.

[Romain-Geissler-1A]

Well @jglick made it clear that there is no future for this plugin but to just make it build and "work" as is, without change. Not sure what's the strategy of cloudbees to be honest, and it happens that @jglick replied just one day after we had a visite from some cloudbees representative in my company, so we couldn't ask specifically about what will happen with this plugin. Maybe I will raise this pull request via our contact there then, because I honestly fail to see how a docker plugin used by quite some instance entered such a frozen state, and how such a rather innocent pull request can affect stability of the plugin.