Add windows container support, simplify binary generation

[car-roll]

The goal is to simplify the build (i.e. binary generation) process.
There are now two Dockerfiles to represent a build using linux or windows environment. Each Dockerfile has a corresponding build script to exercise their own Dockerfile properly.

The linux container is straightforward, using docker build --output (i.e. BuildKit) and a multistage Dockerfile, we can generate the needed binaries and output them directly to target/classes.

Unfortunately for windows, there is no BuildKit support, yet (see microsoft/Windows-Containers#34). In place, there is a traditional single stage Dockerfile that generates the binaries. We then use docker create to add a writeable container layer to extract the binaries to target/classes.

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your master 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

[car-roll]

Always some little issue. Looks like there is an issue for windows machines (possibly due to antivirus?) that causes an access denied error to the go.mod and go.sum files.
golang/go#36568

[jglick]

I am trying to figure out how all this fits together. I ran mvn package on this PR but it did not work:

$ jar tf target/lib-durable-task.jar
META-INF/MANIFEST.MF
META-INF/
META-INF/maven/
META-INF/maven/io.jenkins.plugins/
META-INF/maven/io.jenkins.plugins/lib-durable-task/
META-INF/maven/io.jenkins.plugins/lib-durable-task/pom.xml
META-INF/maven/io.jenkins.plugins/lib-durable-task/pom.properties

I suppose you forgot to package target/src/bin/? (Which is a really weird name BTW. src and target are mutually exclusive in Maven.)

[car-roll]

Windows build claims it passes, but it actually fails do to the same access denied error referenced here: #6 (comment)

golang 1.16 is supposed to fix this issue. maybe not the same problem?

[car-roll]

looks like the culprit was golang/go#31481
go mod tidy -modcacherw did not work, but running go get -modcacherw for every dependency did.

[jglick]

Still producing empty JARs.

[jglick]

To get syntax coloring, suggest moving this to e.g. src/docker/linux/Dockerfile. github-linguist/linguist#4566

[car-roll]

So I gave it a whirl and came across the issue of ADD/COPY requiring the source files to reside in the build context. Don't think this will work for this repo as I am adding the go source files into the image

[jglick]

Yeah, can be worked around by copying the desired Dockerfile along with other inputs into a temp directory and running docker build -t xxx target/xxx, but it is more hassle.

[jglick]

Suggested change

	docker build --build-arg VERSION=$VER -o $DEST -f Dockerfile.linux .
	export DOCKER_BUILDKIT=1
	docker build --build-arg VERSION=$VER -o $DEST -f Dockerfile.linux .

?

[car-roll]

ahh, was this why you were producing empty jars? Or is this a separate issue?

[car-roll]

Set docker buildkit flag in edf248c

[jglick]

https://repo.jenkins-ci.org/incrementals/io/jenkins/plugins/lib-durable-task/1.0-rc34.edf248cdcad1/lib-durable-task-1.0-rc34.edf248cdcad1.jar indeed seems to contain four binaries as expected.

[jglick]

https://repo.jenkins-ci.org/incrementals/io/jenkins/plugins/lib-durable-task/1.0-rc34.edf248cdcad1/lib-durable-task-1.0-rc34.edf248cdcad1.jar indeed seems to contain four binaries as expected.