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

8268860: Windows-Aarch64 build is failing in GitHub actions #4681

Closed
wants to merge 2 commits into from

Conversation

magicus
Copy link
Member

@magicus magicus commented Jul 5, 2021

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

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8268860: Windows-Aarch64 build is failing in GitHub actions

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

@bridgekeeper
Copy link

bridgekeeper bot commented Jul 5, 2021

👋 Welcome back ihse! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label Jul 5, 2021
@openjdk
Copy link

openjdk bot commented Jul 5, 2021

@magicus The following label will be automatically applied to this pull request:

  • build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the build build-dev@openjdk.org label Jul 5, 2021
@mlbridge
Copy link

mlbridge bot commented Jul 5, 2021

Webrevs

@dholmes-ora
Copy link
Member

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,
David

@magicus
Copy link
Member Author

magicus commented Jul 5, 2021

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 --with-msvc-toolset-version argument. This forced configure to pick up the standard installed version of msdev, and that one was correctly configured to build.

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.

Copy link
Member

@dholmes-ora dholmes-ora left a 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

@openjdk
Copy link

openjdk bot commented Jul 5, 2021

@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:

8268860: Windows-Aarch64 build is failing in GitHub actions

Reviewed-by: dholmes

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 master branch:

  • fd4de1e: 8233020: (fs) UnixFileSystemProvider should use StaticProperty.userDir().

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jul 5, 2021
@magicus
Copy link
Member Author

magicus commented Jul 6, 2021

Thanks for the review!

I agree that the GHA situation is far from ideal. (But we've been through this discussion before...)

@magicus
Copy link
Member Author

magicus commented Jul 6, 2021

/integrate

@openjdk
Copy link

openjdk bot commented Jul 6, 2021

Going to push as commit acc3d99.
Since your change was applied there have been 5 commits pushed to the master branch:

  • a18a112: Merge
  • 5b8e1a2: 8266595: jdk/jfr/jcmd/TestJcmdDump.java with slowdebug bits fails with AttachNotSupportedException
  • e14801c: 8269668: [aarch64] java.library.path not including /usr/lib64
  • 97e0e9e: 8268775: Password is being converted to String in AccessibleJPasswordField
  • fd4de1e: 8233020: (fs) UnixFileSystemProvider should use StaticProperty.userDir().

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Jul 6, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jul 6, 2021
@openjdk
Copy link

openjdk bot commented Jul 6, 2021

@magicus Pushed as commit acc3d99.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@jaikiran
Copy link
Member

jaikiran commented Jul 13, 2021

It is still unsettling that we don't know what changed

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:

2021-07-12T20:41:25.6215958Z ##[group]Virtual Environment
2021-07-12T20:41:25.6216502Z Environment: windows-2019
2021-07-12T20:41:25.6216982Z Version: 20210628.1
2021-07-12T20:41:25.6217813Z Included Software: https://github.com/actions/virtual-environments/blob/win19/20210628.1/images/win/Windows2019-Readme.md
2021-07-12T20:41:25.6219152Z Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20210628.1
2021-07-12T20:41:25.6219863Z ##[endgroup]

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:

2021-07-12T20:41:25.6217813Z Included Software: https://github.com/actions/virtual-environments/blob/win19/20210628.1/images/win/Windows2019-Readme.md

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.

@magicus magicus deleted the fix-aarch64-gha branch October 7, 2021 13:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build build-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

3 participants