ci: add check-licenses workflow#353
Open
toiroakr wants to merge 8 commits into
Open
Conversation
Adds a Check Licenses workflow using the shared check-licenses composite action (tailor-platform/actions), covering the whole pnpm workspace including examples/ so license issues in example apps are caught too, not just packages/core. license-groups / additional-licenses / denied-licenses are sourced from LICENSE_GROUPS / ALLOWED_LICENSES / DENIED_LICENSES GitHub Variables, centrally managed instead of hardcoded in the workflow. Verified locally against the actual dependency tree (pnpm licenses list --json): examples/nextjs-app pulls in @img/sharp-libvips-* (LGPL- 3.0-or-later) transitively via next's built-in image optimization, used unmodified as a prebuilt binary — the standard case LGPL's dynamic-linking allowance covers. This repo's ALLOWED_LICENSES variable overrides the org default to include LGPL-3.0-or-later as an app-shell-specific exception. All other licenses in use are covered by the reciprocal/notice/unencumbered baseline plus the shared BlueOak-1.0.0/WTFPL/Unknown extras.
Moves the sharp/libvips LGPL-3.0-or-later exception from a repo-level ALLOWED_LICENSES override to package-exceptions declared inline here, via the check-licenses action's new package-exceptions input. Approves only the exact @img/sharp-libvips-* package+license pairs pulled in by examples/nextjs-app's use of next's image optimization, rather than allowing LGPL-3.0-or-later in general (which would silently approve any future LGPL dependency, unrelated to this one). One entry per platform variant since sharp ships a separate prebuilt binary per OS/arch — package-exceptions matches on exact package name, no globs. Declared directly in this workflow rather than through a shared GitHub Variable, since the exception is tied to this repo's specific dependency tree, not organization policy.
Switches from four flat <package-name>@<license> entries (one per
OS/arch sharp-libvips binary variant) to a single dependency-chain
exception, matching check-licenses' redesigned package-exceptions
input: {"LGPL-3.0-or-later": [["nextjs-app", "next"]]}.
Approves the route (examples/nextjs-app's use of next, which pulls in
sharp/libvips for image optimization) rather than the license or a
specific package name, so it covers every platform variant without
enumerating them, and won't silently approve an unrelated future
LGPL dependency elsewhere in the workspace.
Extracts the LGPL sharp/libvips exception from inline workflow YAML into .github/license-package-exceptions.json, easier to find and edit than digging into the workflow. A new "Load and validate package exceptions" step reads the file and rejects any chain that doesn't start with an example app (nextjs-app, vite-app): package-exceptions may excuse a license issue found in a non-published example, never in @tailor-platform/app-shell itself (the published package) — approving an exception rooted at the actual library would let an unreviewed license slip into what customers install.
actions/checkout@v4, actions/setup-node@v4, and tailor-platform/actions/check-licenses@v1 were still referenced by mutable tag, unlike every other action in this repo. Pinned all three to full commit SHAs with pinact (check-licenses to v1's current commit, v1.6.0), matching the org's SHA-pinning convention and now also passing tailor-platform/sdk's ghalint check (action_ref_should_be_full_length_commit_sha), which surfaced this.
Match the CHECK_LICENSES_* namespace now applied to the ALLOWED_LICENSES/ DENIED_LICENSES/LICENSE_GROUPS org variables upstream.
Edits to check-licenses.yaml itself (e.g. its inputs, action version) should re-run the check, not just pnpm-lock.yaml/exceptions-file changes.
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
1 participant
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.
Summary
check-licensescomposite action (tailor-platform/actions). app-shell had no license check before this.working-directory), includingexamples/, so license issues in example apps are caught too — not justpackages/core, the actually-published package.license-groups/additional-licenses/denied-licensesare sourced fromLICENSE_GROUPS/ALLOWED_LICENSES/DENIED_LICENSESGitHub Variables (organization-level, Terraform-managed) instead of being hardcoded in the workflow.LGPL-3.0-or-later exception
Verified locally against the actual dependency tree (
pnpm licenses list --json):examples/nextjs-apppulls in@img/sharp-libvips-*(LGPL-3.0-or-later) transitively via Next.js's built-in image optimization (next→sharp→@img/sharp-libvips-*). It's used unmodified as a prebuilt binary — the standard case LGPL's dynamic-linking allowance covers, so it doesn't extend copyleft obligations to this repo.Approved via the check-licenses action's
package-exceptionsinput, sourced from a new.github/license-package-exceptions.json(easier to find/edit than inline workflow YAML):{"LGPL-3.0-or-later": [["nextjs-app", "next"]]}. A "Load and validate package exceptions" workflow step loads this file and rejects any chain that doesn't start with an example app (nextjs-app,vite-app) — package-exceptions may excuse a license issue found in a non-published example, never in@tailor-platform/app-shellitself (the published package). This guards against an exception accidentally (or intentionally) whitewashing a license problem in the actual code customers install.The chain approves the route (nextjs-app's use of next) rather than one exact package name, so it covers every OS/arch prebuilt-binary variant of sharp/libvips without enumerating them, and doesn't silently bless every future LGPL dependency org-wide.
All other licenses in use are covered by the reciprocal/notice/unencumbered baseline plus the shared
BlueOak-1.0.0,WTFPL,Unknown,OFL-1.1extras (OFL-1.1covers the bundled Inter font inpackages/core).Dependencies
This requires the following to land first:
tailor-platform/actionsrelease (to advance thev1major tag to includecheck-licensesand itspackage-exceptionsinput).LICENSE_GROUPS/ALLOWED_LICENSES/DENIED_LICENSESvariables.Until both land,
tailor-platform/actions/check-licenses@v1won't resolve / the Variables will read empty.Verification
Verified locally: the "Load and validate package exceptions" step's JS logic against both the checked-in
.github/license-package-exceptions.json(passes) and a mutated version with a chain rooted at@tailor-platform/app-shell(correctly rejected). Ran the fullcheck-licenses.mjslogic against this repo's actual dependency tree with the final config to confirm the whole check passes end to end.