Skip to content

Conversation

ThugPigeon653
Copy link

@ThugPigeon653 ThugPigeon653 commented Sep 17, 2023

Testing done

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

@ThugPigeon653
Copy link
Author

I fixed the absolute path error by enforcing the correct formatting for docker paths, in the WindowsDockerClient. This avoided changing any upstream path variables, so as to not interfere with other usages of the path variables.
Once that was fixed, it became clear that containers were not stopping correctly, making some unit tests fail. This was because the application was synchronously getting the 'stopped' state from the docker command to stop the container. Because it was not synchronously returning the containerID, this was failing (even though the command was correct). I rectified this by making the stop method wait for the container stop time to elapse, then inspect the container. This allowed containers to shut down as expected, and return an accurate status.
Finally WithContainerStep attempting to run 'cmd.exe' on an Ubuntu container, when the agent is Windows. Top fix this, I skipped the 'isunix' check, and set the command variable to 'cat'. The OS of the host running the agent has no bearing on which commands should be run inside the container.

Copy link
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a test that shows the problem. Is a test feasible, even if that test cannot be run in the ci.jenkins.io environment?

}

String command = launcher.isUnix() ? "cat" : "cmd.exe";
String command = "cat";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the motivation for this change. Can you provide more details?

Did you test with a Windows container on a Windows host? I would expect a Windows container on a Windows host to report that cat could not be found.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is attempting to solve an issue in one environment (a Windows agent with Docker Desktop installed and I suppose running Linux containers) while breaking the plugin in other environments (a Windows agent running Windows containers). Does not look safe as written.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Offhand it sounds like this bug might have multiple components—a need for an option to customize the sleep command (here), and some issue with cross-OS file path calculations.

stop(launchEnv, containerId, 1);
}
public void stop(@NonNull EnvVars launchEnv, @NonNull String containerId, @NonNull int stopTime) throws IOException, InterruptedException {
LaunchResult result = launch(launchEnv, false, "docker", "stop", String.format("--time=%s", stopTime), containerId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs the spotbugs warning resolved, either by checking the value of result or by not assigning to result.

@jglick
Copy link
Member

jglick commented Sep 18, 2023

https://issues.jenkins.io/browse/JENKINS-60473 FTR; if you are working on an issue, you can assign to yourself in Jira and mark it In Review.

@jglick
Copy link
Member

jglick commented Sep 18, 2023

Also please link to earlier attempts: #197, #234, #235.

Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This plugin has no effective test coverage on Windows so it is unclear what use cases you would be breaking by touching behavior like this. (And the patch seems to also affect behavior on Linux, in probably unwanted ways.)

My general advice with this plugin is to use it when it is convenient if it works out of the box; but at the first sign of trouble, ignore it and switch to running docker CLI commands directly, testing your proposed commands directly on an example agent until you find a script that works. Experience has proven that the range of ways people expect Docker to work in builds is too broad for a plugin to comprehensively and reliably handle, and the original idea behind this plugin was ill conceived.

}

String command = launcher.isUnix() ? "cat" : "cmd.exe";
String command = "cat";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is attempting to solve an issue in one environment (a Windows agent with Docker Desktop installed and I suppose running Linux containers) while breaking the plugin in other environments (a Windows agent running Windows containers). Does not look safe as written.

}
public void stop(@NonNull EnvVars launchEnv, @NonNull String containerId, @NonNull int stopTime) throws IOException, InterruptedException {
launch(launchEnv, false, "docker", "stop", String.format("--time=%s", stopTime), containerId);
Thread.sleep((long)stopTime*1100);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unclear what this sleep is for.

@ThugPigeon653
Copy link
Author

Hi @jglick and @MarkEWaite ,
Thanks for taking the time to check this out and respond. I have taken on board your suggestions, and do agree completely with what you have said.
I will be sure to familiarise myself more deeply with the plugin, and will keep in mind what Jesse has said about correct use of Jira, as well as links to earlier attempts. I apologise if I got ahead of myself a bit with this PR.

Thanks,
Lachie

@ThugPigeon653 ThugPigeon653 deleted the JENKINS-60473 branch September 18, 2023 23:24
@MarkEWaite
Copy link
Contributor

Thanks @ThugPigeon653 for your willingness to adopt the plugin and to be involved in Jenkins. Much appreciated!

@jglick
Copy link
Member

jglick commented Sep 19, 2023

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants