-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8268860: Windows-Aarch64 build is failing in GitHub actions #4681
Conversation
👋 Welcome back ihse! A progress list of the required criteria for merging this PR into |
Hi Magnus, I think we need to understand more about why this stopped working before reenabling it. I also would like to know how this fixes things when according to the Github folk: actions/runner-images#3567 (comment) the issue is using VC instead of cygwin. If there is a misunderstanding about how the build works it would be good to clear that up and document it. Thanks, |
There were a bit of initial confusion in the actions bug you mention, but in the end that was also what supplied the solution. The quote about "VC instead of cygwin" is just confused and misleading; we are using VC (that is, Visual Studio) as well as Cygwin. When @dsame played around in his personal fork, he never changed any of these. But it piqued my interest when he said he got it building, so I had a closer look at what he actually did. There were some irrelevant changes, but the core fix was to remove the However, this is not a solution that we would like to have, since we want more control of what version is used to build. The price we pay for that, is to occasionally having to bump the version like this, when stuff starts to break. (We recently have to fix ubuntu builds when our selected compiler were removed from the apt sources.) So I changed this to explicitly set the version of msdev that worked. I don't think we will ever find out what changed with the GHA environment. We are never going to have that kind of control over it. So we will just have to go with the flow, and patch submit.yml whenever we ran across new snags. And the misunderstanding about how the build works resides purely in the Github action team. The documentation is clear enough, but I don't expect them to get any more knowledge about our building system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation and for updating the github issue!
It is still unsettling that we don't know what changed as no-one has responsibility for keeping this part working, and it will rely on concerned volunteers to monitor and update.
Thanks,
David
@magicus This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
Thanks for the review! I agree that the GHA situation is far from ideal. (But we've been through this discussion before...) |
/integrate |
Going to push as commit acc3d99.
Your commit was automatically rebased without conflicts. |
More as an FYI and something that might help investigate similar failures in future. Each run of the GitHub action job generates a log which is available for download publicly (and/or can be viewed raw in the browser). For example, I just picked a random PR in the current queue #4759 and clicked the "Details" link beside the "Pre-submit tests - Windows aarch64 - Build" under GitHub actions on that PR. Then click on the "Windows aarch64 (build debug)" link on that job run page. On the page that shows up, there's a visual log viewer of that job run. There's a settings icon, top right of that widget, which has an option which allows you to view the raw logs in the browser. Doing so will show the entire log of that run. One part of the log contains details about the virtual environment used for that run and it has some interesting/useful details like:
So the details about the virtual environment used for that run are listed in the log and additional a (version controlled) link is provided which has the full list of softwares that were installed on that VM:
This is a version controlled file and available in their github repo for public access as well as review. The commit history shows the exact version of which software changed over time. I don't know when the Windows-Aarch64 build started failing first, otherwise we could probably check the history on that file around that time to know what exactly caused this issue. |
GHA for Windows/aarch64 was disabled in JDK-8268861. The problem with GHA for windows/aarch64 was due to using Visual Studio 14.28. (Why this suddenly started failing is a mystery for another time. Perhaps GitHub, or Microsoft, changed something...)
Upgrading to 14.29 (which is the default on the GitHub actions machines) solves the problem.
This patch contains a revert of JDK-8268861, followed by an upgrade to 14.29.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4681/head:pull/4681
$ git checkout pull/4681
Update a local copy of the PR:
$ git checkout pull/4681
$ git pull https://git.openjdk.java.net/jdk pull/4681/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4681
View PR using the GUI difftool:
$ git pr show -t 4681
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4681.diff