ci: run the Windows unit and Pester suites on every pull request - #168
Open
tas50 wants to merge 1 commit into
Open
ci: run the Windows unit and Pester suites on every pull request#168tas50 wants to merge 1 commit into
tas50 wants to merge 1 commit into
Conversation
The shared lint-unit workflow only runs the RSpec suite on Ubuntu, and the Pester suite in spec/powershell never ran anywhere except a developer's laptop. This driver only ever runs on Windows, so neither gap was harmless. Adds two jobs: - windows-unit runs `rake test` on windows-latest against Ruby 3.1 and 3.4. File.join, Dir.exist? and the WOW64 architecture detection in powershell.rb all behave differently there, and none of it was covered. - pester runs spec/powershell/run_tests.ps1 on windows-latest, which exercises the 45 tests over support/hyperv.ps1 against the stub Hyper-V module. It needs no bundle, just Pester 5. Also records at the top of the workflow why there is no `kitchen test` job: Hyper-V needs nested virtualization, which GitHub-hosted runners do not offer, so end-to-end coverage stays a manual step documented in CONTRIBUTING.md. Removes support/ci/windows_ci.bat and support/ci/windows_integration.bat. Nothing referenced either one. windows_ci.bat duplicated what these jobs now do, and windows_integration.bat could not have worked: it called `kitchen verify windows` against a kitchen.yml this repo does not have, using %machine_user% and %machine_pass% that nothing sets. Signed-off-by: Tim Smith <tim@mondoo.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
CI for this driver had two holes that mattered more here than they would elsewhere, because this plugin only ever runs on Windows.
lint-unitworkflow runs RSpec on Ubuntu only. Nothing verified the driver on the one platform it actually ships to.spec/powershellholds 45 Pester tests covering the functions insupport/hyperv.ps1, complete with a stub Hyper-V module so they run anywhere. They have never run in CI — only on a developer's laptop viabundle exec rake pester.This adds two jobs:
windows-unit—bundle exec rake testonwindows-latest, Ruby 3.1 and 3.4.File.join,Dir.exist?and the WOW64 architecture detection inpowershell.rball behave differently on Windows, and none of that was exercised.pester— runsspec/powershell/run_tests.ps1onwindows-latest. It needs no bundle, just Pester 5, and uploads the NUnit results as an artifact.Why there is no
kitchen testjobI looked at adding real integration suites the way kitchen-docker has them, and it is not possible on GitHub-hosted runners: Hyper-V requires nested virtualization, which hosted runners do not provide, and the Hyper-V role cannot be enabled on them. Inventing a suite that cannot run would be worse than not having one, so instead the workflow now carries a comment saying exactly that, and points at the "Manual testing against Hyper-V" section of
CONTRIBUTING.md, which is where end-to-end verification actually lives.If we ever get a self-hosted Hyper-V runner, that is the point to add a
kitchen testjob.Dead code removed
support/ci/windows_ci.batandsupport/ci/windows_integration.batare both gone. Nothing in the repo referenced either file.windows_ci.batduplicated what the new jobs do, andwindows_integration.batcould not have worked at all — it ranbundle exec kitchen verify windowsagainst akitchen.ymlthis repo does not have, using%machine_user%and%machine_pass%that nothing sets.Verification