Gitpulse ships distributable CLI with Pages workflow
Gitpulse is now installable as a regular npm package. A new reusable GitHub Actions workflow lets any repo publish its editorial story feed to Pages with a single YAML block.
Gitpulse's internal GitHub Action was never shippable — the ncc bundler collided with TypeScript configuration, and the workflow only worked for the project's own deployment. A complete rethink swaps the action for a proper npm package, cli, exposing analyze and build commands that run anywhere: GitHub Actions, Vercel build hooks, Netlify functions, or a quick npx call.
The new publish-pages.yaml reusable workflow wraps gitpulse analyze + gitpulse build + actions/deploy-pages in a single reusable artifact. Consumers add six lines to their repo's workflow directory — granting contents/pages/id-token permissions — and the site updates on every push. Base path and site URL are configurable for user/org Pages, custom domains, or subdirectory prefixes like "/blog".
The build command itself handles site generation by cloning the repository at the matching gitpulse tag, sanitizing the environment (stripping GITHUB_TOKEN, OPENAI_API_KEY, and any *_TOKEN/_SECRET/_PASSWORD/_API_KEY vars), then running the Next.js static export. Output lands in GITPULSE_OUT_DIR ready for Pages deployment.
Publishing is handled by release-please through Trusted Publishing — OIDC credentials minted per-release, no long-lived NPM_TOKEN secret. Both the root package and @gitpulse/cli bump together via linked-versions, keeping the v0/v1 floating tags synchronized.
In the @gitpulse/site app, GITPULSE_BASE_PATH now defaults to auto-derived /{owner}/{repo} for Pages but accepts "none" for root deployments or any literal prefix. SEO canonicals stay consistent regardless of how the site is deployed.