infra: CI/CD pipelines and shared workflow templates

[kristopherjturner]

Overview

Implement CI/CD automation pipelines for the toolkit itself — lint, validation, release, and the shared workflow templates that will be replicated to solution repos.

Scope

• GitHub Actions workflow: PSScriptAnalyzer + YAML lint on all toolkit files
• GitHub Actions workflow: unit tests for PowerShell and Python modules
• GitHub Actions workflow: Release Please for automated changelog and releases
• Shared workflow templates in pipelines/templates/ (designed for reuse in solution repos):
  • template-lint.yml — PSScriptAnalyzer / ruff / shellcheck
  • template-test.yml — Pester / pytest with coverage
  • template-release.yml — Release Please integration
• Release artifact: toolkit ZIP with versioned module exports

Acceptance Criteria

• Toolkit's own lint and test pipelines pass on every PR
• Shared templates documented with usage instructions for solution repos
• Release Please triggers release on merge to main
• Shared templates adopted by ≥2 solution repos (validated by standards replication feat: standards replication mechanism across all solution repos #11)

Dependencies

• Parent Epic: [Epic] Azure Local Toolkit Platform Automation Full Build-Out #9
• Standards replication: feat: standards replication mechanism across all solution repos #11
• IaC maturity tracking: Track IaC tool maturity status across all repos (Built / Tested / Released) #5

[kristopherjturner]

Related to #16 (TKT-6) — Research: Azure Deployment Stacks for ARM/Bicep Deployments. Implementation of this issue should account for deployment stack adoption across all repos.

[m13v]

Good scope for the CI/CD setup. Having built shared pipeline templates for our own multi-repo setup (desktop app + Rust backend + multiple tool repos), some lessons learned:

1. Shared workflow templates need versioning from day one. When solution repos reference templates, pin them to a tag (not branch). We learned this the hard way when a template change broke 3 downstream repos simultaneously. Use @v1.0.0 references and bump versions with semver.

2. Release Please works great but has one gotcha with monorepo-style setups: if your toolkit has multiple independently-versioned modules, you need separate Release Please configs per module. The single-config approach leads to version bumps for unchanged modules.

3. For the lint workflow template: Make the tool versions configurable as inputs. Different solution repos may need different PSScriptAnalyzer or ruff versions based on their Python/PowerShell version constraints. We use a tool-versions input that defaults to "latest" but can be pinned.

4. Test workflow with coverage: Set a coverage threshold that blocks PRs but start low (60-70%) and ratchet it up. Starting at 80%+ on existing codebases creates a wall of "fix coverage" PRs before anyone can do real work.

5. Adoption validation (your last acceptance criterion): The best way to ensure templates are adopted is to make the toolkit's own CI use the same templates. If the toolkit dogfoods its own templates, you catch usability issues before they hit solution repos.

We use Codemagic for our macOS builds which has a similar shared pipeline concept.

[m13v]

For reference, here is our Codemagic CI/CD config that handles the full release pipeline (build, sign, notarize, publish, auto-update): https://github.com/m13v/fazm/blob/main/codemagic.yaml

And our launchd-based scheduling configs for automated jobs: https://github.com/m13v/social-autoposter/tree/main/launchd/

[kristopherjturner]

Tracked in Azure DevOps: https://dev.azure.com/hybridcloudsolutions/Azure%20Local%20Toolkit/_workitems/edit/200