Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modified testScript.sh to allow for Win2012 to build JDK #942

Merged
merged 11 commits into from
Oct 30, 2019

Conversation

Willsparker
Copy link
Contributor

Fixes: #938

With this, all OS' currently supported in testScript.sh should be able to test a build.

@karianna karianna added the bug label Sep 19, 2019
ansible/pbTestScripts/buildJDKWin.sh Outdated Show resolved Hide resolved
ansible/pbTestScripts/buildJDKWin.sh Outdated Show resolved Hide resolved
ansible/pbTestScripts/buildJDKWin.sh Outdated Show resolved Hide resolved
ansible/pbTestScripts/buildJDKWin.sh Outdated Show resolved Hide resolved
@karianna karianna requested a review from sxa September 20, 2019 23:40
@Willsparker
Copy link
Contributor Author

Adding [WIP] tag to this PR, as I'm consistently having an error when trying to build a JDK on Windows, in that the build hangs up when attempting to move the workspace- though it also can't find a viable version of Java in a directory that definitely has one, so I'm going to investigate if that is due to an exporting an environment variable issue.

@Willsparker Willsparker changed the title Modified testScript.sh to allow for Win2012 to build JDK [WIP] Modified testScript.sh to allow for Win2012 to build JDK Sep 30, 2019
@karianna karianna added this to the September 2019 milestone Sep 30, 2019
@karianna
Copy link
Contributor

karianna commented Oct 4, 2019

@Willsparker merge conflicts...

@Willsparker
Copy link
Contributor Author

I've got to the point where the playbook installs the dependencies correctly, and a JDK can now be built on the Windows machine without additional user input- however, when attempting to do this through the script, one of these error messages occur:

fatal: mmap failed: Resource temporarily unavailable
error: https://github.com/adoptopenjdk/openjdk-jdk8u.git did not send all necessary objects

      0 [main] git 579 fhandler_disk_file::fixup_mmap_after_fork: requested 0x6FFF8FA0000 != 0x0 mem alloc base 0x0, state 0x10000, size 132998073876480, Win32 error 1455
   3442 [main] git 579 C:\cygwin64\usr\libexec\git-core\git.exe: *** fatal error in forked process - recreate_mmaps_after_fork_failed
   7928 [main] git 579 cygwin_exception::open_stackdumpfile: Dumping stack trace to git.exe.stackdump
      1 [main] git 578 dofork: child -1 - forked process 2112 died unexpectedly, retry 0, exit code 0x100, errno 11
error: cannot fork() for index-pack: Resource temporarily unavailable
fatal: fetch-pack: unable to fork off index-pack

Both occur after saving ./security/cacerts. Google specifies it's a cygwin error, it seems.

@Willsparker
Copy link
Contributor Author

Errors have been hit. When attempting to run the BuildJDKWin.sh script via vagrant powershell -c, when the version of git that is used is the one installed with the playbook (known as WinGit from now), an error will occur where it successfully clones a repository to /tmp/openjdk-build-dir/, however when attempting to cd into that repository, it doesn't exist- this is because WinGit has caused the repo to be at C:/tmp/openjdk-build-dir/
Source : git-for-windows/git#568
Keeping to Cygwin's inbuilt Git, causes an error in which cloning a repository with result in a well known fork(): Resource Temporarily Unavailable error or fatal: mmap failed: Resource temporarily unavailable error. This can supposedly be solved by rebasing the Cygwin packages, however I'm yet to make this work, let alone implement it into the script so automation of building the JDK can be achieved.

@Willsparker
Copy link
Contributor Author

The new direction I've taken this is to add a role into the playbook that will run the build script on the machine. The previous problems are therefore side-stepped as a different piece of software is communicating with the VM. This contains the tag build, and so can be skipped when a JDK doesn't need to be built on the VM.

@Willsparker Willsparker changed the title [WIP] Modified testScript.sh to allow for Win2012 to build JDK Modified testScript.sh to allow for Win2012 to build JDK Oct 18, 2019
Copy link
Contributor

@karianna karianna left a comment

Choose a reason for hiding this comment

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

nitpicks

ansible/pbTestScripts/buildJDKWin.sh Outdated Show resolved Hide resolved
ansible/pbTestScripts/testScript.sh Outdated Show resolved Hide resolved
ansible/pbTestScripts/testScript.sh Outdated Show resolved Hide resolved
ansible/playbooks/AdoptOpenJDK_Windows_Playbook/main.yml Outdated Show resolved Hide resolved
Copy link
Contributor

@karianna karianna left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@sxa sxa left a comment

Choose a reason for hiding this comment

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

Doing this as a playbook role is confusing and definitely not the right approach to take. Since I believe ansible and vagrant powershell are both communicating to the machine over WinRM there must be an alternate way to make this work.

@Willsparker
Copy link
Contributor Author

As per @sxa555 's request, I've removed the role from the playbooks. Instead, the testScript has instead been altered to used the command ansible to run the buildScript on the Windows VM, however just running the ad-hoc command, therefore it doesn't require addition to the playbook as a role.

@sxa sxa merged commit d85f303 into adoptium:master Oct 30, 2019
@Willsparker Willsparker deleted the winBuild branch February 13, 2020 08:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add build testing into the automated playbook testing
3 participants