Use docker-workflow 592.v1001d948426c, not 595.v60cec912059b_

[MarkEWaite]

Use docker-workflow 592.v1001d948426c, not 595.v60cec912059b_

The 595.v60cec912059b_ tests fail on the ci.jenkins.io agents that are used for BOM builds. The failure message is:

java.lang.IllegalArgumentException: No enum constant org.jenkinsci.plugins.docker.workflow.DockerTestUtil.DockerOsMode. CANNOT CONNECT TO THE DOCKER DAEMON AT UNIX:///VAR/RUN/DOCKER.SOCK. IS THE DOCKER DAEMON RUNNING?

A pull request has been proposed to resolve the failure by skipping those tests on machines that have the docker executable available but the user does not have permission to use docker. The pull request is:

• Use docker ps to detect absence of docker permissions docker-workflow-plugin#336

Testing done

No local testing done, since this configuration was passing previously.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[MarkEWaite]

I'm merging this because it improves the condition of the master branch. There are still a few failures that need to be investigated, but they seem like they might be related to the performance of the agent rather than anything specific to the code.

[dduportal]

Thanks @MarkEWaite . I'm still wondering why this behavior appeared with the AWS change: both the Azure and AWS ci.jenkins.io are running BOM as Kubernetes agents, using the exact same container image from our "all in one" Packer Images. The docker CLI was already present before the migration.

Looks like the docker ps test makes sense to cover all future cases (e.g. is there a client + server Docker or not) and makes the test setup stronger.

[MarkEWaite]

I'm still wondering why this behavior appeared with the AWS change

Good question. It appeared during the same time period as the Azure to AWS change but was unrelated to that change. The change happened in the following pull request:

• Revive test suite on Windows docker-workflow-plugin#331

That change was released five days ago in 595.v60cec912059b_.

[dduportal]

I'm still wondering why this behavior appeared with the AWS change

Good question. It appeared during the same time period as the Azure to AWS change but was unrelated to that change. The change happened in the following pull request:

* [Revive test suite on Windows docker-workflow-plugin#331](https://github.com/jenkinsci/docker-workflow-plugin/pull/331)

That change was released five days ago in 595.v60cec912059b_.

Thanks for checking and confirming! I was worried that we were having a complex unexpected case in AWS EKS. Make sense then!