@intentius/chant-lexicon-forgejo 0.122.0 → 0.123.0

package/dist/components/generate-op-pipeline.d.ts

@@ -29,62 +29,28 @@
  * the runner can fetch it.
  *
  * `comment` (#2231) crosses over, since chant #2291: it posts onto the
- * triggering pull request by shelling to `gh` against `${GITHUB_API_URL}`,
- * and a Forgejo Actions job already sets that (and `github.token`) the same
- * way a GitHub Actions job does. This generator used to refuse the mode by
- * name here, on the premise that chant had no way to point `gh` at a Forgejo
- * instance; that premise was checked against a real Forgejo
- * 12.0.4+gitea-1.22.0 instance during INTENTIUS/choudoufu#1027 and found
- * false — the failure was `gh api` resolving a *relative* path against
- * `/api/v3`, which Forgejo does not serve, not an unreachable forge. See
- * `reconcilePr`'s `postOrUpdateComment` (`packages/core/src/op/activities/reconcile.ts`)
- * for the fix.
+ * triggering pull request against `${GITHUB_API_URL}`, and a Forgejo Actions
+ * job already sets that (and `github.token`) the same way a GitHub Actions
+ * job does. This generator used to refuse the mode by name here, on the
+ * premise that chant had no way to reach a Forgejo instance; that premise
+ * was checked against a real Forgejo 12.0.4+gitea-1.22.0 instance during
+ * INTENTIUS/choudoufu#1027 and found false. Since chant #3757 the post goes
+ * through the Forgejo client in `packages/core/src/pr-forge.ts` over `fetch`
+ * rather than through `gh`, so the job's image needs no `gh` either.
  *
- * `issue` (`gh issue create`/`postOrUpdateGithubIssue`) does not cross over,
- * and chant #2315 is why: it remained un-refused-but-unverified after #2304
- * lifted `comment`'s refusal, and settling that gap the same way — against a
- * real instance rather than a mock — found a real failure, so the refusal
- * below is reinstated rather than lifted. Tested against the same
- * 12.0.4+gitea-1.22.0 image (`codeberg.org/forgejo/forgejo:12`) with a repo,
- * an issue, and a pull request created on it: the *read* half of
- * `postOrUpdateGithubIssue` checks out fine on Forgejo — plain paginated
- * `GET .../issues?state=open` (no `/search/issues`, confirmed absent from a
- * live Forgejo's own OpenAPI spec) returns pull requests interleaved with
- * issues exactly as GitHub's endpoint does, and the `.pull_request == null`
- * filter and the marker `startswith` match both behave identically to
- * GitHub. The *write* half did not: `postOrUpdateGithubIssue`'s POST and
- * PATCH calls carried only `GH_TOKEN` (in fact, on the `issue` path, not even
- * that — `reconcilePr` handed it `execAsync` with no `env` override at all,
- * chant #2320), and `gh`'s own documented environment variables (`gh help
- * environment`) scope `GH_TOKEN`/`GITHUB_TOKEN` to "github.com or a subdomain
- * of ghe.com" — never a self-hosted Forgejo. A `GH_DEBUG=api` POST against
- * the live instance, with `GH_TOKEN` and `GITHUB_API_URL` set exactly as the
- * generated workflow sets them, sent no `Authorization` header at all and
- * Forgejo answered `{"message":"token is required"}` (HTTP 401); adding
- * `GH_HOST` alongside `GH_TOKEN` made no difference. The same shape was what
- * `postOrUpdateComment`'s writes carried too, which is why #2304's "verified
- * against a real Forgejo instance" could not have gone through the generated
- * workflow's own credential path — either that session had a `gh auth login`
- * already stored for the test instance, which a real Actions job's fresh
- * checkout never has, or a different `gh` build was in play.
- *
- * Chant #2333 fixed that credential for both modes: `ghCredentialEnv` now
- * forwards the resolved token as `GH_ENTERPRISE_TOKEN` beside `GH_TOKEN`,
- * which is the variable `gh` reads for a host in neither of the two classes
- * above. #2333's own probe against the same image also narrowed the claim
- * made here: `GH_ENTERPRISE_TOKEN` authenticated the identical call *without*
- * a `GH_HOST` beside it, because the full URL #2291 built already names the
- * host. So the premise this refusal was reinstated on no longer holds, and
- * both halves of `postOrUpdateGithubIssue` — the paginated read and the
- * POST/PATCH write — were driven green end to end against a live
- * 12.0.4+gitea-1.22.0 instance under #2333, from a shell with no stored
- * `gh auth login`.
- *
- * The refusal below is nonetheless left standing here, because lifting it is
- * a generator behavior change with its own YAML surface to settle and #2333
- * was scoped to the credential. Lifting it is filed separately; this comment
- * is corrected rather than acted on so the stated reason does not outlive the
- * fact it rested on.
+ * `issue` crosses over too, since chant #2351. It was refused here from
+ * #2332 on, after chant #2315 drove the mode against a real Forgejo
+ * 12.0.4+gitea-1.22.0 instance: the paginated read and the `.pull_request ==
+ * null` filter behaved as on GitHub, but every POST and PATCH answered
+ * `{"message":"token is required"}` (HTTP 401), because `gh` sends
+ * `GH_TOKEN` only to github.com and `ghe.com` hosts. #2333 fixed that
+ * credential, and #3757 moved the mode off `gh` onto the Forgejo client in
+ * `packages/core/src/pr-forge.ts`, which sends `Authorization: token …`
+ * itself. The job this emits for a cron `issue` Op is github's, unchanged:
+ * the same trigger, and the same `GH_TOKEN`/`GITHUB_TOKEN` from
+ * `github.token` on the run step, which is the credential the mode reads.
+ * Only `permissions:` is dropped, as for every mode, so what that token may
+ * write on a scheduled run is the runner's configuration.
  *
  * A spec's `environment` (#2257) is dropped on the same terms as
  * `permissions:`, and for a stronger reason: Forgejo Actions has no
@@ -97,25 +63,18 @@
  * still holds the apply here is chant's own gate (#2119), which is a fact on
  * the `chant/lifecycle` branch and needs nothing from the forge.
  *
- * The gated-apply notice job (#2243) does not cross over either, for the same
- * reason and by the same mechanism as `permissions:`: it shells to `gh`, which
- * a Forgejo `act_runner` neither ships nor can point at its own instance, and
- * it runs outside the Op's container image, where a hosted GitHub runner's
- * preinstalled tools would be. So the doc rebuilt below simply does not carry
- * `gatedNoticeDoc`, and the job is dropped. What does cross over is the half
- * that needs no forge API: a `push` job still runs with `--gated-exit 0`, so a
- * Forgejo apply that stops at its gate is a green run rather than a red one,
- * and `chant run` still writes the gate and the approve command to
- * `GITHUB_STEP_SUMMARY`, which Forgejo Actions sets like GitHub does.
- *
- * The gate-notice job's own reason for being — `outputs: { gated, op, gate,
- * approve }` on the Op's job, and the `node -e` step that writes them to
- * `$GITHUB_OUTPUT` — does not survive it either (#2294). Both existed only for
- * that job to read via `needs.<job>.outputs`; with the job gone, so is every
- * reader, and `buildGithubOpPipelineDocs` is asked for neither
- * (`emitGatedOutputs: false` below) rather than emitting them here and
- * stripping them back out. Should the Forgejo posting work in #2291 grow a
- * notice job of its own, this is the one flag that brings both back.
+ * The gated-apply notice job (#2243) crosses over since #3773. It used to
+ * shell to `gh` on GitHub's hosted runner image, which a Forgejo runner
+ * neither ships nor can point at its own instance, so it was dropped here
+ * along with the apply job's `gated`/`op`/`gate`/`approve` outputs that
+ * only it read (#2294). It now runs in the Op's own image and posts through
+ * `@intentius/chant/pr-forge`, whose Forgejo client finds the pull request
+ * a commit merged with `commits/{sha}/pull` and sends `Authorization: token`
+ * itself. So the doc rebuilt below carries `gatedNoticeDoc` through the
+ * same dialect transform as the jobs, which drops its `permissions:` the
+ * way it drops every scope but `id-token`. A `push` job also still runs
+ * with `--gated-exit 0`, and `chant run` still writes the gate and the
+ * approve command to `GITHUB_STEP_SUMMARY`.
  *
  * A spec's own `variables` (#2290) crosses over unchanged: forgejo reuses the
  * same job-level `env:` github's builder emits, and the dialect transform

package/dist/components/generate-op-pipeline.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"generate-op-pipeline.d.ts","sourceRoot":"","sources":["../../src/components/generate-op-pipeline.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+HG;AAOH,OAAO,KAAK,EACV,wBAAwB,EACxB,gBAAgB,EAChB,eAAe,EAChB,MAAM,0BAA0B,CAAC;AAClC,OAAO,EAA2B,KAAK,qBAAqB,EAAE,MAAM,YAAY,CAAC;AAmCjF;;;;;;;;GAQG;AACH,wBAAgB,yBAAyB,CACvC,GAAG,EAAE,eAAe,EAAE,EACtB,OAAO,GAAE,wBAA6B,EACtC,cAAc,GAAE,qBAA0B,GACzC,gBAAgB,CA+ClB"}
+{"version":3,"file":"generate-op-pipeline.d.ts","sourceRoot":"","sources":["../../src/components/generate-op-pipeline.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsFG;AAOH,OAAO,KAAK,EACV,wBAAwB,EACxB,gBAAgB,EAChB,eAAe,EAChB,MAAM,0BAA0B,CAAC;AAClC,OAAO,EAA2B,KAAK,qBAAqB,EAAE,MAAM,YAAY,CAAC;AAmCjF;;;;;;;;GAQG;AACH,wBAAgB,yBAAyB,CACvC,GAAG,EAAE,eAAe,EAAE,EACtB,OAAO,GAAE,wBAA6B,EACtC,cAAc,GAAE,qBAA0B,GACzC,gBAAgB,CA6BlB"}

package/dist/integrity.json

@@ -1,7 +1,7 @@
 {
   "algorithm": "sha256",
   "artifacts": {
-    "manifest.json": "394736ec8b39447a6889f39cde46a43490537a102e326dd74841ab8f4f2d23cc",
+    "manifest.json": "151167f06f66d77050d96f35856fc324fddd493067350967d26bb1dc3c995c63",
     "meta.json": "44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
     "types/index.d.ts": "66204549b2a864ab5489e3f02c1878e73ab4b3c9d938cfb480b66f71543a43de",
     "rules/delegate-to-github.ts": "1060cda40f4b73d6cca3ba3fa13b80b4886147d4034c88584c2d80c5510dbe5e",
@@ -9,5 +9,5 @@
     "rules/wfj011.ts": "fcb8bf6685d744af20ad804ce929488257995c74b9a3353b2eacae3768d1c83e",
     "skills/chant-forgejo.md": "f28d7fb69fb1cfd992496ef41fda0ea5ccd54a29b84ea1c501a44f6a3992c4d5"
   },
-  "composite": "0c39972e554f303c0ee13c68abff63d7f9105ca95350966af4200206cd4a7dc6"
+  "composite": "14703e6af2b10d8c29a0924bae768c39d2c913ba486a3fb0af8c7b285195062f"
 }

package/dist/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "forgejo",
-  "version": "0.122.0",
+  "version": "0.123.0",
   "chantVersion": ">=0.1.0",
   "namespace": "Forgejo",
   "intrinsics": [],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@intentius/chant-lexicon-forgejo",
-  "version": "0.122.0",
+  "version": "0.123.0",
   "description": "Forgejo / Codeberg / Gitea Actions lexicon for chant — a thin GitHub Actions dialect",
   "license": "Apache-2.0",
   "homepage": "https://intentius.io/chant",
@@ -54,8 +54,8 @@
   },
   "peerDependencies": {
     "zod": "^4.3.6",
-    "@intentius/chant": "^0.122.0",
-    "@intentius/chant-lexicon-github": "^0.122.0"
+    "@intentius/chant": "^0.123.0",
+    "@intentius/chant-lexicon-github": "^0.123.0"
   },
   "scripts": {
     "generate": "tsx src/codegen/generate-cli.ts",

package/src/components/generate-op-pipeline.test.ts

@@ -13,6 +13,9 @@ import { generateGithubOpPipeline } from "@intentius/chant-lexicon-github/compon
 import type { ScheduledOpSpec } from "@intentius/chant/lexicon";
 
 interface ParsedJob {
+  needs?: string;
+  if?: string;
+  permissions?: Record<string, string>;
   "runs-on"?: string;
   container?: string;
   environment?: Record<string, string>;
@@ -33,7 +36,7 @@ describe("generateForgejoOpPipeline: structure (github-shaped)", () => {
   test("one file per scheduled Op, each a valid workflow with one job", () => {
     const specs: ScheduledOpSpec[] = [
       { name: "actions-audit", schedule: "0 6 * * *" },
-      { name: "prod-reconcile", schedule: "0 * * * *", findingMode: "pull-request" },
+      { name: "prod-reconcile", schedule: "0 * * * *", findingMode: "issue" },
     ];
     const result = generateForgejoOpPipeline(specs);
 
@@ -78,7 +81,7 @@ describe("generateForgejoOpPipeline: dialect applied", () => {
 describe("generateForgejoOpPipeline: non-cron trigger survives the dialect transform (#2084)", () => {
   test("a pull_request trigger round-trips through the Forgejo dialect, with permissions: still dropped", () => {
     const specs: ScheduledOpSpec[] = [
-      { name: "tf-plan", trigger: { kind: "pull_request", branches: ["main"] }, findingMode: "pull-request" },
+      { name: "tf-plan", trigger: { kind: "pull_request", branches: ["main"] }, findingMode: "issue" },
     ];
     const fj = generateForgejoOpPipeline(specs);
     const gh = generateGithubOpPipeline(specs);
@@ -149,32 +152,41 @@ describe("generateForgejoOpPipeline: comment finding mode crosses over (#2291)",
   });
 });
 
-describe("generateForgejoOpPipeline: issue finding mode is refused by name (#2315)", () => {
-  // `comment` (above) was checked against a real Forgejo instance and cleared
-  // (#2291, #2304). `issue` stayed un-refused-but-unverified after that —
-  // this is the same settling, and it came out the other way: a real
-  // instance showed the write half of `postOrUpdateGithubIssue` cannot
-  // authenticate (`gh`'s GH_TOKEN never reaches a self-hosted Forgejo), so
-  // the refusal this mode used to carry (pre-#2304, for a different reason)
-  // is reinstated rather than left lifted. See the module doc above for the
-  // reproduction.
-  test("findingMode issue is refused, naming the Op and the real-instance failure", () => {
-    const specs: ScheduledOpSpec[] = [{ name: "prod-watch", schedule: "0 6 * * *", findingMode: "issue" }];
-    expect(() => generateForgejoOpPipeline(specs)).toThrow(
-      /Scheduled Op "prod-watch".*findingMode "issue".*token is required/s,
-    );
-  });
-
-  test("github generates the same spec cleanly, so the refusal is forgejo's and not the shared builder's", () => {
+describe("generateForgejoOpPipeline: issue finding mode crosses over (#2351)", () => {
+  // Refused here from #2332 to #2351: a real Forgejo instance answered 401 to
+  // the writes `gh` made for this mode, because `gh` never sent its token to
+  // a self-hosted host (#2315). #2333 fixed that credential, and #3757 moved
+  // the mode onto the forge client in `pr-forge.ts`, which sends the header
+  // itself. So the generator emits the mode as github does: same trigger,
+  // same job, same step env, with `permissions:` dropped by the dialect.
+  test("a cron issue Op generates cleanly", () => {
     const specs: ScheduledOpSpec[] = [{ name: "prod-watch", schedule: "0 6 * * *", findingMode: "issue" }];
-    expect(() => generateGithubOpPipeline(specs)).not.toThrow();
+    expect(() => generateForgejoOpPipeline(specs)).not.toThrow();
   });
 
-  test("a pull_request-triggered Op is refused the same way — issue mode needs no trigger to fail on", () => {
+  test("job/trigger/findingMode parity with the github generator", () => {
     const specs: ScheduledOpSpec[] = [
+      { name: "prod-watch", schedule: "0 6 * * *", findingMode: "issue" },
       { name: "tf-plan", trigger: { kind: "pull_request", branches: ["main"] }, findingMode: "issue" },
     ];
-    expect(() => generateForgejoOpPipeline(specs)).toThrow(/findingMode "issue"/);
+    expect(generateForgejoOpPipeline(specs).jobs).toEqual(generateGithubOpPipeline(specs).jobs);
+  });
+
+  test("the cron job carries github.token as GH_TOKEN and GITHUB_TOKEN, the credential the mode reads", () => {
+    const specs: ScheduledOpSpec[] = [{ name: "prod-watch", schedule: "0 6 * * *", findingMode: "issue" }];
+    const fjDoc = parseFile(generateForgejoOpPipeline(specs).files[0].yaml);
+    const ghDoc = parseFile(generateGithubOpPipeline(specs).files[0].yaml);
+    const run = fjDoc.jobs!["prod-watch"].steps.at(-1)!;
+    expect(run.run).toBe("chant run prod-watch");
+    expect((run as { env?: Record<string, string> }).env).toEqual({
+      GITHUB_TOKEN: "${{ github.token }}",
+      GH_TOKEN: "${{ github.token }}",
+    });
+    expect(fjDoc.on).toEqual(ghDoc.on);
+    expect(fjDoc.permissions).toBeUndefined();
+    // github grants the scope the mode needs; on Forgejo what the token may
+    // write is the runner's configuration.
+    expect(ghDoc.permissions).toEqual({ contents: "read", issues: "write" });
   });
 });
 
@@ -238,14 +250,18 @@ describe("generateForgejoOpPipeline: the gated apply on push (#2243)", () => {
     expect(step?.run).toContain("chant run app-apply --gated-exit 0 --json");
   });
 
-  test("the notice job does not: it shells to `gh`, which no Forgejo runner points at its own instance", () => {
+  test("the notice job crosses over too, posting through pr-forge rather than gh (#3773)", () => {
     const fj = parseFile(generateForgejoOpPipeline([pushSpec]).files[0].yaml);
-    const gh = parseFile(generateGithubOpPipeline([pushSpec]).files[0].yaml);
-    // Dropped the same way `permissions:` is dropped — by not being carried
-    // onto the rebuilt doc — and github still has it, so the omission is
-    // forgejo's rather than the shared builder's.
-    expect(Object.keys(fj.jobs ?? {})).toEqual(["app-apply"]);
-    expect(gh.jobs).toHaveProperty("app-apply-gate-notice");
+    expect(Object.keys(fj.jobs ?? {})).toEqual(["app-apply", "app-apply-gate-notice"]);
+    const notice = fj.jobs!["app-apply-gate-notice"];
+    expect(notice.needs).toBe("app-apply");
+    expect(notice.if).toBe("needs.app-apply.outputs.gated == 'true'");
+    expect(notice.container).toBe("node:22");
+    // The dialect drops the job's permissions like every scope but id-token.
+    expect(notice.permissions).toBeUndefined();
+    const script = notice.steps[0].run ?? "";
+    expect(script).toContain('from "@intentius/chant/pr-forge"');
+    expect(script).not.toMatch(/(^|\s)gh\s/m);
   });
 
   /**
@@ -262,7 +278,7 @@ describe("generateForgejoOpPipeline: the gated apply on push (#2243)", () => {
   test("the exit-code capture crosses the Forgejo dialect with no shell override — its job runs in a container, whose default shell is sh", () => {
     const doc = parseFile(generateForgejoOpPipeline([pushSpec]).files[0].yaml);
     const job = doc.jobs!["app-apply"];
-    expect(job.container).toBe("node:22-slim");
+    expect(job.container).toBe("node:22");
     const step = job.steps.find((s) => s.id === "chant-run");
     expect(step?.shell).toBeUndefined();
     expect(step?.run).not.toContain("pipefail");
@@ -318,7 +334,7 @@ describe("generateForgejoOpPipeline: a dropped deployment environment (#2257)",
       "jobs:",
       "  actions-audit:",
       "    runs-on: docker",
-      "    container: node:22-slim",
+      "    container: node:22",
       "    steps:",
       "      - uses: https://code.forgejo.org/actions/checkout@v7",
       "      - run: chant run actions-audit",
@@ -329,7 +345,7 @@ describe("generateForgejoOpPipeline: a dropped deployment environment (#2257)",
 
   test("a spec with no environment emits the bytes it emitted before the option existed", () => {
     const yaml = generateForgejoOpPipeline([
-      { name: "actions-audit", schedule: "0 6 * * *", findingMode: "pull-request" },
+      { name: "actions-audit", schedule: "0 6 * * *", findingMode: "issue" },
     ]).files[0].yaml;
     expect(yaml).toBe(AUDIT_YAML_BEFORE_2257);
   });
@@ -456,41 +472,23 @@ describe("generateForgejoOpPipeline: per-Op variables land on the job, not the w
 });
 
 /**
- * chant #2294 — the gated-apply outputs survive the notice job that consumed
- * them. Asserted directly against forgejo's own output: no `outputs:` on the
- * push job, no `node -e` line writing to `$GITHUB_OUTPUT`, while github's
- * generator (same spec) still carries both because its notice job still reads
- * them.
+ * chant #2294 dropped the gated-apply outputs on Forgejo while nothing read
+ * them; #3773 brings back the notice job that does, and the outputs with it.
  */
-describe("generateForgejoOpPipeline: no unconsumed outputs (#2294)", () => {
+describe("generateForgejoOpPipeline: the outputs the notice job reads (#2294, #3773)", () => {
   const pushSpec: ScheduledOpSpec = { name: "live-apply", trigger: { kind: "push", branches: ["main"] } };
 
-  test("the push job carries no outputs: block", () => {
-    const doc = parseFile(generateForgejoOpPipeline([pushSpec]).files[0].yaml);
-    expect(doc.jobs!["live-apply"].outputs).toBeUndefined();
-  });
-
-  test("the run step carries no node -e line writing to $GITHUB_OUTPUT", () => {
+  test("the push job publishes what it stopped on, as on github", () => {
     const doc = parseFile(generateForgejoOpPipeline([pushSpec]).files[0].yaml);
-    const step = doc.jobs!["live-apply"].steps.find((s) => s.id === "chant-run");
-    expect(step?.run).not.toContain("node -e");
-    expect(step?.run).not.toContain("GITHUB_OUTPUT");
-    // The tee'd invocation survives — it's what puts the run's own record in
-    // the log, gate-notice job or not.
-    expect(step?.run).toContain("| tee");
-    expect(step?.run).toContain("chant run live-apply --gated-exit 0 --json");
-  });
-
-  test("github, generated from the same spec, still carries both — the drop is forgejo's dialect, not the shared builder", () => {
-    const gh = parseFile(generateGithubOpPipeline([pushSpec]).files[0].yaml);
-    const ghStep = gh.jobs!["live-apply"].steps.find((s) => s.id === "chant-run");
-    expect(gh.jobs!["live-apply"].outputs).toEqual({
+    expect(doc.jobs!["live-apply"].outputs).toEqual({
       gated: "${{ steps.chant-run.outputs.gated }}",
       op: "${{ steps.chant-run.outputs.op }}",
       gate: "${{ steps.chant-run.outputs.gate }}",
       approve: "${{ steps.chant-run.outputs.approve }}",
     });
-    expect(ghStep?.run).toContain("node -e");
+    const step = doc.jobs!["live-apply"].steps.find((s) => s.id === "chant-run");
+    expect(step?.run).toContain("GITHUB_OUTPUT");
+    expect(step?.run).toContain("chant run live-apply --gated-exit 0 --json");
   });
 
   test("a non-push (cron) job carries no outputs and no gate script either way", () => {

package/src/components/generate-op-pipeline.ts

@@ -29,62 +29,28 @@
  * the runner can fetch it.
  *
  * `comment` (#2231) crosses over, since chant #2291: it posts onto the
- * triggering pull request by shelling to `gh` against `${GITHUB_API_URL}`,
- * and a Forgejo Actions job already sets that (and `github.token`) the same
- * way a GitHub Actions job does. This generator used to refuse the mode by
- * name here, on the premise that chant had no way to point `gh` at a Forgejo
- * instance; that premise was checked against a real Forgejo
- * 12.0.4+gitea-1.22.0 instance during INTENTIUS/choudoufu#1027 and found
- * false — the failure was `gh api` resolving a *relative* path against
- * `/api/v3`, which Forgejo does not serve, not an unreachable forge. See
- * `reconcilePr`'s `postOrUpdateComment` (`packages/core/src/op/activities/reconcile.ts`)
- * for the fix.
+ * triggering pull request against `${GITHUB_API_URL}`, and a Forgejo Actions
+ * job already sets that (and `github.token`) the same way a GitHub Actions
+ * job does. This generator used to refuse the mode by name here, on the
+ * premise that chant had no way to reach a Forgejo instance; that premise
+ * was checked against a real Forgejo 12.0.4+gitea-1.22.0 instance during
+ * INTENTIUS/choudoufu#1027 and found false. Since chant #3757 the post goes
+ * through the Forgejo client in `packages/core/src/pr-forge.ts` over `fetch`
+ * rather than through `gh`, so the job's image needs no `gh` either.
  *
- * `issue` (`gh issue create`/`postOrUpdateGithubIssue`) does not cross over,
- * and chant #2315 is why: it remained un-refused-but-unverified after #2304
- * lifted `comment`'s refusal, and settling that gap the same way — against a
- * real instance rather than a mock — found a real failure, so the refusal
- * below is reinstated rather than lifted. Tested against the same
- * 12.0.4+gitea-1.22.0 image (`codeberg.org/forgejo/forgejo:12`) with a repo,
- * an issue, and a pull request created on it: the *read* half of
- * `postOrUpdateGithubIssue` checks out fine on Forgejo — plain paginated
- * `GET .../issues?state=open` (no `/search/issues`, confirmed absent from a
- * live Forgejo's own OpenAPI spec) returns pull requests interleaved with
- * issues exactly as GitHub's endpoint does, and the `.pull_request == null`
- * filter and the marker `startswith` match both behave identically to
- * GitHub. The *write* half did not: `postOrUpdateGithubIssue`'s POST and
- * PATCH calls carried only `GH_TOKEN` (in fact, on the `issue` path, not even
- * that — `reconcilePr` handed it `execAsync` with no `env` override at all,
- * chant #2320), and `gh`'s own documented environment variables (`gh help
- * environment`) scope `GH_TOKEN`/`GITHUB_TOKEN` to "github.com or a subdomain
- * of ghe.com" — never a self-hosted Forgejo. A `GH_DEBUG=api` POST against
- * the live instance, with `GH_TOKEN` and `GITHUB_API_URL` set exactly as the
- * generated workflow sets them, sent no `Authorization` header at all and
- * Forgejo answered `{"message":"token is required"}` (HTTP 401); adding
- * `GH_HOST` alongside `GH_TOKEN` made no difference. The same shape was what
- * `postOrUpdateComment`'s writes carried too, which is why #2304's "verified
- * against a real Forgejo instance" could not have gone through the generated
- * workflow's own credential path — either that session had a `gh auth login`
- * already stored for the test instance, which a real Actions job's fresh
- * checkout never has, or a different `gh` build was in play.
- *
- * Chant #2333 fixed that credential for both modes: `ghCredentialEnv` now
- * forwards the resolved token as `GH_ENTERPRISE_TOKEN` beside `GH_TOKEN`,
- * which is the variable `gh` reads for a host in neither of the two classes
- * above. #2333's own probe against the same image also narrowed the claim
- * made here: `GH_ENTERPRISE_TOKEN` authenticated the identical call *without*
- * a `GH_HOST` beside it, because the full URL #2291 built already names the
- * host. So the premise this refusal was reinstated on no longer holds, and
- * both halves of `postOrUpdateGithubIssue` — the paginated read and the
- * POST/PATCH write — were driven green end to end against a live
- * 12.0.4+gitea-1.22.0 instance under #2333, from a shell with no stored
- * `gh auth login`.
- *
- * The refusal below is nonetheless left standing here, because lifting it is
- * a generator behavior change with its own YAML surface to settle and #2333
- * was scoped to the credential. Lifting it is filed separately; this comment
- * is corrected rather than acted on so the stated reason does not outlive the
- * fact it rested on.
+ * `issue` crosses over too, since chant #2351. It was refused here from
+ * #2332 on, after chant #2315 drove the mode against a real Forgejo
+ * 12.0.4+gitea-1.22.0 instance: the paginated read and the `.pull_request ==
+ * null` filter behaved as on GitHub, but every POST and PATCH answered
+ * `{"message":"token is required"}` (HTTP 401), because `gh` sends
+ * `GH_TOKEN` only to github.com and `ghe.com` hosts. #2333 fixed that
+ * credential, and #3757 moved the mode off `gh` onto the Forgejo client in
+ * `packages/core/src/pr-forge.ts`, which sends `Authorization: token …`
+ * itself. The job this emits for a cron `issue` Op is github's, unchanged:
+ * the same trigger, and the same `GH_TOKEN`/`GITHUB_TOKEN` from
+ * `github.token` on the run step, which is the credential the mode reads.
+ * Only `permissions:` is dropped, as for every mode, so what that token may
+ * write on a scheduled run is the runner's configuration.
  *
  * A spec's `environment` (#2257) is dropped on the same terms as
  * `permissions:`, and for a stronger reason: Forgejo Actions has no
@@ -97,25 +63,18 @@
  * still holds the apply here is chant's own gate (#2119), which is a fact on
  * the `chant/lifecycle` branch and needs nothing from the forge.
  *
- * The gated-apply notice job (#2243) does not cross over either, for the same
- * reason and by the same mechanism as `permissions:`: it shells to `gh`, which
- * a Forgejo `act_runner` neither ships nor can point at its own instance, and
- * it runs outside the Op's container image, where a hosted GitHub runner's
- * preinstalled tools would be. So the doc rebuilt below simply does not carry
- * `gatedNoticeDoc`, and the job is dropped. What does cross over is the half
- * that needs no forge API: a `push` job still runs with `--gated-exit 0`, so a
- * Forgejo apply that stops at its gate is a green run rather than a red one,
- * and `chant run` still writes the gate and the approve command to
- * `GITHUB_STEP_SUMMARY`, which Forgejo Actions sets like GitHub does.
- *
- * The gate-notice job's own reason for being — `outputs: { gated, op, gate,
- * approve }` on the Op's job, and the `node -e` step that writes them to
- * `$GITHUB_OUTPUT` — does not survive it either (#2294). Both existed only for
- * that job to read via `needs.<job>.outputs`; with the job gone, so is every
- * reader, and `buildGithubOpPipelineDocs` is asked for neither
- * (`emitGatedOutputs: false` below) rather than emitting them here and
- * stripping them back out. Should the Forgejo posting work in #2291 grow a
- * notice job of its own, this is the one flag that brings both back.
+ * The gated-apply notice job (#2243) crosses over since #3773. It used to
+ * shell to `gh` on GitHub's hosted runner image, which a Forgejo runner
+ * neither ships nor can point at its own instance, so it was dropped here
+ * along with the apply job's `gated`/`op`/`gate`/`approve` outputs that
+ * only it read (#2294). It now runs in the Op's own image and posts through
+ * `@intentius/chant/pr-forge`, whose Forgejo client finds the pull request
+ * a commit merged with `commits/{sha}/pull` and sends `Authorization: token`
+ * itself. So the doc rebuilt below carries `gatedNoticeDoc` through the
+ * same dialect transform as the jobs, which drops its `permissions:` the
+ * way it drops every scope but `id-token`. A `push` job also still runs
+ * with `--gated-exit 0`, and `chant run` still writes the gate and the
+ * approve command to `GITHUB_STEP_SUMMARY`.
  *
  * A spec's own `variables` (#2290) crosses over unchanged: forgejo reuses the
  * same job-level `env:` github's builder emits, and the dialect transform
@@ -186,31 +145,11 @@ export function generateForgejoOpPipeline(
   options: ComponentPipelineOptions = {},
   dialectOptions: ForgejoDialectOptions = {},
 ): OpPipelineResult {
-  // `findingMode: "comment"` used to be refused by name here (#2231); lifted
-  // in #2291 once a real Forgejo instance showed the forge itself was never
-  // the obstacle — see the module doc above.
-
-  // `findingMode: "issue"` is refused by name here (#2315): unlike `comment`,
-  // a real Forgejo instance did not clear it — see the module doc above for
-  // the reproduction.
-  for (const spec of ops) {
-    if (spec.findingMode === "issue") {
-      throw new Error(
-        `Scheduled Op "${spec.name}" has findingMode "issue", which opens or edits a GitHub-shaped issue by ` +
-          `shelling to \`gh\`. Checked against a real Forgejo 12.0.4+gitea-1.22.0 instance (chant #2315): the ` +
-          `search this mode does works there, but the POST/PATCH it writes with does not — \`gh\`'s own ` +
-          `GH_TOKEN/GITHUB_TOKEN only authenticate a request to github.com or a ghe.com subdomain, never a ` +
-          `self-hosted Forgejo, and neither this mode nor its caller sets GH_HOST or GH_ENTERPRISE_TOKEN, so ` +
-          `every write fails with Forgejo's "token is required" (HTTP 401). Use findingMode "comment" on a ` +
-          `pull_request trigger here, or generate this Op for github.`,
-      );
-    }
-  }
+  // `findingMode: "comment"` used to be refused by name here (#2231), and
+  // `findingMode: "issue"` from #2332 to #2351. Neither is now: both post
+  // through the Forgejo client — see the module doc above.
 
-  // `emitGatedOutputs: false` (#2294): forgejo never carries a gate-notice job
-  // (`gatedNoticeDoc` never crosses the dialect, below), so the job outputs
-  // and the `node -e` step that populate them would have no reader.
-  const { files, jobs } = buildGithubOpPipelineDocs(ops, options, { emitGatedOutputs: false });
+  const { files, jobs } = buildGithubOpPipelineDocs(ops, options);
 
   return {
     // One file per spec, in spec order, which is what lets the header below
@@ -227,6 +166,8 @@ export function generateForgejoOpPipeline(
         concurrency: forgejoize(doc.concurrency, dialectOptions),
         permissions: {},
         jobsDoc: forgejoize(withoutEnvironment(doc.jobsDoc), dialectOptions),
+        // The gate-notice job (#3773), dialect applied like the Op's own job.
+        ...(doc.gatedNoticeDoc ? { gatedNoticeDoc: forgejoize(doc.gatedNoticeDoc, dialectOptions) } : {}),
       };
       return { name, yaml: emitOpPipelineYAML(forgejoDoc) };
     }),

package/src/components/generate-op-waves-pipeline.test.ts

@@ -47,4 +47,19 @@ describe("generateForgejoOpWavesPipeline", () => {
     expect(files[1]!.yaml).toContain("pull_request:");
     expect(files[1]!.yaml).toContain("run: chant run wave --spec waves.json --record-plans");
   });
+
+  test("a wave-level plan and apply, and stage hooks, render the same jobs: chant run wave runs them (#3762)", () => {
+    const { plan: _plan, ...rest } = spec;
+    const waveLevel: OpWavesSpec = {
+      ...rest,
+      planWave: ["./bin/plan-wave", "{runs}", "{plans}"],
+      applyWave: ["./bin/apply-wave", "{runs}"],
+      hooks: { before: { apply: [{ command: ["./bin/check", "{runs}"], onFailure: "approve" }] } },
+    };
+    const plain = generateForgejoOpWavesPipeline(spec, { specFile: "waves.json" });
+    const rendered = generateForgejoOpWavesPipeline(waveLevel, { specFile: "waves.json" });
+    expect(rendered.files).toEqual(plain.files);
+    expect(rendered.jobs).toEqual(plain.jobs);
+    expect(() => generateForgejoOpWavesPipeline({ ...waveLevel, hooks: { after: { apply: [{ command: ["./bin/smoke"], onFailure: "approve" }] } } }, { specFile: "waves.json" })).toThrow(/nothing left to hold/);
+  });
 });