5 Commits

Include renames

Author	SHA1	Message	Date
valknarandClaude Sonnet 5	8ca8c57793	Stop routing pnpm install through the Gitea registry ... actions/setup-node's registry-url sets the *default* npm registry for every install, not just publishing - since triggershell is an unscoped package name, that meant `pnpm install` tried to fetch every ordinary dependency (zod, typescript, ws, ...) from dev.pivoine.art/api/packages/valknar/npm/ instead of the public npm registry, and got hammered with 429s retrying each one. Removes registry-url from setup-node entirely (installs go back to the default public registry) and instead scopes the auth token to just that one registry host+path via `pnpm config set "//dev.pivoine.art/api/packages/valknar/npm/:_authToken" ...` right before the publish step - publishConfig.registry in package.json already tells `pnpm publish` specifically where to go (verified locally via `pnpm publish --dry-run` earlier), this only supplies the matching credential without touching install resolution. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-16 14:16:41 +02:00
valknarandClaude Sonnet 5	3f391ff584	Drop pnpm cache from the release workflow - not reachable on this runner ... actions/setup-node's cache: pnpm option tries to hit this Gitea instance's Actions cache service, which times out (ETIMEDOUT against an internal address) rather than failing fast - burning ~5 minutes on every run before falling back to an uncached install anyway. Not worth it for a release workflow that runs once per tag. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-16 14:13:46 +02:00
valknarandClaude Sonnet 5	ef453eadd0	Bump release workflow's Node to 22 - pnpm 11 needs it to even run ... pnpm 11.21.0 (pinned in packageManager) now uses node:sqlite internally, which requires Node >=22.13 - unrelated to this project's own engines.node: >=20 floor for end users. With node-version: 20 the runner's pnpm binary couldn't execute at all (ERR_UNKNOWN_BUILTIN_MODULE on the first pnpm invocation inside actions/setup-node's cache-path detection), before ever reaching the actual lint/build/publish steps. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-16 14:05:48 +02:00
valknarandClaude Sonnet 5	a11dfd8f7e	Rename the release workflow's secret to PACKAGE_TOKEN ... Gitea rejects secret names starting with GIT (not just the GITEA_/ GITHUB_ prefixes), so GITEA_PACKAGE_TOKEN wasn't a valid name. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-16 14:01:40 +02:00
valknarandClaude Sonnet 5	2a5b0b98f4	Add a Gitea Actions release workflow: lint/typecheck/format check -> build -> publish ... Triggered on tags matching v*.*.* - runs the quality gate (lint, typecheck, format:check, the existing test suite, build) as individual steps for clear failure attribution, then publishes to this Gitea instance's own npm registry (dev.pivoine.art, unscoped package name - Gitea's npm registry supports that directly, no @owner/ rename needed). The release version comes from the git tag (v1.0.0 -> 1.0.0 via `npm pkg set`), patched into package.json only in the CI run, never committed back. publishConfig.registry in package.json is a static string (safe to commit); the auth token is supplied at publish time via NODE_AUTH_TOKEN, written to a CI-generated user-level .npmrc by actions/setup-node's registry-url option rather than a repo-committed one - pnpm >=10.34.2/11.5.3 (this repo pins 11.21.0) blocks ${VAR} expansion in repository-controlled npmrc/pnpm-workspace.yaml specifically to stop a malicious repo from exfiltrating CI secrets that way, so the token can't live in a committed .npmrc at all. Verified locally end-to-end short of the actual registry upload: lint/typecheck/format:check/test/build all pass, and `pnpm publish --dry-run --no-git-checks` after a temporary version bump confirms publishConfig.registry resolves to the right URL and prepack (next build) fires automatically as part of publish. One-time manual setup this can't do by itself (documented in the plan file): a repo-scoped Gitea Personal Access Token with the `package` Read&Write scope, stored as the GITEA_PACKAGE_TOKEN repo secret - Gitea's own auto-injected GITEA_TOKEN explicitly cannot publish packages (unimplemented per Gitea's own docs). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-16 13:55:47 +02:00