ci: reconcile withheld managed Forgejo workflows #10
Loading…
Reference in a new issue
No description provided.
Delete branch "ci/reconcile-managed-workflows"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The earlier workflow re-render ran without forge access, so it withheld three visibility-dependent workflows:
.forgejo/workflows/checks.yml,.forgejo/workflows/dedupe-check.yml, and.forgejo/workflows/release.yml. A forge-connected@j4k/align --fixreconciles them here.The re-rendered files carry the
pnpm_config_verify_deps_before_runguard, which is what currently turnsChecks / quality-checksred: pnpm 11 auto-reinstalls dependencies mid-run with lifecycle scripts re-enabled.No forge-side settings changed.
Approach review: The approach looks good. Re-rendering the three managed workflows through
@j4k/alignis the appropriate project-standard change, and applying the pnpm guard at workflow scope consistently preserves the hardened install behavior across each independent workflow.Approach review by Codex GPT-5.6 SOL (gpt-5.6-sol)
Approach review: The approach looks good. The guard is placed at workflow scope in each affected workflow, including the reusable checks workflow, so it covers all subsequent pnpm invocations without relying on project configuration that the PR checks intentionally remove. No materially better alternative was found.
Approach review by Codex GPT-5.6 Luna (gpt-5.6-luna)
Approach review: The approach looks good. The workflow-level
pnpm_config_verify_deps_before_runguard is appropriately scoped to each independently rendered workflow and preserves the existing hardened install boundary for subsequent pnpm commands. No materially better alternative is evident.Approach review by Codex GPT-5.6 Luna (gpt-5.6-luna)
Approach review: The workflow-level pnpm guard is appropriately scoped across the three independent workflows and addresses the pnpm 11 behavior without relying on PR-controlled project configuration. No materially better alternative identified.
Approach review by Codex GPT-5.6 Luna (gpt-5.6-luna)
Summary: No actionable issues found.
Code review by Codex GPT-5.6 Luna (gpt-5.6-luna)
Summary: No actionable issues found.
Code review by Codex GPT-5.6 Luna (gpt-5.6-luna)
Summary: No actionable issues found.
Code review by Codex GPT-5.6 Luna (gpt-5.6-luna)
Summary: No actionable defects found. The change is correct and complete; one informational note.
I verified the technical claims in the added comment block against pnpm 11.8.0 (the version pinned by
packageManagerand resolved bypnpm/action-setup@v5), by readingpnpm/dist/pnpm.mjsand by running the two spellings against a drifted workspace:install. The config defaults table sets"verify-deps-before-run": "install", and an out-of-syncpnpm runreproduced the mid-runpnpm installre-invocation viarunDepsStatusCheck.pnpm_config_verify_deps_before_runis read raw, inaddSettingsFromWorkspaceManifestToConfig:if (process.env.pnpm_config_verify_deps_before_run != null) pnpmConfig.verifyDepsBeforeRun = .... Setting it to"false"matches nocasein the switch, so the auto-install is skipped. Confirmed by running the script with the env var set: no install fired.npm_config_spelling is ignored. Withnpm_config_verify_deps_before_run=false, the auto-install still ran. The comment's warning is accurate, not defensive folklore.createInstallArgsrebuilds only--production/--dev/--no-optionalfrom the recorded workspace state, so--ignore-scriptsand--ignore-pnpmfileare genuinely lost on the re-install. Inrelease.ymlthat re-install could previously fire frompnpm exec semantic-releasewhile both OIDC registry tokens were still in~/.npmrc(that workflow never strips it), so the guard closes a concrete exposure.envis supported by Forgejo's act fork: bothmodel.Workflowandjobparser.SingleWorkflowcarry anEnv map[string]stringfield, so the value survives the single-job split.release.yml's workflow-levelenvdoes not propagate into theuses: ./.forgejo/workflows/checks.ymlreusable-workflow call, butchecks.ymlcarries its own copy, so there is no gap.checks.yml,dedupe-check.yml, andrelease.ymlare exactly the three workflows under.forgejo/workflows/that invoke pnpm, and all three now carry the guard.Code review by Claude Code Opus (opus)
@ -21,0 +26,4 @@# pnpm_config_verify_deps_before_run raw from the environment, and the# npm_config_ spelling is silently ignored.env:pnpm_config_verify_deps_before_run: "false"ℹ️ Info: No action needed — noting for the record that this guard is inert in this particular workflow. In pnpm 11.8.0 the
verifyDepsBeforeRungate is only consulted by therunandexeccommand handlers (if (opts.verifyDepsBeforeRun) await runDepsStatusCheck(opts)); neitherpnpm installnorpnpm dedupereaches it. This file's only pnpm steps arepnpm install --frozen-lockfile --ignore-scripts --ignore-pnpmfileandpnpm dedupe --check --ignore-scripts --ignore-pnpmfile, so nothing here could have triggered the mid-run re-install.Keeping it is still the right call: it costs nothing, it is what the managed render emits uniformly, and it pre-empts the trap the moment a
pnpm <script>orpnpm execstep is ever added to this file. The load-bearing copies are the ones inchecks.yml(which runspnpm knip,pnpm build,pnpm run test, …) andrelease.yml(pnpm exec semantic-release).