[JENKINS-56114] Correct behavior for Windows Server 2016 with Docker #3914
Conversation
- also adjust the symlink escape hatch
There was a problem hiding this comment.
If it works, it seems fine. I haven't been able to figure out any further issues this might cause.
It's such a specific environment that it's hard to make any specific, meaningful test. If manual and usage testing demonstrate it works for this environment, then it makes sense to include. I don't see any way it should disrupt other or more common environments.
|
Tested by Jeremy Kam (initial reporter) and it works fine! |
| return false; | ||
| } | ||
| } catch (NoSuchFileException e) { | ||
| // nonexistent file | ||
| // nonexistent file / Windows Server 2016 + MSFT docker |
There was a problem hiding this comment.
toRealPath will never work under Windows Server 2016 + MSFT Docker (perhaps other env) when the root is a mounted folder.
oleg-nenashev
added
the
ready-for-merge
There was a problem hiding this comment.
I do not see anything wrong here for JENKINS-56114, but I would highly recommend explicitly checking the platform before trying to apply a workaround. Otherwise relaxedToRealPath() may suppress real exceptions and cause unexpected behavior on other platforms.
oleg-nenashev
removed
the
ready-for-merge
|
@oleg-nenashev I added a condition on Windows for the specific code. |
daniel-beck
added
the
regression-fix
oleg-nenashev
added
the
ready-for-merge
|
Will merge it tomorrow if there is no negative feedback |
…3914) * [JENKINS-56114] Correct behavior for Windows Server 2016 with Docker - also adjust the symlink escape hatch * Correct missing space + retrigger build * Improve performance with a check on the logger level * Run the specific code only under Windows * Rename the method as it's used only for Windows (cherry picked from commit 5562b2f)
…enkinsci#3914) * [JENKINS-56114] Correct behavior for Windows Server 2016 with Docker - also adjust the symlink escape hatch * Correct missing space + retrigger build * Improve performance with a check on the logger level * Run the specific code only under Windows * Rename the method as it's used only for Windows
See JENKINS-56114.
Proposed changelog entries
The changelogs will be integrated by the core maintainers after the merge. See the changelog examples here: https://jenkins.io/changelog/ -->
Submitter checklist
* Use the
Internal:prefix if the change has no user-visible impact (API, test frameworks, etc.)