Git And CI/CD
GitHub and GitHub Actions serve two distinct purposes in the roadmap:
- S2 repository engineering CI (FR-012) checks Azure Data Lab Toolkit itself: package, PowerShell, Pester, schemas, docs, links, dependencies, secrets, vulnerabilities, and releases.
- S14 user-facing Git and CI/CD (FR-042 and FR-027) expresses validate-plan-approve-deploy-probe-report-teardown intent for users, with GitHub as the reference adapter and Azure Pipelines, GitLab CI/CD, Gitea Actions, and Forgejo Actions as additional adapters.
The general adapter segment is scheduled after Bicep and Terraform and before Fabric. That schedule is not a code dependency on either engine.
CI stages
Section titled “CI stages”| Stage | Required outcome |
|---|---|
| Validate | Parse PowerShell, validate YAML schemas and examples, check generated content |
| Test | Run unit, contract, fixture, failure-path, redaction, and report tests |
| Analyze | Run PowerShell, dependency, secret, IaC, and vulnerability checks |
| Build | Package the module and build docs without uncommitted generation |
| Plan | Produce deterministic plan and cost artifacts without Azure mutation |
| Compare | Run Azure-aware -WhatIf only in an approved environment |
| Deploy | Require protected-environment approval and scoped OIDC identity |
| Probe | Verify the target, data, tools, security posture, and expected outputs |
| Teardown | Preview, confirm, remove eligible resources, and publish cleanup proof |
Security and quality gates
Section titled “Security and quality gates”| Control | Planned use and boundary |
|---|---|
| Dependabot | Update supported dependency manifests and GitHub Actions; updates still require review and tests |
| Dependency review | Show dependency changes and known vulnerability information in pull requests |
| CodeQL | Analyze supported languages only; CodeQL does not support PowerShell |
| PSScriptAnalyzer | Static analysis for PowerShell style, compatibility, and selected defect patterns |
| Pester | Exercise PowerShell behavior, contracts, negative paths, and redaction |
| Checkov | Scan supported Bicep, Terraform, GitHub Actions, and related configuration when those files exist |
| Secret scanning | Detect committed credentials and block supported secret patterns |
| Trivy | Planned generic scan for repository/filesystem dependencies and container images |
Trivy is the selected generic vulnerability scanner, but it remains backlog until a pinned workflow, severity policy, ignore process, database-update policy, and retained report exist. None of these tools proves that a deployment is secure.
Cloud identity and approvals
Section titled “Cloud identity and approvals”Live workflows will use GitHub OIDC federation with least-privilege Azure roles. Trust policies must constrain repository, branch or tag, environment, and workflow context.
Protected environments will control deployment and teardown identities, required reviewers, and environment-specific configuration. Forked or untrusted pull requests will not receive Azure credentials or access to protected secrets.
CI, webhook, and other unattended mutation also requires encrypted remote run state, locking, monotonically increasing fencing tokens, idempotency keys, resumable evidence, and duplicate-trigger rejection. A workflow may resume an approved run; it cannot approve its own plan, secret handling, spend increase, sensitive data, adoption, or teardown.
Live test protections
Section titled “Live test protections”Live tests need explicit subscription and region allowlists, quota checks, constrained SKUs, unique ownership tags, concurrency limits, budgets, short TTLs, and cleanup that runs after failure. A final Azure query will record resources that remain.
Small SQL VM smoke tests can run after approval. Wider provider, engine, region, and version matrices belong on scheduled or release workflows. No workflow may delete a resource whose ownership is unknown.
Fabric CI/CD is a later, separate segment
Section titled “Fabric CI/CD is a later, separate segment”Fabric automation will follow the current Fabric Git integration provider and item matrix and Fabric CI/CD guidance. Full Fabric infrastructure-as-code parity remains exploratory.
Fabric workspace creation does not technically depend on Git. Fabric CI/CD does depend on Fabric items and on a Git adapter that Fabric actually supports. Completing GitLab, Gitea, or Forgejo adapters does not imply that Fabric accepts those services.
Gitea and Forgejo can also become self-hosted lab solution packs, but that adds storage, backup, identity, ingress, certificates, upgrades, scanning, secret store, and teardown responsibilities beyond a pipeline adapter.