Exclude .pnpm-store from prettier and git

On the Gitea runner, pnpm's content-addressable store ends up inside the workspace (.pnpm-store/) instead of the global cache location - format:check was scanning its content-addressable blobs as if they were source files, some of which happen to parse as JS/TS-like text and crash prettier's parser outright rather than just wasting time. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Stop routing pnpm install through the Gitea registry
2026-08-16 14:19:44 +02:00 · 2026-08-16 14:16:41 +02:00 · 2026-08-16 14:13:46 +02:00 · 2026-08-16 14:05:48 +02:00
3 changed files with 15 additions and 5 deletions
@@ -17,9 +17,7 @@ jobs:
      - uses: https://github.com/actions/setup-node@v4
        with:
-          node-version: 20
+          node-version: 22
          cache: pnpm
          registry-url: https://dev.pivoine.art/api/packages/valknar/npm/
      - run: pnpm install --frozen-lockfile
@@ -32,7 +30,13 @@ jobs:
      - name: Set package version from the tag
        run: npm pkg set version="${GITHUB_REF_NAME#v}"
      # Scoped to this one registry host+path (via publishConfig.registry in package.json) rather
      # than actions/setup-node's registry-url, which would set it as the *default* registry for
      # every install - breaking `pnpm install` for this project's own (unscoped, public) deps.
      - name: Configure registry auth for publish
        run: pnpm config set "//dev.pivoine.art/api/packages/valknar/npm/:_authToken" "$PACKAGE_TOKEN"
        env:
          PACKAGE_TOKEN: ${{ secrets.PACKAGE_TOKEN }}
      - name: Publish to Gitea npm registry
        run: pnpm publish --no-git-checks
        env:
          NODE_AUTH_TOKEN: ${{ secrets.PACKAGE_TOKEN }}
@@ -1,5 +1,6 @@
 # dependencies
 /node_modules
 /.pnpm-store
 /.pnp
 .pnp.*
 .yarn/*
@@ -1,2 +1,7 @@
 # Machine-generated - pnpm owns this file's formatting, not prettier.
 pnpm-lock.yaml
 # pnpm's local content-addressable store - on some runners this ends up inside the workspace
 # instead of the global cache location; its blobs aren't source files (some happen to parse as
 # JS/TS-like content, which crashes prettier's parser rather than just wasting time on them).
 .pnpm-store/
Author	SHA1	Message	Date
valknarandClaude Sonnet 5	677aabfa30	Exclude .pnpm-store from prettier and git Release / release (push) Successful in 1m25s Details On the Gitea runner, pnpm's content-addressable store ends up inside the workspace (.pnpm-store/) instead of the global cache location - format:check was scanning its content-addressable blobs as if they were source files, some of which happen to parse as JS/TS-like text and crash prettier's parser outright rather than just wasting time. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-16 14:19:44 +02:00
valknarandClaude Sonnet 5	8ca8c57793	Stop routing pnpm install through the Gitea registry Release / release (push) Canceled after 1m42s Details 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 Release / release (push) Canceled after 8m18s Details 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