feat(lib-version): let a repository declare it has no Lerian dependency - #837
Merged
Merged
Conversation
The zero-dependency verdict assumes the caller is a service, where depending on at least one Lerian library is a company-standards rule. It is a false positive for a repository that legitimately has none: a library whose public API is standard-library only, a template, a generator. Those had one way out — run_lib_version_check: false on the umbrella — which also switched off the outdated-version guard the check exists for, and switched it off permanently, including after the repository grows its first Lerian dependency. Adds require_lerian_libs (composite: require-lerian-libs), default true, so nothing changes for anyone who does not set it. When false, "no Lerian libraries" is reported as a warning and the check exits clean instead of failing. Deliberately narrow, matching outdated_non_blocking: it softens only that one verdict. A missing or unreadable go.mod, an outdated dependency and every infrastructure error keep failing, so a repository that opts out cannot turn a broken pipeline into a pass. Found on lib-boilerplate, the Go library template: its example depends on the standard library only, so the umbrella failed with "No github.com/LerianStudio/* dependencies in go.mod" and the template had to disable the whole check.
Contributor
🛡️ CodeQL Analysis ResultsLanguages analyzed: ✅ No security issues found. 🔍 View full scan logs | 🛡️ Security tab |
lerian-studio
added
documentation
Contributor
🔍 Lint Analysis
|
Contributor
🔍 PR Validation Summary✅ PR Mergeable — no blocking failures
|
This comment has been minimized.
This comment has been minimized.
lerian-studio
added
the
review-ready
This comment has been minimized.
This comment has been minimized.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: LerianStudio/github-actions-shared-workflows/.coderabbit.yml Review profile: ASSERTIVE Plan: Essentials Run ID: 📒 Files selected for processing (4)
Limit details: You’ve used the included review currently available. Your 97 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. WalkthroughThe library version check adds a setting that controls whether no direct Lerian dependencies cause failure. The setting defaults to ChangesLerian dependency requirement
Estimated code review effort: 2 (Simple) | ~10 minutes Change: Feature Suggested reviewers: Merge Risk: 🔵 Low · up to The opt-out may not work when testing a branch-channel workflow before the matching action is released at 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation 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 10 functions across 1 files. (3 skipped: 3 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Usage-based review receipt
Note This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…e opt-out The `Lerian Lib Version Advisory Tests` check was failing on this branch. The new REQUIRE_LERIAN_LIBS expansion runs under `set -euo pipefail`, and the test harness did not define it, so the script aborted at the first expansion and every verdict test read as a pass of the wrong kind. The harness now mirrors the action's declared default, which is what it does for every other input. The opt-out was `!= "true"`, so any unrecognised value waived the rule — `require-lerian-libs: tru` from a direct composite caller silently turned a compliance check off. Only the literal "false" opts out now, and a value that is neither emits a warning, so the typo is visible instead of enforcing a rule the caller believed it had disabled. The reusable workflow coerces a boolean and can only ever send "true" or "false", so this only affects direct callers. Seven tests cover the input, including the typo and empty-value paths and the three verdicts the exception must not widen to. Also corrected an overstated guarantee, in all four places it was written: the new text claimed every infrastructure error keeps failing, but an unresolvable releases API has always reported⚠️ Unknown and passed. The failure-modes table additionally still carried an unqualified "App has no Lerian libs → Fail" row that the three new rows below it contradicted, plus two claims that a go.mod with no Lerian libraries always fails, which is now `require_lerian_libs`'s call rather than `outdated_non_blocking`'s.
The previous fixture spelled the invalid value "tru", which the Spelling Check job flagged — correctly, since it cannot tell a deliberate fixture from a real misspelling. Replaced with two values that are likelier to reach the action for real: "FALSE", where only the case is wrong, and a bare "no", which YAML 1.1 reads as a boolean but which arrives at an action input spelled as written. Better coverage than the invented typo it replaces.
Contributor
|
@coderabbitai review |
✅ Action performedReview finished.
|
github-actions
Bot
deleted the
feat/lib-version-check-allow-no-lerian-deps
branch
September 24, 2026 19:57
bedatty
added a commit
that referenced
this pull request
Sep 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
lerian-lib-versionfails a repository whosego.moddeclares nogithub.com/LerianStudio/*dependency:That is the right rule for a service. It is a false positive for a repository that legitimately has none — a library whose public API is standard-library only, a template, a generator.
Today such a repository has exactly one way out:
run_lib_version_check: falseon the Go umbrella. That does not just skip the zero-dependency verdict, it switches off the outdated-version guard the check exists for — and switches it off permanently, including after the repository grows its first Lerian dependency, which is precisely when the guard starts being useful.This adds
require_lerian_libs(composite inputrequire-lerian-libs), defaulttrue, so nothing changes for any current caller. Set tofalse, the absence is reported as a warning and the check exits clean.Deliberately narrow, matching the wording already in the file for
outdated_non_blocking: it softens only that verdict. A missing or unreadablego.mod, an outdated dependency and every infrastructure error keep failing, so a repository that opts out cannot turn a broken pipeline into a pass.On the default. I kept it at
truerather than inverting it. Flipping it would silently drop the standards gate for every Go service on the channel, and that is a policy call for this repo's owners, not a side effect of a bug fix. If you would rather havefalseas the default, it is a one-line change on top of this PR and I am happy to make it.Where it came from
lib-boilerplate, the template new Lerian Go libraries are created from (LerianStudio/lib-boilerplate#13). Its placeholder API depends on the standard library only — on purpose, since the template must compile before anyone writes real code — so the umbrella failed on it and the template had to disable the whole check. With this input, the template (and every library generated from it) passeslib_version_require_lerian_libs: falseand keeps the version guard live for the day it takes its first Lerian dependency.Changes
src/validate/lerian-lib-version/action.ymlrequire-lerian-libsinput (default"true"); the zero-dependency branch reports a warning and exits 0 when it is nottrue. The failing branch's report now names the input as the supported way out..github/workflows/lerian-lib-version-check.ymlrequire_lerian_libsinput (boolean, defaulttrue), forwarded to the composite; header comment updated..github/workflows/go-pr-validation.ymllib_version_require_lerian_libsinput (boolean, defaulttrue), forwarded to the check.docs/lerian-lib-version-check.md,docs/go-pr-validation.mdTesting
actionlinton both workflow files — clean.true/true/"true"(no behavior change without opting in).checkscript extracted and run throughbash -nandshellcheck -S error— clean.go.modwith no Lerian requires:REQUIRE_LERIAN_LIBS=true→::error+ exit 1 (today's behavior, unchanged);REQUIRE_LERIAN_LIBS=false→::warning+ exit 0.I did not run the workflow end-to-end from a caller — that needs a branch pin from a test repo, which I can do if you want it exercised before merge.
Breaking Changes
None. Every input defaults to the current behavior.