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

feat: add support for newer Windows SDKs #72

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

stevapple
Copy link
Contributor

@stevapple stevapple commented Sep 26, 2023

  • Supports Windows 11 SDK correctly;
  • Bumps the recommended version to Windows 10 SDK (10.0.19041);
  • Build dist/index.js;
  • Fixes typo.

This requires a SemVer minor release.

@codecov
Copy link

codecov bot commented Sep 26, 2023

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (5dfc518) 91.00% compared to head (1ceff75) 91.02%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #72      +/-   ##
==========================================
+ Coverage   91.00%   91.02%   +0.02%     
==========================================
  Files          30       30              
  Lines         900      903       +3     
  Branches      122      125       +3     
==========================================
+ Hits          819      822       +3     
  Misses         80       80              
  Partials        1        1              
Files Coverage Δ
src/installer/windows/index.ts 100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@stevapple
Copy link
Contributor Author

stevapple commented Sep 26, 2023

Unfortunately this path cannot be easily covered because GitHub runner is already Windows 11. Any hint?

The runner is Windows 10. Logic fixed.

@stevapple
Copy link
Contributor Author

@soumyamahunt Can you help to build and push dist/index.js so that end-to-end tests will use the updated version? It seems we need CI/CD for auto-building dist/index.js, or at least block E2E tests if it’s outdated.

@stevapple
Copy link
Contributor Author

And is it necessary & how to test the Windows SDK version logic?

@soumyamahunt
Copy link
Contributor

@soumyamahunt Can you help to build and push dist/index.js so that end-to-end tests will use the updated version?

You can run npm run all, this will generate dist/index.js.

It seems we need CI/CD for auto-building dist/index.js, or at least block E2E tests if it’s outdated.

yes for E2E test generated dist/index.js needs to be present in the branch, in future we can explore how to block if dist/index.js is not up-to-date.

@@ -11,17 +11,18 @@ import {Installation} from './installation'

export class WindowsToolchainInstaller extends VerifyingToolchainInstaller<WindowsToolchainSnapshot> {
private get vsRequirement() {
const reccommended = '10.0.17763'
const recommended = '10.0.19041'
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason for this change? Swift.org mentions 10.0.17763 is the lowest version supported and I would like the action have maximum compatibility.

Copy link
Contributor Author

@stevapple stevapple Sep 26, 2023

Choose a reason for hiding this comment

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

IIRC Windows 10 SDK (10.0.17763) is the default of Visual Studio 2017, which is long outdated and has compatibility issues with even VS 2019. Official Swift toolchains and SDKs are actually built against the newest setup, which means Windows 11 SDK (10.0.22621) for Swift 5.9.

I actually think Windows 11 SDK (10.0.22000) is better since it’s the default of Visual Studio 2022, but 19041 is new enough for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

The current logic uses the grater SDK version between current platform and 10.0.17763. So for Windows 11 version 10.0.22621, that version SDK will be chosen but if action is used on a Windows version lesser than 10.0.17763 then SDK of 10.0.17763 will be used.

This variable should be the lowest SDK version supported by Swift, not the latest one. Otherwise action will download the SDK unnecessarily, when it can reuse pre-installed SDK version.

const version = semver.gte(current, reccommended) ? current : reccommended
const winsdk = semver.patch(version)
const version = semver.gte(current, recommended) ? current : recommended
const winsdkMajor = semver.gte(version, '10.0.22000') ? semver.major(version) : 11
Copy link
Contributor

Choose a reason for hiding this comment

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

There could be better way of writing this that works for future release of Windows, i.e. Windows 12

Copy link
Contributor Author

@stevapple stevapple Sep 26, 2023

Choose a reason for hiding this comment

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

Basically no one knows what version logic MS will use for Windows 12🤷 Maybe they’re going to stick to 10 as major version….

@@ -66,6 +67,7 @@ export class WindowsToolchainInstaller extends VerifyingToolchainInstaller<Windo
}
core.debug(`Swift installed at "${swiftPath}"`)
const visualStudio = await VisualStudio.setup(this.vsRequirement)
// FIXME(stevapple): This is no longer required for Swift 5.9+
Copy link
Contributor

Choose a reason for hiding this comment

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

Are you planning to address this in current PR or in a future PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A future PR I think. Needs to figure out how to pass the version around, so it might be a big fix.

@stevapple
Copy link
Contributor Author

You can run npm run all, this will generate dist/index.js.

I cannot access my computer in ~2hrs and now I’m using an iPad🤦

yes for E2E test generated dist/index.js needs to be present in the branch, in future we can explore how to block if dist/index.js is not up-to-date.

Is it possible to run npm run all before E2E tests?

@soumyamahunt
Copy link
Contributor

Is it possible to run npm run all before E2E tests?

Integration tests use npm run build && npm run package to generate latest dist/index.js and then test.

The reason E2E works differently is because I wanted to add test for real-world usage. Unlike other GitHub actions, this action accesses files from swiftorg submodule, which varies based on action is cloned via git or downloaded.

If we go approach of generating dist/index.js, then it needs to be committed first for E2E test. I would rather enforce generation of dist/index.js before committing than complicating CI with auto-commit.

I cannot access my computer in ~2hrs and now I’m using an iPad🤦

No need to hurry, anyway action works fine on current windows runners.

And is it necessary & how to test the Windows SDK version logic?

For now you can add unit-tests with mocking the OS, there is no way to test properly until GitHub adds Windows 11 runner.

@stevapple
Copy link
Contributor Author

stevapple commented Sep 26, 2023

For now you can add unit-tests with mocking the OS, there is no way to test properly until GitHub adds Windows 11 runner.

It turns out that there's no reliable way to spyOn an ES module (os), see microsoft/TypeScript#43081.

Give up after literally trying all possible "safe" solutions.

@stevapple stevapple changed the title feat: add support for newer Visual Studio and Windows SDKs feat: add support for newer Windows SDKs Sep 26, 2023
@soumyamahunt
Copy link
Contributor

For now you can add unit-tests with mocking the OS, there is no way to test properly until GitHub adds Windows 11 runner.

It turns out that there's no reliable way to spyOn an ES module (os), see microsoft/TypeScript#43081.

Give up after literally trying all possible "safe" solutions.

Not sure what you have tried, there are already tests that mock os, please refer here for example.

Also please add windows-2019 to integration test, let's see if changes impact older versions:

os: [ubuntu-latest, macos-latest, windows-latest]

- os: windows-latest
swift: '5.3'
development: false

@stevapple
Copy link
Contributor Author

Not sure what you have tried, there are already tests that mock os, please refer here for example.

Mocking os in this way requires changing import * as os from "os" into import os from "os", which fundamentally changes os from all exported declarations to the only default one. However it worked, just slightly… uglier, I would say, than before.

@@ -249,6 +249,9 @@ jobs:
- os: windows-latest
swift: '5.3'
development: false
- os: windows-2019
Copy link
Contributor

Choose a reason for hiding this comment

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

please add windows-2019 with latest swift as well

const winsdkMajor = semver.lt(version, '10.0.22000')
? semver.major(version)
: 11
const winsdkMinor = semver.patch(version)
Copy link
Contributor

Choose a reason for hiding this comment

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

please extract the windows major version logic to a separate function, it will be easier to update in future.

@@ -11,17 +11,18 @@ import {Installation} from './installation'

export class WindowsToolchainInstaller extends VerifyingToolchainInstaller<WindowsToolchainSnapshot> {
private get vsRequirement() {
const reccommended = '10.0.17763'
const recommended = '10.0.19041'
Copy link
Contributor

Choose a reason for hiding this comment

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

The current logic uses the grater SDK version between current platform and 10.0.17763. So for Windows 11 version 10.0.22621, that version SDK will be chosen but if action is used on a Windows version lesser than 10.0.17763 then SDK of 10.0.17763 will be used.

This variable should be the lowest SDK version supported by Swift, not the latest one. Otherwise action will download the SDK unnecessarily, when it can reuse pre-installed SDK version.

@soumyamahunt
Copy link
Contributor

@stevapple can you rebase this PR, I am thinking of adding this as part of next release.

@stevapple
Copy link
Contributor Author

@stevapple can you rebase this PR, I am thinking of adding this as part of next release.

I may need some more time to look at previous discussions and try to handle these more elegantly. Thanks for getting this back to me😂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants