Compliance Improvements with Git Hooks

[pwei1018]

Summary

Implement the Git Hooks RFC to standardize repository compliance controls, improve code quality, and ensure required validation checks are consistently enforced before code is committed or pushed. This initiative will align development practices across teams and reduce the risk of non-compliant changes entering shared repositories. The RFC is documented in the BC Gov Connect discussion.

Description

Implement the Git Hooks RFC and associated compliance controls across applicable repositories.

The objective is to establish a consistent developer workflow that automatically validates code quality, security, and repository standards before changes are committed or pushed. This work should align with emerging BC Government developer guardrail practices that emphasize enforcement of repository standards and validation checks through local automation.

Business Value

• Improves compliance with organizational development standards.
• Reduces non-compliant code entering shared repositories.
• Improves code quality and consistency across teams.
• Provides earlier feedback to developers, reducing rework and CI/CD failures.
• Supports secure and reliable software delivery practices.
• Establishes a common developer experience across participating teams.

Acceptance Criteria

• Git Hooks RFC requirements have been reviewed and mapped to implementation tasks.
• Repositories within scope have standardized Git hooks configured. (https://github.com/topics/bcregistry)
• Required compliance checks execute successfully before commits and/or pushes.
• Developer onboarding documentation includes hook installation and usage instructions.
• Implementation has been validated across supported development platforms.
• CI/CD pipelines continue to function without regression.
• Product teams have been engaged and informed of workflow changes.
• Any approved exceptions, limitations, or accommodations are documented.
• Compliance improvements and adoption metrics are documented in the ticket.

Definition of Done

• Git hook implementation committed to source control.
• Standardized installation mechanism documented and available to development teams.
• Compliance checks execute successfully in local development environments.
• CI/CD pipeline validation completes successfully.
• Documentation updated to reflect the new workflow and developer responsibilities.
• Product teams notified of implementation and support resources.
• Compliance posture is improved through automated enforcement of repository standards.
• Lessons learned, risks, and future enhancement opportunities are documented.

Example
https://github.com/bcgov/connect
https://github.com/bcgov/connect/blob/feature-design-01/.gitleaks.toml

[panish16]

Per acceptance criteria item 1 ("Git Hooks RFC requirements reviewed and mapped to implementation tasks"), here's an audit of current state across all repos tagged with the bcregistry GitHub topic.

Scope

• 36 repos carry the bcregistry topic.
• 4 are archived and excluded: business-ar, bcrs-testing, ppr-deprecated, sbc-search.
• 32 active repos in scope.
• namex is on hold pending the Solr migration — excluding from active rollout until that unblocks.

Existing git-hook / secret-scanning tooling — only 2 of 32 have anything

Repo	What exists
sbc-pay	.pre-commit-config.yaml already runs gitleaks (via the Python pre-commit framework, not Lefthook)
business-transparency-registry	.pre-commit-config.yaml with linting only (black/flake8/pyupgrade) — no secret scanning

All other 30 repos have no lefthook.yml, .husky, pre-commit config, gitleaks config, or husky/lefthook/lint-staged deps in any package.json.

Rollout splits into two repo shapes

• 7 single-app repos (root package.json, JS/TS) — can adopt the RFC's example lefthook.yml close to as-is: business-filings-ui, business-create-ui, business-edit-ui, bcrs-shared-components, business-dashboard-ui, entity-selection-tool, bcregistry.
• ~23 polyrepo-style monorepos — mix Python APIs and Vue/TS UIs across sibling subfolders (e.g. entity → vue-project-stub, api-e2e; ppr → ppr-api, ppr-ui, mhr-api; registries-search → 5+ service subfolders). These need path-scoped lefthook configs rather than the flat glob pattern in the RFC example, since a bare *.py glob at repo root won't distinguish between subfolders.

Bonus finding

22 of the 32 repos already carry a COMPLIANCE.yaml at root — an existing BC Gov compliance-metadata convention. Worth extending/referencing for this initiative's own compliance tracking rather than introducing a separate mechanism.

Suggested next step

Build out the reference implementation in bcgov/connect (currently has lefthook.yml but no .gitleaks.toml) as the template, then pilot on one single-app repo and one monorepo before wider rollout.

[panish16]

Reference implementation ready for review: bcgov/connect#38. Once merged this becomes the template for the pilot rollout to the other bcregistry-topic repos.

[panish16]

Both pilot PRs are up, validating the two repo shapes identified in the audit:

• Single-app: feat: add lefthook pre-commit hooks with gitleaks secret scanning bcregistry#278
• Polyrepo-style monorepo (path-scoped lefthook config via root:): feat: add lefthook pre-commit hooks with gitleaks secret scanning ppr#2364

Both follow the reference implementation in bcgov/connect#38 (still in review). Once these are reviewed, they become the two templates for the remaining ~27 repo rollout.