PALEE CLI

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:

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 check which combines ESLint for linting and tsc for strict type checking .github/workflows/ci.yml
  • Testing & Coverage: Running the full invariant test suite with c8 for coverage reporting .github/workflows/ci.yml
  • Smoke Installation: Building a production tarball and performing a global npm install to verify the CLI binary (palee) functions correctly in a clean environment .github/workflows/ci.yml

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:

  1. Version Consistency: The Git tag must exactly match the version defined in package.json.github/workflows/release.yml
  2. Artifact Validation: The scripts/verify-tarball.js script is executed against the generated .tgz to ensure no critical files (like dist/) are missing .github/workflows/release.yml
  3. Idempotency: Before publishing, the workflow checks the NPM registry via npm view to see if the version already exists, preventing failed "already published" errors .github/workflows/release.yml
  4. 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

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 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.yml file to manage GitHub labels, synchronized via sync-labels.yml.github/workflows/sync-labels.yml
  • Automated Labeling: Pull Requests are automatically categorized (e.g., core, tests, build) based on the file paths modified, using the actions/labeler.github/workflows/pr-labeler.yml

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:

Released under the MIT License.

Copyright © 2026 Kuldeep Kumar. Powered by VitePress.