Skip to content

refactor(scripts): standardize entry point guard pattern #346

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
azurecloudkevin wants to merge 5 commits into from
Closed

refactor(scripts): standardize entry point guard pattern #346

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7f3a5b5
refactor(scripts): standardize entry point guard pattern
azurecloudkevin Jan 28, 2026
eb9fd3a
style(scripts): format table alignment in README
azurecloudkevin Feb 2, 2026
496228a
test(scripts): add P1-P2 coverage tests
azurecloudkevin Feb 2, 2026
eacd93b
test: Add extended coverage tests for scripts
azurecloudkevin Feb 2, 2026
dde5916
test(scripts): expand test coverage for extension and linting scripts
azurecloudkevin Feb 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions scripts/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,61 @@ When adding new scripts:
5. Document in relevant README files
6. Test locally before creating PR

## Script Entry Point Pattern

All PowerShell scripts designed for both direct invocation and dot-sourcing (for testing) follow this pattern:

### Pattern Structure

1. **Script Parameters**: CmdletBinding and param block at top
2. **Helper Functions**: Pure functions for individual operations
3. **Invoke-* Function**: Main orchestration function
4. **Guard Pattern**: Entry point that only executes on direct invocation

### Example

```powershell
[CmdletBinding()]
param([string]$InputPath)

function Get-Data { ... }

function Invoke-MyOperation {
param([string]$InputPath)
# Main orchestration logic
}

#region Main Execution
try {
if ($MyInvocation.InvocationName -ne '.') {
Invoke-MyOperation -InputPath $InputPath
exit 0
Comment on lines +105 to +106
Copy link

Copilot AI Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The README example exits with 0 unconditionally after calling Invoke-MyOperation, which hides failures and does not match the pattern used elsewhere in this PR (capture function return code, then exit $exitCode). Update the example to assign the orchestration function’s return value to $exitCode and exit with that value.

Suggested change
Invoke-MyOperation -InputPath $InputPath
exit 0
$exitCode = Invoke-MyOperation -InputPath $InputPath
exit $exitCode

Copilot uses AI. Check for mistakes.
}
}
catch {
Write-Error "Operation failed: $($_.Exception.Message)"
exit 1
}
#endregion
```

### Benefits

* **Testability**: Dot-source to access functions without executing main logic
* **Reusability**: Import functions into other scripts
* **Consistency**: Predictable behavior across all scripts

### Naming Convention

| Script Name | Invoke Function |
|------------------|-----------------------|
| `Generate-*.ps1` | `Invoke-*Generation` |
| `Test-*.ps1` | `Invoke-*Test` |
| `Package-*.ps1` | `Invoke-*Packaging` |
| `Prepare-*.ps1` | `Invoke-*Preparation` |
| `Update-*.ps1` | `Invoke-*Update` |
| `Validate-*.ps1` | `Test-*Validation` |

## Related Documentation

* [Linting Scripts Documentation](linting/README.md)
Expand Down
Loading