feat: enable CI workflows to use NuGet WDK packages #236
Conversation
…getWDKContentRoot env variable
… tools/ for WDK tool root
crates/wdk-build/src/utils.rs
Outdated
| @@ -98,6 +98,19 @@ pub fn detect_wdk_content_root() -> Option<PathBuf> { | |||
| ); | |||
| } | |||
|
|
|||
| // If NugetWdkContentRoot is present in environment, use it | |||
| if let Ok(wdk_content_root) = env::var("NugetWdkContentRoot") { | |||
There was a problem hiding this comment.
I don't think we should be doing custom handling here for nuget since NugetWdkContentRoot doesn't exist normally for the Kit. How does building with nuget generally work in a non-rust environment?
There was a problem hiding this comment.
I understand. The C samples use the Build-SampleSet.ps1 script. Adding the NugetWdkContentRoot was one of the ways to point to the NuGet pkg root. I'm not fully aware of how msbuild works with NuGet pkgs and how SxS WDK installations work.
There was a problem hiding this comment.
I very much do not want to add new scaffolding to windows-drivers-rs when existing mechanisms exist. In order to make sure this doesn't diverge from the original kit, I think you need to find out how C/C++ WDK handles pointing to the WDKContentRoot when using the new nuget install methods. For eWDK, we check for the env vars that eWDK prompts set. For installed WDK, we look for the reg keys that the WDK installer sets. For nuget, we should use whatever mechanism DDX has for nuget for root discovery. @NateD-MSFT do you have insight/contacts for this?
There was a problem hiding this comment.
I'll spin up a thread with the WDK team to ask.
.github/workflows/build.yaml
Outdated
| @@ -20,6 +20,7 @@ jobs: | |||
| matrix: | |||
| wdk: | |||
| - Microsoft.WindowsWDK.10.0.22621 # NI WDK | |||
| - Microsoft.Windows.WDK # Latest WDK | |||
There was a problem hiding this comment.
Even with nuget, we want to be able to test specific versions of the kit
…d_length_path_prefix
…into port-pipeline
…1 script to install WDK version based on the matrix input, fix clippy issue
…_or issue in utils.rs
svasista-ms
changed the title
| WDF_DRIVER_CONFIG, | ||
| WDF_NO_HANDLE, | ||
| WDF_NO_OBJECT_ATTRIBUTES, | ||
| call_unsafe_wdf_function_binding, ntddk::DbgPrint, DRIVER_OBJECT, NTSTATUS, PCUNICODE_STRING, PDRIVER_OBJECT, ULONG, UNICODE_STRING, WCHAR, WDFDEVICE, WDFDEVICE_INIT, WDFDRIVER, WDF_DRIVER_CONFIG, WDF_NO_HANDLE, WDF_NO_OBJECT_ATTRIBUTES |
There was a problem hiding this comment.
Not a blocker, but I am curious how this reformat wasn't caught sooner by CI/other pipeline checkins.
There was a problem hiding this comment.
I think this change actually needs to be reverted? I suspect that whats going on is that:
- cargo fmt check is only run at repo root. AFAIU, it traverses files it sees based on cargo-metadata (ie. it only looks in the workspace)
- the mixed-package-kmdf-workspace is actually its own cargo workspace, so that cargo fmt has no idea it exists
There are some gaps in the top-level examples and tests folders where certain pipelines are not fully covering them. spent some time figuring out what gaps there are (mostly due to changes related to #186 ) and will be adding the rundown to github in a pr
Enables the CI pipeline to use NuGet WDK/SDK packages instead of WinGet WDK installation.
These changes allow the workflows to use multiple WDK versions in the matrix.
NOTE: The latest WDK version is installed as a NuGet package. Older versions of WDK (before v10.0.26100) still rely on WinGet. On a local computer eWDK environement can be used.
Closes #214 partially. NI WDK and LLVM still use WinGet at the moment.
Summary of changes,
Modified workflows to use the above script to install WDK build numbers >= 26100.
Added packages.config that contains WDK packages and dependencies to be downloaded.