windocker: User ID mapping/permissions prevents removal of files in containers

[sxa]

          The current jobs are failing to remove some of the files after the build. Suspect they're being extracted via the host system and then deletion is attempted in the container which is failing:

18:29:42  Cleaning workspace non-hidden files: C:/workspace/openjdk-build/*
[Pipeline] sh
18:29:44  + rm -rf C:/workspace/openjdk-build/CONTRIBUTING.md C:/workspace/openjdk-build/FAQ.md C:/workspace/openjdk-build/LICENSE C:/workspace/openjdk-build/NOTICE C:/workspace/openjdk-build/README.md C:/workspace/openjdk-build/cyclonedx-lib C:/workspace/openjdk-build/docs C:/workspace/openjdk-build/pipelines C:/workspace/openjdk-build/tools C:/workspace/openjdk-build/workspace
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/CONTRIBUTING.md': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/FAQ.md': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/LICENSE': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/NOTICE': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/README.md': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/cyclonedx-lib': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/docs': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/pipelines': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/tools': Permission denied
[Pipeline] }

Originally posted by @sxa in #3713 (comment)

[sxa]

Noting also that the git clean -fdx operation at the start of the build occurs within the container and can't clean up in the extracted openjdk-build directory:

09:56:31  + git clean -fdx
09:56:31  warning: failed to remove cyclonedx-lib/: Permission denied

The c:\workspace\openjdk-build directory is being created in a way that is showing as being owned by Administrators according to cygwin's ls -l which is potentially the cause of this conflict. I have regenerated it manually on the shared file system within the container so it is now owned by ContainerUser and will run some tests to see if it still fails (At this point I'm assuming that the directory is not totally removed and recreated by the automation, which is a possibility)

[sxa]

This is definitely looking more promising based on a few runs of a build with a faulty configure-arg :-)

Unfortunately not for the full run :'( At the end of the build it hit the same problem and subsequent runs failed on the git clean -fdx (Possibly since there were things to clean up unlike the first test)
Note that removing just the cyclonedx-lib directory (from the host) prevents the failure.

[sxa]

context.cleanWs notFailBuild: true in openjdk_build_pipeline.groovy is executed on the host - latest branch will attempt to remove cyclonedx-lib in that section.