fix: remove parameter sets so the script runs as an Azure Automation runbook - #22
Merged
Conversation
…runbook
Azure Automation rejects runbooks that use parameter sets ('Parameter sets
in runbooks are not supported in this release'), which broke the script's
primary target even though local tests passed. Declare -InputJson and
-ConfigFile as plain optional parameters and validate their mutual
exclusivity in the body (exactly one required). Bump to 3.1.1.
Fixes #21
Replace the two-parameter-set assertions with checks that no parameter sets are used and that exactly one config source is validated at runtime. 111 tests pass. Refs #21
Add a 3.1.1 section to CHANGELOG and trim RELEASE-NOTES to the latest version, documenting the Azure Automation parameter-set incompatibility fix. Refs #21
Live runbook testing showed Connect-PnPOnline was 'not recognized': in Azure Automation the '#Requires -Modules' directive does not import the module and command auto-loading is unreliable in the sandbox. Add an explicit Import-Module PnP.PowerShell (with a clear error if missing), which is harmless locally. Completes the runbook-compatibility fix. Refs #21
Live runbook testing surfaced that PnP.PowerShell 3.x requires PowerShell 7.4, so it fails to import on a 7.2 runbook. Document the runtime/module matrix in Getting Started (use a 7.4 Runtime Environment with PnP 3.x, or PnP 2.12.x on a 7.2 runbook) and note it in CHANGELOG/RELEASE-NOTES. Refs #21
Document the validated end-to-end runbook setup: system-assigned Managed Identity, a PowerShell 7.4 Runtime Environment with PnP.PowerShell 3.x, granting the MI Sites.FullControl.All (app-only) via Microsoft Graph, linking the runbook to the 7.4 runtime, and a note that only Legacy mode is reliably app-only. Highlight the breaking change vs 2.0.1 (7.2 runtime). Refs #21
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
1 participant
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.
Closes #21
Problem
Testing v3.1.0 live in an Azure Automation Runbook fails at start:
The
-ConfigFilesupport (from #7) introducedCmdletBinding(DefaultParameterSetName=...)with twoParameterSetNameparameters. Azure Automation runbooks do not support parameter sets, so the script — whose primary target is Azure Automation — could not run as a runbook, despite all local tests passing. Found by live runbook testing.Fix
-InputJsonand-ConfigFileare now plain optional parameters (noParameterSetName, noDefaultParameterSetName).Testing
Invoke-Pester-> 111 passed, 0 failed (parameter tests updated: assert no parameter sets + runtime source validation). Source-selection logic verified for all four cases (InputJson / ConfigFile / both / neither).Notes
Patch release. Behaviour is otherwise unchanged; both input methods still work.