CI/CD and Release Pipeline
Relevant Source Files
This section provides a high-level overview of the automated workflows that govern the PALEE codebase. The project utilizes GitHub Actions to enforce code quality, manage repository organization, ensure security invariants, and orchestrate multi-platform releases to the NPM registry.
Pipeline Architecture
The automation strategy is divided into three primary phases: Continuous Integration (quality and correctness), Security & Maintenance (auditing and labeling), and Continuous Delivery (versioning and distribution).
Workflow Orchestration
The following diagram illustrates the relationship between repository events and the resulting GitHub Action workflows.
Workflow Event Mapping
Sources:
- .github/workflows/ci.yml#3-10
- .github/workflows/release.yml#3-7
- .github/workflows/security.yml#3-13
- .github/workflows/pr-labeler.yml#3-5
Continuous Integration (CI)
The CI pipeline is designed to be fast and comprehensive, running on every Pull Request and push to the main branch. It utilizes a test matrix to ensure compatibility across Node.js versions (22.x, 24.x) and Operating Systems (Ubuntu, Windows, macOS).
Key responsibilities include:
- Static Analysis: Execution of
npm run checkwhich combines ESLint for linting andtscfor strict type checking .github/workflows/ci.yml#33-34 - Testing & Coverage: Running the full invariant test suite with
c8for coverage reporting .github/workflows/ci.yml#65-66 - Smoke Installation: Building a production tarball and performing a global
npm installto verify the CLI binary (palee) functions correctly in a clean environment .github/workflows/ci.yml#75-131
For detailed information on the CI configuration and coverage thresholds, see Continuous Integration.
Sources:
Release and NPM Publishing
The release pipeline is a strictly controlled, idempotent process triggered by Git tags. It enforces a "Build Once, Deploy Everywhere" philosophy by packing the library into a tarball and promoting that specific artifact through verification steps.
Release Safety Checks
The pipeline implements several guardrails to prevent broken releases:
- Version Consistency: The Git tag must exactly match the version defined in
package.json.github/workflows/release.yml#30-38 - Artifact Validation: The
scripts/verify-tarball.jsscript is executed against the generated.tgzto ensure no critical files (likedist/) are missing .github/workflows/release.yml#67-68 - Idempotency: Before publishing, the workflow checks the NPM registry via
npm viewto see if the version already exists, preventing failed "already published" errors .github/workflows/release.yml#100-109 - Windows Smoke Test: After publishing, the workflow waits for registry propagation and attempts a global install on a Windows runner to verify cross-platform binary availability .github/workflows/release.yml#140-179
For a deep dive into the publishing logic and artifact verification, see Release Workflow and NPM Publishing.
Sources:
Security and Governance
PALEE maintains strict security invariants, particularly regarding native dependencies.
Native Module Guardrail
A custom security job in security.yml scans the production dependency tree to ensure zero native binaries or toolchains (e.g., node-gyp, napi-rs) are included .github/workflows/security.yml#46-101 This preserves the project's goal of being a lightweight, pure-JS/TS CLI tool.
Repository Management
- Label Synchronization: The project uses a declarative
labels.ymlfile to manage GitHub labels, synchronized viasync-labels.yml.github/workflows/sync-labels.yml#1-30 - Automated Labeling: Pull Requests are automatically categorized (e.g.,
core,tests,build) based on the file paths modified, using theactions/labeler.github/workflows/pr-labeler.yml#1-19
Sources:
Code-to-Workflow Mapping
This diagram maps specific codebase entities (scripts and config files) to the high-level workflow jobs that consume them.
Entity Relationship Diagram
Sources: