[github actions template] Pin vmImage to 2022 #100
Conversation
A change for windows-latest from Windows 2022 to Windows 2025 is imminent. Rather than winging it, we should pin to the working version, and test before we suffer the consequences.
WalkthroughUpdated CI runner images from windows-latest to windows-2022 across GitHub Actions workflows and Azure Pipelines. No changes to steps, logic, or control flow. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
.github/workflows/NanoFramework-GitHubBot.yml (2)
24-24: Consider centralizing the runner image or pre-testing Windows 2025.
- To prevent drift across many workflows, consider a reusable workflow input or a repo-level env in each workflow and reference it from jobs.
- Optionally, add a canary job/matrix leg on windows-2025 with continue-on-error to surface incompatibilities early.
Example (minimal change using a matrix on this workflow):
jobs: build-and-deploy: - runs-on: windows-2022 + strategy: + fail-fast: false + matrix: + os: [windows-2022] # add windows-2025 later + runs-on: ${{ matrix.os }}If you prefer a single place to tweak the image:
name: Build and deploy nanoFramework GitHubBot +env: + RUNNER_IMAGE: windows-2022 ... jobs: build-and-deploy: - runs-on: windows-2022 + runs-on: ${{ env.RUNNER_IMAGE }}
30-34: Heads-up: .NET 6 is out of support.Unrelated to this PR, but DOTNET_VERSION is set to 6.0.x. Plan an upgrade path to .NET 8 LTS to avoid toolchain removal on newer images.
.github/workflows/check-packages-updated.yml (1)
20-20: De-duplicate image selection across workflows.If multiple workflows must pin the same image, consider using a reusable workflow with an image input, or an env variable within each file to make future flips trivial.
Example:
jobs: check_nugets_using_latest_version: - runs-on: windows-2022 + runs-on: ${{ env.RUNNER_IMAGE }}And at top-level of the workflow:
env: RUNNER_IMAGE: windows-2022.github/workflows/update-dependencies.yml (1)
49-53: Optional: tighten secrets usage and preflight checks.Since this job creates PRs, adding an os-canary leg or a scheduled run on windows-2025 (continue-on-error) can validate future image compatibility without blocking routine runs.
.github/workflows/check-package-lock.yml (1)
21-21: Nit: make the missing-lock-file loop more explicit to avoid xor toggling.Not part of this PR, but
$lockFileMissing = $lockFileMissing -xor $truecan flip back to false if multiple files are missing. Use an OR to latch the failure.Proposed small refactor inside the existing loop:
- $lockFileMissing = $lockFileMissing -xor $true + $lockFileMissing = $trueazure-pipelines.yml (1)
31-31: Reduce duplication by introducing a pipeline variable for vmImage.Setting the image once avoids touching five job blocks in the next switch (e.g., to windows-2025).
Apply this pattern:
trigger: branches: include: [main, develop, "release-*" ] @@ -jobs: +variables: + vmImage: 'windows-2022' + +jobs: ############################## - job: Check_Build_Options pool: - vmImage: 'windows-2022' + vmImage: $(vmImage) @@ - job: Build_VersionCop pool: - vmImage: 'windows-2022' + vmImage: $(vmImage) @@ - job: Build_DependencyUpdater pool: - vmImage: 'windows-2022' + vmImage: $(vmImage) @@ - job: Build_NanoProfiler pool: - vmImage: 'windows-2022' + vmImage: $(vmImage) @@ - job: Report_Build_Failure pool: - vmImage: 'windows-2022' + vmImage: $(vmImage)Also applies to: 111-111, 230-230, 375-375, 424-424
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
.github/workflows/NanoFramework-GitHubBot.yml(1 hunks).github/workflows/check-package-lock.yml(1 hunks).github/workflows/check-packages-updated.yml(1 hunks).github/workflows/update-dependencies.yml(1 hunks)azure-pipelines.yml(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: nanoframework.nf-tools (Check_Build_Options)
🔇 Additional comments (9)
.github/workflows/NanoFramework-GitHubBot.yml (1)
24-24: Pinning to windows-2022 is appropriate to avoid surprises from windows-latest flip.LGTM. This stabilizes the environment ahead of the Windows 2025 switch.
.github/workflows/check-packages-updated.yml (1)
20-20: Runner pinned to windows-2022 — good call for stability.No functional changes; keeping CI deterministic before windows-latest rebase is sensible.
.github/workflows/update-dependencies.yml (1)
47-47: Pin to windows-2022 looks good.This job installs tooling and updates dependencies; pinning the image avoids toolchain changes mid-flight.
.github/workflows/check-package-lock.yml (1)
21-21: Pin to windows-2022 is fine here.No logic changes; behavior remains the same.
azure-pipelines.yml (5)
31-31: Pinned agent image (Check_Build_Options): good for predictability.Approving this change.
111-111: Pinned agent image (Build_VersionCop): good.Consistent with the rest of the pipeline.
230-230: Pinned agent image (Build_DependencyUpdater): good.No issues spotted.
375-375: Pinned agent image (Build_NanoProfiler): good.VSBuild will continue to use the VS 2022 toolset available on this image.
424-424: Pinned agent image (Report_Build_Failure): good.Keeps the reporting job aligned with the rest of the pipeline.
|
@josesimoes , any feedback on this since: |
Description
Pin vmImage used for CI jobs.
Motivation and Context
A change for windows-latest from Windows 2022 to Windows 2025 is imminent. Rather than winging it, we should pin to the working version, and test before we suffer the consequences.
Reasons:
How Has This Been Tested?
Screenshots
Types of changes
Checklist:
Summary by CodeRabbit