Skip to content

fix(hooks): run the pre-push check and warn when hooks are missing (#3493) - #3495

Merged
eleshar merged 14 commits into
developfrom
fix/husky-hooks-3493
Sep 26, 2026
Merged

eleshar merged 14 commits into
developfrom
fix/husky-hooks-3493

Conversation

@eleshar

@eleshar eleshar commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Bugfix Pull Request

Linked issues

Closes #3493

Context

  • Severity/Impact: Medium. Local pre-commit and pre-push checks, including the branch name check, did not run in most checkouts, with no warning. CI still gated merges.
  • Affected versions/environments: every local clone and worktree; worst after npm ci --ignore-scripts.

Reproduction

  • Steps: 1) npm ci --ignore-scripts in a fresh worktree. 2) git config core.hooksPath returns .husky/_. 3) ls .husky/_ reports "No such file or directory". 4) Commit or push: no hook runs.
  • Expected vs Actual: lint-staged and the branch name check should run; neither did.

Root Cause

  • lib/hooks/install.js copied the branch-name hook into .git/hooks. Git ignores that directory because core.hooksPath is .husky/_.
  • lib/hooks/.hook-version is committed, so on a fresh clone the installer decided the hook was already installed and skipped it.
  • .husky/_ is created only by npm run prepare, so --ignore-scripts installs have no hooks at all. The main clone was in this state too.
  • .husky/pre-push was removed in docs: Reports & Projects Restructuring Phase 4 #1989, but the docs still describe it.

Fix Summary

  • Adds .husky/pre-push, which runs lib/hooks/pre-push. Removes install.js, .hook-version and the postinstall script.
  • Adds scripts/check-git-hooks.mjs, run by npm run hooks:check and pretest. It warns when hooks are missing and prints the fix, npm run prepare. --strict exits 1. It is skipped in CI.
  • The pre-push hook claimed forced pushes bypass it, but Git never passes push flags to the hook. The message now points to --no-verify.
  • Docs: the pre-push hook validates branch names only; the full tests run in CI. An npm test pre-push hook would block every push until test: 7 failing suites / 5 failing tests on develop (2026-09-23 full-suite inventory) #3472 is fixed.

Verification

  • Tests added/updated to cover the bug: check-git-hooks Jest suite 5/5 pass; branch-name integration script 11/11 pass.
  • Manual verification steps: before npm run prepare the check warns (--strict exit 1); after it, the check passes. The commits in this PR went through the live pre-commit hook, and the pushes through the live pre-push hook.
  • Negative/edge cases checked: git hook run pre-push fails with exit 1 on bad_Name_x; the check skips in CI; unset core.hooksPath; a single missing hook.
  • /code-review: no findings. /security-review: PASS. Semgrep: 0 findings.

Risk & Rollback

  • Risk level: Low. Local hooks only; pretest only warns.
  • Rollback plan: revert this PR.

Changelog

Fixed

Summary by CodeRabbit

  • Bug Fixes
    • Restored branch-name validation before pushes. Invalid branch names are blocked locally, including force pushes; the remote branch check still applies if you bypass the local hook with git push --no-verify.
    • Added warnings when Git hooks are missing or inactive. Checks are skipped in CI.
  • Documentation
    • Clarified how to restore missing hooks and that the full test suite runs in CI rather than during a push.

…3493)

- lib/hooks/install.js copied the branch-name hook into .git/hooks, which
  Git ignores because core.hooksPath is .husky/_; the committed
  .hook-version also made it skip installing. Remove both and add
  .husky/pre-push, so the check runs through Husky.
- scripts/check-git-hooks.mjs (npm run hooks:check, and pretest) warns
  when core.hooksPath is missing, e.g. after npm ci --ignore-scripts.
- The pre-push hook claimed forced pushes bypass it; Git never passes push
  flags to the hook. Point to --no-verify instead.
- Docs: the pre-push hook validates branch names; CI runs the tests.
@github-actions

github-actions Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

📋 Changelog Quality Validation

Metric Count
✅ Passing 119
❌ Failing 10
🆕 New failures in this PR 0
📦 Pre-existing failures 10

Status

✅ Validation PASSED - No new failures introduced by this PR.
Note: 10 pre-existing failure(s) remain in the Unreleased section.

No action required.

@github-actions

Copy link
Copy Markdown
Contributor

PR Template Routing

Branch Type: fix
Scope: husky-hooks-3493
Template: pr_bug.md
Labels Applied: type:bug

This PR was automatically routed based on the branch naming strategy.

@coderabbitai

coderabbitai Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: lightspeedwp/.github/.coderabbit.yml

Review profile: CHILL

Plan: Advanced

Run ID: 7c82f67b-be33-40e1-9486-a5585a8bf1e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

The pre-push hook now runs branch-name validation. New scripts detect missing Husky hooks and warn when hooks are inactive. Package scripts, tests, the changelog, and the hook guide reflect these changes.

Changes

Husky hook checks

Layer / File(s) Summary
Pre-push hook and branch validation
.husky/pre-push, lib/hooks/pre-push, lib/__tests__/validate-branch-name.integration.sh, lib/hooks/install.js, lib/hooks/.hook-version
The pre-push hook invokes branch validation. Forced pushes are no longer exempt. The integration test checks the hook entry point. The previous installer and version marker are removed.
Missing-hook detection and script wiring
scripts/check-git-hooks.mjs, scripts/__tests__/check-git-hooks.cli.test.js, package.json
The new CLI detects missing or inactive hooks, warns outside CI, and exits with status 1 in strict mode. Package scripts expose the check. Tests cover missing hooks, installed hooks, and CI behavior.
Hook setup documentation
docs/HUSKY_PRECOMMITS.md, CHANGELOG.md
The guide and changelog describe pre-push branch validation, hook checks, and recovery commands.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Low

Merge Risk: 🟡 Moderate · up to d276c

Some developers can miss the warning when local hooks are inactive, and the guide incorrectly describes what runs before a push. Resolve the hook-detection gaps before merging; CI remains the authoritative test gate.

Security Architecture Review

Security architecture risk: 🔵 Low · up to d276c

The new pre-push hook restores a local branch-name check, but the new status check can say hooks are present when Git is using a different hook directory. This creates false assurance about local checks; no server-side bypass has been established.

Retained concerns

  • Low · security · inferred: An alternate configured hook directory with files bearing the expected names passes the new check even when Git does not invoke the repository’s Husky hooks.
Security review details

Security Blast Radius

  • inferred — The false-active result affects local checkouts using an alternate hook directory; the reviewed paths do not establish a server-side authorization or merge-control bypass.

Security Findings and Attack Paths

  • inferred — If core.hooksPath points to another directory containing files with the two expected names, findProblems reports no issue even though those files need not dispatch to this repository’s checks.

Trust Boundaries and Controls

  • observed — The status check trusts the local Git hook-path configuration and file existence. Even a detected problem blocks the command only when --strict is supplied.

Hardening Proposals

  • proposed — To make the status message an assurance of effective local checks, verify that Git’s effective hook path reaches the intended Husky shims and that the hooks can execute, rather than checking filenames alone.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 3 files. (5 skipped: 5 … Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main changes: restoring the pre-push check and warning when hooks are missing.
Linked Issues check ✅ Passed Issue #3493 requires a documented recovery path after installs that skip scripts and a warning when the configured hooks directory is missing. The PR documents npm run hooks:check and `npm run prepa…
Out of Scope Changes check ✅ Passed The changes stay within Issue #3493 and the PR objective. The .husky/pre-push restoration, removal of the obsolete installer and version file, package script changes, hook behavior correction, docum…
Full details: Docstring Coverage

Explanation

Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 3 files. (5 skipped: 5 unsupported.)

✨ Finishing Touches 💡 2
📝 Generate docstrings 💡
  • Commit to this branch
  • Create a new PR
⚔️ Resolve merge conflicts 💡
  • Resolve merge conflict in branch fix/husky-hooks-3493
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@eleshar

eleshar commented Sep 25, 2026

Copy link
Copy Markdown
Contributor Author

@coderabbitai full review

@eleshar

eleshar commented Sep 26, 2026

Copy link
Copy Markdown
Contributor Author

@Mergifyio update

@mergify

mergify Bot commented Sep 26, 2026

Copy link
Copy Markdown
Contributor

update

☑️ Nothing to do, the required conditions are not met

Details
  • #commits-behind > 0 [📌 update requirement]
  • -conflict [📌 update requirement]
  • -closed [📌 update requirement]
  • queue-position = -1 [📌 update requirement]

@eleshar

eleshar commented Sep 26, 2026

Copy link
Copy Markdown
Contributor Author

@Mergifyio refresh

@mergify

mergify Bot commented Sep 26, 2026

Copy link
Copy Markdown
Contributor

refresh

✅ Pull request refreshed

@eleshar

eleshar commented Sep 26, 2026

Copy link
Copy Markdown
Contributor Author

@Mergifyio update

@mergify

mergify Bot commented Sep 26, 2026

Copy link
Copy Markdown
Contributor

update

☑️ Nothing to do, the required conditions are not met

Details
  • #commits-behind > 0 [📌 update requirement]
  • -closed [📌 update requirement]
  • -conflict [📌 update requirement]
  • queue-position = -1 [📌 update requirement]

@eleshar

eleshar commented Sep 26, 2026

Copy link
Copy Markdown
Contributor Author

/agentic_review

@qodo-code-review

qodo-code-review Bot commented Sep 26, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Grey Divider


Action required

1. Valid release branches cannot be pushed ✗ Dismissed 🐞 Bug
Description
.husky/pre-push activates the library validator whose PARSE_PATTERN excludes dots, unlike the
canonical validator's semantic-version release pattern. When a developer pushes a permitted branch
such as release/v1.2.3, the local hook exits with status 1 even though repository policy and
remote validation accept it.
Code

.husky/pre-push[2]

+node lib/hooks/pre-push "$@"
Relevance

●●● Strong

Accepted branch-pattern alignment fixes show the team prioritizes consistency with canonical release
naming rules.

PR-#2551

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The active hook invokes the library validator, whose general parser permits only lowercase
alphanumerics and hyphens. Repository documentation identifies the CJS validator as authoritative
and explicitly permits dotted semantic-version release branches.

.husky/pre-push[1-2]
lib/hooks/pre-push[33-44]
lib/validate-branch-name.js[68-73]
scripts/validation/validate-branch-name.cjs[66-78]
docs/BRANCHING_STRATEGY.md[185-207]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly active pre-push hook rejects semantic-version release branches that the repository's canonical branch policy accepts.

## Fix Focus Areas
- lib/validate-branch-name.js[68-73]
- scripts/validation/validate-branch-name.cjs[66-78]
- lib/__tests__/validate-branch-name.test.js[1-394]

## Recommended Fix
Add the canonical release semantic-version pattern to the library validator before applying the standard scope-title parser. Cover accepted forms such as `release/v1.2.3`, `release/1.2.3`, and supported prerelease suffixes, while retaining rejection tests for malformed versions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. Developers are told pushes run tests ✓ Resolved 🐞 Bug
Description
docs/HUSKY_PRECOMMITS.md now says full tests run only in CI, but DEVELOPMENT.md still states
that every pre-push hook executes npm test. Developers following the general development guide
will expect a local test gate that the restored hook does not provide.
Code

docs/HUSKY_PRECOMMITS.md[100]

+If the branch name does not follow the naming strategy, the push is aborted. The full test suite runs in CI, not in this hook.
Relevance

●●● Strong

Recent accepted reviews consistently require documentation to match actual workflow behavior.

PR-#1613
PR-#3563

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The changed Husky guide accurately documents branch validation and CI-owned tests, while the
repository's main development guide still promises that pre-push invokes the complete test suite
through npm test.

docs/HUSKY_PRECOMMITS.md[91-111]
DEVELOPMENT.md[69-105]
.husky/pre-push[1-2]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The repository's two developer guides now give contradictory descriptions of the pre-push hook.

## Fix Focus Areas
- DEVELOPMENT.md[69-105]
- docs/HUSKY_PRECOMMITS.md[91-111]

## Recommended Fix
Update `DEVELOPMENT.md` to state that pre-push validates branch names and that the full test suite runs in CI. Replace its `npm test` hook example with the actual branch-validation command or a link to the detailed Husky guide.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


View medium (1)
3. The wrong branch is checked before push ✓ Resolved 🐞 Bug
Description
lib/hooks/pre-push validates git rev-parse --abbrev-ref HEAD without consuming the ref-update
records supplied to a pre-push hook on standard input. An explicit push of another local branch can
therefore bypass validation when the checked-out branch is valid, while an invalid checked-out
branch can block pushing or deleting an unrelated ref.
Code

.husky/pre-push[2]

+node lib/hooks/pre-push "$@"
Relevance

●● Moderate

Potential explicit-push bypass is substantive, but no closely matching historical precedent confirms
expected hook behavior.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The newly wired script derives one name exclusively from HEAD and validates only that value. Its
integration test similarly substitutes an invalid current HEAD and never supplies the ref-update
input used by real explicit or multi-ref pushes.

.husky/pre-push[1-2]
lib/hooks/pre-push[16-44]
lib/tests/validate-branch-name.integration.sh[37-56]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The activated pre-push hook checks only the checked-out branch, not the refs included in the push operation.

## Fix Focus Areas
- .husky/pre-push[1-2]
- lib/hooks/pre-push[16-44]
- lib/__tests__/validate-branch-name.integration.sh[37-56]

## Recommended Fix
Read all pre-push ref-update records from standard input and validate each destination branch under `refs/heads/` that is being created or updated. Permit deletion records, avoid checking unrelated `HEAD`, and add integration cases for another local branch, multiple refspecs, detached HEAD, and branch deletion.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context sources
✅ Compliance rules (platform): 30 rules
✅ Cross-repo context — repo relationships
Review mode: ⚖️ Balanced: This changes Git hook installation, package lifecycle scripts, pre-test behavior, and branch-validation execution across multiple paths, creating genuine but contained runtime and developer-workflow risk.

Grey Divider

Tip of the day
💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Comment thread .husky/pre-push
Comment thread .husky/pre-push
Comment thread docs/HUSKY_PRECOMMITS.md
Qodo found that the restored pre-push hook read the branch with
`git rev-parse --abbrev-ref HEAD`, which is not the branch being pushed. Git
feeds a pre-push hook one ref-update record per ref on stdin, so an explicit
`git push other-branch` escaped validation whenever the current branch was valid,
and an invalid current branch could block an unrelated push or a ref deletion.

The hook now parses the records and validates every refs/heads entry in them,
skipping deletions and non-branch refs such as tags, and reporting how many of
how many were rejected. With no records on stdin it falls back to HEAD, so the
documented `node lib/hooks/pre-push` invocation still works outside a push.

Also corrects DEVELOPMENT.md, which claimed the pre-push hook runs the full test
suite. It validates branch names; the full suite runs in CI, which
docs/HUSKY_PRECOMMITS.md already stated correctly.

Adds lib/hooks/__tests__/pre-push.test.js, because the hook had no behavioural
coverage: the existing check-git-hooks test only covers hook installation. Seven
cases pin the stdin contract, and reverting the hook to the HEAD-only logic fails
four of them.
The manual-invocation example still said the hook "validates the current branch
name". Since 5b20dfb it validates every branch in the ref-update records git
supplies, and only falls back to the checked-out branch when there are none.
@eleshar

eleshar commented Sep 26, 2026

Copy link
Copy Markdown
Contributor Author

Review disposition — Qodo's three findings

Recording here rather than in the threads, because Qodo auto-resolved them on the push and my reply only landed on
one of them. Two of the three were valid and are fixed; one I could not reproduce and believe is incorrect.

1. "Valid release branches cannot be pushed" — not reproduced, believe incorrect

The finding says .husky/pre-push activates a library validator whose PARSE_PATTERN excludes dots, "unlike the
canonical validator's semantic-version release pattern", so release/v1.2.3 is blocked locally while policy accepts it.

There is no second parser. lib/hooks/pre-push line 13 does:

import { validateBranchName, formatErrorMessage } from '../validate-branch-name.js';

so the hook and the canonical validator are the same code. Tested directly against validateBranchName:

Branch Result
feat/x-y VALID
release/v1-2-3 VALID
release/v1.2.3 INVALID

Dotted release branches are accepted nowhere in the repository today, by the hook or by CI — which is why
#3558 ("branch-validator — accept semver release branches") is open. So the hook is not more restrictive than
remote validation; the real gap is #3558, and closing it there fixes the hook for free, because the hook shares the
parser. I have not touched #3558.

If Qodo was comparing against a semver pattern it saw in #3558 or in the spec rather than in the validator, that
would explain the claim.

2. "Developers are told pushes run tests" — fixed

DEVELOPMENT.md said the pre-push hook "Runs the full test suite" and showed npm test, while
docs/HUSKY_PRECOMMITS.md correctly said the hook validates branch names and the suite runs in CI. DEVELOPMENT.md
now matches the hook and points at the husky document. CodeRabbit's earlier finding on this file — "Update all
remaining pre-push workflow descriptions" — is addressed by the same change.

3. "The wrong branch is checked before push" — fixed, 5b20dfb4b2

Correct, and the most serious of the three. The hook read git rev-parse --abbrev-ref HEAD, which is not the branch
being pushed. Git supplies one ref-update record per ref on stdin, so git push other-branch escaped validation when
the current branch was valid, and an invalid current branch could block an unrelated push or a ref deletion.

It now parses stdin and validates every refs/heads entry, skipping deletions and non-branch refs such as tags, and
reports how many of how many were rejected. With no records it falls back to HEAD, so the documented
node lib/hooks/pre-push invocation still works.

Verified against real records:

stdin Result
refs/heads/Invalid_Branch rejected, exit 1 — previously bypassed
refs/heads/fix/abc-def exit 0
(delete) … refs/heads/… skipped, exit 0
refs/tags/v1.0.0 skipped, exit 0
empty falls back to HEAD

Test coverage added

lib/hooks/__tests__/pre-push.test.js — seven cases, because the hook had no behavioural coverage: the existing
check-git-hooks test only covers hook installation. I confirmed the coverage is real by reverting the hook to the
HEAD-only logic, which fails four of the seven.

Full suite: 287 suites, 5666 passed, 0 failed (up from 285 — the new file).

Also brought current with develop

Merged origin/develop; the branch is now 0 behind and MERGEABLE. The conflict GitHub previously reported was in
CHANGELOG.md, which now union-merges via the .gitattributes change in #3581, so it resolved without intervention.
Both changelog entries survived.

@eleshar
eleshar merged commit 84f42f1 into develop Sep 26, 2026
25 checks passed
@eleshar
eleshar deleted the fix/husky-hooks-3493 branch September 26, 2026 12:04
@linear-code

linear-code Bot commented Sep 26, 2026

Copy link
Copy Markdown

GIT-2373

eleshar added a commit that referenced this pull request Sep 26, 2026
Qodo's local review caught a second completeness gap in the same area CodeRabbit
flagged. FR-008's exception, FR-009's bypass list and the shipped-gate
constraint all named only Dependabot and docs-bot, but changelog-unified.yml
skips the require-gate job outright when github.actor is imgbot[bot] -- a
job-level if: on line 30, not an in-script author check. So an image bot's pull
requests are exempt from the changelog requirement too.

All three now say so, and distinguish the job-level skip from the in-script
author checks, since they happen at different points.

Its other finding, on .github/reports/changelog-metrics/20260926.json, is a
generated artefact left in the worktree by a test run: the file is untracked and
the pull request diff contains no report files, so it is not part of this change.

Also merges origin/develop for #3495, which touches none of these files.
eleshar added a commit that referenced this pull request Sep 26, 2026
…3583)

* fix: correct a false claim about the shipped changelog gate

Spec 016 FR-009 asserted that the shipped gate exempts a pull request changing
only CHANGELOG.md, because its docs-only test accepts any file ending in .md and
CHANGELOG.md ends in .md. That claim is wrong, and it reached the specification
through my own review of #3500, where I read one line of the gate's require step
rather than its control flow.

The gate tests changed.includes("CHANGELOG.md") and returns run_validation=true
before the docs-only exemption is ever evaluated, so a changelog-only pull request
is validated. Verified three ways: the guard appears at character 4246 and the
docs-only test at 5368 in the workflow, so the guard is reached first; the full
require-gate suite passes 41 of 41; and it already contains
"runs validation when the root changelog changed", which asserts exactly this and
contradicts the claim, alongside "exempts a nested CHANGELOG.md under docs/ as
docs-only", which is the case the .md suffix really does cover.

No gate change is needed, so none is made. FR-009 now states the gate's actual
order of tests, notes that the ordering is what keeps FR-008 and FR-009
consistent rather than conflicting, distinguishes a root CHANGELOG.md from one
nested under docs/, and cites the tests that pin the behaviour. FR-008's
cross-reference to a non-existent conflict is removed, the constraint line states
the full shipped order, and the same correction is applied to
FEEDBACK_RESPONSE.md, which repeated the claim on develop.

* docs: qualify the root changelog check with the gate's author skips

CodeRabbit is right that FR-008 and the corrected FR-009 were incomplete. The
gate skips Dependabot and docs-bot authors before it inspects any file, so those
pull requests never reach the changed.includes("CHANGELOG.md") guard and are not
validated even when they modify the root CHANGELOG.md.

Verified against the workflow: the dependabot skip is at character 430, the
docs-bot skip at 931, and the CHANGELOG.md guard at 2304, so the author skips
unambiguously come first.

FR-008 now carries the exception and FR-009 states that the ordering means the
guard applies only to pull requests that reach the file inspection.

* docs: list the imgbot gate bypass in spec 016

Qodo's local review caught a second completeness gap in the same area CodeRabbit
flagged. FR-008's exception, FR-009's bypass list and the shipped-gate
constraint all named only Dependabot and docs-bot, but changelog-unified.yml
skips the require-gate job outright when github.actor is imgbot[bot] -- a
job-level if: on line 30, not an in-script author check. So an image bot's pull
requests are exempt from the changelog requirement too.

All three now say so, and distinguish the job-level skip from the in-script
author checks, since they happen at different points.

Its other finding, on .github/reports/changelog-metrics/20260926.json, is a
generated artefact left in the worktree by a test run: the file is untracked and
the pull request diff contains no report files, so it is not part of this change.

Also merges origin/develop for #3495, which touches none of these files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Husky pre-commit hooks silently skipped when installed with --ignore-scripts

1 participant