Compliance Improvements with Git Hooks

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

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.

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

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.

SRE repo done: bcgov/bcregistry-sre#388

Correction to my earlier comment: bcgov/connect#38 was closed, not merged. Thoe pointed out connect already had a feature-design-01 branch covering this with a simpler approach (npx gitleaks-secret-scanner, no custom install script) that the team preferred over the checksum-verified-binary installer I'd built — closed #38 in favor of that. Note feature-design-01 itself isn't merged to connect's main yet either, so connect currently has no live secret scanning.

bcgov/bcregistry-sre — done, merged, and now solid:

#388 (SRE repo setup) merged 2026-08-26.
Validating it found a critical bug: the pre-commit hook failed on every commit before the gitleaks scan ever ran, due to a POSIX shell quirk in how .lefthookrc was sourced (confirmed on both Git Bash and dash, so not Windows-specific — anyone on main was blocked from committing anything).
Fixed in #391, merged 2026-08-26.
Re-validated thoroughly post-merge: fresh clone + npm install, full battery of real git commit tests (clean commits pass; real secrets, weak hardcoded passwords, and API-key-shaped tokens all correctly blocked; documented placeholders/throwaway CI creds correctly allowed).

Pilot PRs — open, ready for review, no reviewers assigned yet:

Single-app pattern: bcgov/bcregistry#278
Monorepo pattern (path-scoped root: lefthook commands): bcgov/ppr#2364

Both updated to match the simpler npx gitleaks-secret-scanner pattern (no custom install scripts) and CI-verified green.

Next steps: get #278 and #2364 reviewed/merged, then decide how to fold in sbc-pay (already has gitleaks via the Python pre-commit framework) and business-transparency-registry (has pre-commit for linting only, no secret scan) before rolling out to the remaining ~27 bcregistry-topic repos.

feat: add lefthook pre-commit hooks with gitleaks secret scanning (#278)

feat: add lefthook pre-commit hooks with gitleaks secret scanning

feat bcgov/entity#34619

Quick update — both pilots are merged now.

Single-app: feat: add lefthook pre-commit hooks with gitleaks secret scanning bcregistry#278 merged, then had to revert it, then re-landed as #281 (more below)
Monorepo: bcgov/ppr#2364, merged and working on main

Found a real bug that's worth flagging for the rest of the rollout: after #278 merged it broke CD on main (https://github.com/bcgov/bcregistry/actions/runs/34994839975). Turns out our CD build image doesn't have git installed, and lefthook's postinstall plus our own prepare script both need it, so the install just failed. Any repo whose build runs in a git-less image is going to hit this, not just us.

Fix (in #281, also applied to ppr's package.json):

"prepare": "lefthook install || exit 0"

plus lefthook: false in pnpm-workspace.yaml so its own postinstall doesn't do the same thing.

Probably worth baking this into the reference pattern now instead of everyone hitting it one by one.

(#281 also fixed a separate CD crash we had with better-sqlite3 on Node 24, not related to the hooks stuff, just fyi)

Tested both by actually running pnpm install + git commit with a fake secret in it and confirming it gets blocked, not just checking it looks right.

Still left to do:

figure out what to do with sbc-pay (already has gitleaks via pre-commit) and business-transparency-registry (pre-commit but no secret scan)
roll out to the other ~27 repos — namex is unblocked now too, solr migration's done, so it's back in scope (no push access there so it'll need a fork+PR like we did for ppr)
connect's own feature-design-01 branch — the one everyone's copying — still isn't merged to connect main, so connect itself has no secret scanning live right now. probably should fix that first since it's the reference

feat: add lefthook pre-commit hooks with gitleaks secret scanning

Found another problem with the lefthook prepare guard, fyi.

The command -v git >/dev/null 2>&1 && lefthook install || true line we added after the CD break doesn't work on Windows. pnpm runs scripts through cmd.exe there, and cmd doesn't know command -v or /dev/null, so it just errors, the || true swallows it, and install looks like it worked but no hook gets installed. So anyone on Windows had no secret scanning and wouldn't have known.

Caught it testing on my Windows machine, there was nothing in .git/hooks after install.

Changed it to:

"prepare": "git --version && lefthook install || exit 0"

Does the same thing (skips lefthook if there's no git, never fails the install) but works in both cmd and sh. Only side effect is it prints the git version or a "git not found" line.

Tested on Windows and in a node:24-alpine container (same kind of image as our CD), with and without git. Also tried committing a fake token on Windows and it got blocked. bcgov/bcregistry#284 is merged and the CD run after it went through fine, the log shows git: not found then prepare: Done, and the deploy to dev worked.

Same fix is on bcgov/ppr#2377 (approved, just needs someone to approve the Cloud Build check) and bcgov/namex#2019 (rebased, waiting on review).

I'll use this version of the line for the rest of the rollout. Also good reminder that we need to actually test on Windows for the "validated across platforms" part of the ticket, this only showed up because I happened to run it there.

feat: add gitleaks secret scanning to pre-commit config (#290)

feat: add lefthook pre-commit hook with gitleaks secret scanning

feat: add gitleaks secret scanning via pre-commit (#234)

feat: add lefthook pre-commit hook with gitleaks secret scanning (#898)

feat: add lefthook pre-commit hook with gitleaks secret scanning (#718)

feat: add lefthook pre-commit hook with gitleaks secret scanning (#834)

feat: add lefthook pre-commit hook with gitleaks secret scanning (#319)

feat: shared gitleaks rules for repo pre-commit hooks

feat: use shared gitleaks rules from bcregistry-sre

feat: use shared gitleaks rules from bcregistry-sre (#71)

feat: use shared gitleaks rules from bcregistry-sre

feat: add gitleaks secret scanning via pre-commit

feat: use shared gitleaks rules from bcregistry-sre

Navigation Menu

Repository navigation

Compliance Improvements with Git Hooks #34619

Scope

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

Rollout splits into two repo shapes

Bonus finding

Suggested next step

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Compliance Improvements with Git Hooks #34619

Description

Activity

panish16 commented on Aug 20, 2026

Scope

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

Rollout splits into two repo shapes

Bonus finding

Suggested next step

panish16 commented on Aug 20, 2026

panish16 commented on Aug 20, 2026

pwei1018 commented on Aug 25, 2026

panish16 commented on Aug 26, 2026

panish16 commented on Sep 23, 2026

panish16 commented on Sep 29, 2026

11 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions