Skip to content

feat: add support for newer Windows SDKs#72

Closed
stevapple wants to merge 10 commits into
SwiftyLab:mainfrom
stevapple:vs-sdk
Closed

feat: add support for newer Windows SDKs#72
stevapple wants to merge 10 commits into
SwiftyLab:mainfrom
stevapple:vs-sdk

Conversation

@stevapple

@stevapple stevapple commented Sep 26, 2023

Copy link
Copy Markdown
Contributor
  • 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

codecov Bot commented Sep 26, 2023

Copy link
Copy Markdown

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.02%. Comparing base (5dfc518) to head (1ceff75).
Report is 178 commits behind head on main.

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              

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@stevapple

stevapple commented Sep 26, 2023

Copy link
Copy Markdown
Contributor Author

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
Copy Markdown
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
Copy Markdown
Contributor Author

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

@soumyamahunt

Copy link
Copy Markdown
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.

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

Copy link
Copy Markdown
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.

@stevapple stevapple Sep 26, 2023

Copy link
Copy Markdown
Contributor Author

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
Copy Markdown
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.

Comment thread src/installer/windows/index.ts Outdated
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
Copy Markdown
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

@stevapple stevapple Sep 26, 2023

Copy link
Copy Markdown
Contributor Author

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….

}
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
Copy Markdown
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
Copy Markdown
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.

Comment thread src/installer/windows/index.ts Outdated
@stevapple

Copy link
Copy Markdown
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
Copy Markdown
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

stevapple commented Sep 26, 2023

Copy link
Copy Markdown
Contributor Author

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
Copy Markdown
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
Copy Markdown
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.

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

Copy link
Copy Markdown
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
Copy Markdown
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.

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

Copy link
Copy Markdown
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
Copy Markdown
Contributor

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

@stevapple

Copy link
Copy Markdown
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😂

@soumyamahunt

Copy link
Copy Markdown
Contributor

@stevapple I have taken your changes in 6efadfd, closing this PR

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