@intentius/chant-lexicon-forgejo 0.62.0 → 0.64.0

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

@@ -28,7 +28,7 @@
  * no mapping in ../actions.ts passes through verbatim and resolves only if
  * the runner can fetch it.
  *
- * `comment` (#2231) crosses over too, since chant #2291: it posts onto the
+ * `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
@@ -38,10 +38,42 @@
  * 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. `issue` mode (`gh issue create`) was not part of that
- * verification — only the comment endpoints were exercised on the real
- * instance — so it remains un-refused-but-unverified here, exactly as it was
- * on GitHub before this change.
+ * for the fix.
+ *
+ * `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 does not: `postOrUpdateGithubIssue`'s POST and
+ * PATCH calls carry only `GH_TOKEN` (in fact, on the `issue` path, not even
+ * that — `reconcilePr` hands 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. Only `GH_ENTERPRISE_TOKEN`
+ * paired with a matching `GH_HOST` authenticated the same call. Since neither
+ * `postOrUpdateGithubIssue` nor its caller sets either, every write this mode
+ * makes on Forgejo fails — not a slow search, a 401 on every run. The same
+ * shape (`GH_TOKEN` only, no `GH_HOST`/`GH_ENTERPRISE_TOKEN`) is what
+ * `postOrUpdateComment`'s writes carry too, which means #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. That is
+ * `comment` mode's problem to re-verify, not `issue` mode's, and out of
+ * scope for chant #2315; flagged here because finding it is what closes that
+ * issue's question of whether to lift or reinstate this refusal.
  *
  * A spec's `environment` (#2257) is dropped on the same terms as
  * `permissions:`, and for a stronger reason: Forgejo Actions has no

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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoFG;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,CA2BlB"}
+{"version":3,"file":"generate-op-pipeline.d.ts","sourceRoot":"","sources":["../../src/components/generate-op-pipeline.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoHG;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,CA4ClB"}

package/dist/integrity.json

@@ -1,7 +1,7 @@
 {
   "algorithm": "sha256",
   "artifacts": {
-    "manifest.json": "3f69907e1588ef81d9bbf78e57ba60a06e4657ad54692aad9cc172ac21246ce6",
+    "manifest.json": "b27a0caa6602113e3055867aa963f678a9711619cf73741170ae05938f562af0",
     "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": "a1a560429db736c187e0b34cf8dd9efc6ad771afefcbf6f802d160d3d5274257"
   },
-  "composite": "c1b979e353a7bd9fbc449e1f98b765979d89d4e386ed94d8fce9ec20754ee514"
+  "composite": "a8a40b48d5887134deb8e9feb9ffa1ea5502fd1e4c9ce7462f48d10368e1d881"
 }

package/dist/manifest.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@intentius/chant-lexicon-forgejo",
-  "version": "0.62.0",
+  "version": "0.64.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.62.0",
-    "@intentius/chant-lexicon-github": "^0.62.0"
+    "@intentius/chant": "^0.64.0",
+    "@intentius/chant-lexicon-github": "^0.64.0"
   },
   "scripts": {
     "generate": "tsx src/codegen/generate-cli.ts",

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

@@ -33,7 +33,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: "issue" },
+      { name: "prod-reconcile", schedule: "0 * * * *", findingMode: "pull-request" },
     ];
     const result = generateForgejoOpPipeline(specs);
 
@@ -78,7 +78,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: "issue" },
+      { name: "tf-plan", trigger: { kind: "pull_request", branches: ["main"] }, findingMode: "pull-request" },
     ];
     const fj = generateForgejoOpPipeline(specs);
     const gh = generateGithubOpPipeline(specs);
@@ -149,6 +149,35 @@ 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", () => {
+    const specs: ScheduledOpSpec[] = [{ name: "prod-watch", schedule: "0 6 * * *", findingMode: "issue" }];
+    expect(() => generateGithubOpPipeline(specs)).not.toThrow();
+  });
+
+  test("a pull_request-triggered Op is refused the same way — issue mode needs no trigger to fail on", () => {
+    const specs: ScheduledOpSpec[] = [
+      { name: "tf-plan", trigger: { kind: "pull_request", branches: ["main"] }, findingMode: "issue" },
+    ];
+    expect(() => generateForgejoOpPipeline(specs)).toThrow(/findingMode "issue"/);
+  });
+});
+
 /**
  * #2242 crosses the dialect asymmetrically: Forgejo runs `uses:` steps, so a
  * spec's `setup` list is emitted; it ignores `permissions:`, so an additive
@@ -225,16 +254,34 @@ describe("generateForgejoOpPipeline: the gated apply on push (#2243)", () => {
    * always carries, unconditionally) defaults to `sh`, and `sh` rejects `set
    * -o pipefail`. This generator reuses github's `buildGithubOpPipelineDocs`
    * to build the job, then the dialect transform in ../dialect.ts to cross
-   * it, so the fix has to survive both: neither step drops or renames
-   * `shell:`.
+   * it, so the fix has to survive both: the exit-code capture is plain POSIX
+   * `sh` (chant #2321 — no `shell: bash` to drop or rename in the first
+   * place, unlike before #2321, when an unconditional `shell: bash` broke
+   * any consumer image without bash — see the sibling test below).
    */
-  test("the pipefail step keeps shell: bash across the Forgejo dialect — its job runs in a container, whose default shell is sh", () => {
+  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");
     const step = job.steps.find((s) => s.id === "chant-run");
-    expect(step?.run).toContain("set -o pipefail");
-    expect(step?.shell).toBe("bash");
+    expect(step?.shell).toBeUndefined();
+    expect(step?.run).not.toContain("pipefail");
+    expect(step?.run).toContain('[ "$code" -eq 0 ] || exit "$code"');
+  });
+
+  /**
+   * chant #2321 — same regression as the github generator's, since this one
+   * reuses `buildGithubOpPipelineDocs` to build the job before crossing the
+   * dialect: a consumer's non-bash `options.image` (alpine, distroless, …)
+   * must not get an unconditional `shell: bash` it cannot run.
+   */
+  test("a consumer-set non-bash image's gated job can still start on Forgejo (#2321)", () => {
+    const doc = parseFile(generateForgejoOpPipeline([pushSpec], { image: "alpine:3.20" }).files[0].yaml);
+    const job = doc.jobs!["app-apply"];
+    expect(job.container).toBe("alpine:3.20");
+    const step = job.steps.find((s) => s.id === "chant-run");
+    expect(step?.shell).toBeUndefined();
+    expect(step?.run).not.toContain("pipefail");
   });
 });
 
@@ -277,7 +324,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: "issue" },
+      { name: "actions-audit", schedule: "0 6 * * *", findingMode: "pull-request" },
     ]).files[0].yaml;
     expect(yaml).toBe(AUDIT_YAML_BEFORE_2257);
   });

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

@@ -28,7 +28,7 @@
  * no mapping in ../actions.ts passes through verbatim and resolves only if
  * the runner can fetch it.
  *
- * `comment` (#2231) crosses over too, since chant #2291: it posts onto the
+ * `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
@@ -38,10 +38,42 @@
  * 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. `issue` mode (`gh issue create`) was not part of that
- * verification — only the comment endpoints were exercised on the real
- * instance — so it remains un-refused-but-unverified here, exactly as it was
- * on GitHub before this change.
+ * for the fix.
+ *
+ * `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 does not: `postOrUpdateGithubIssue`'s POST and
+ * PATCH calls carry only `GH_TOKEN` (in fact, on the `issue` path, not even
+ * that — `reconcilePr` hands 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. Only `GH_ENTERPRISE_TOKEN`
+ * paired with a matching `GH_HOST` authenticated the same call. Since neither
+ * `postOrUpdateGithubIssue` nor its caller sets either, every write this mode
+ * makes on Forgejo fails — not a slow search, a 401 on every run. The same
+ * shape (`GH_TOKEN` only, no `GH_HOST`/`GH_ENTERPRISE_TOKEN`) is what
+ * `postOrUpdateComment`'s writes carry too, which means #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. That is
+ * `comment` mode's problem to re-verify, not `issue` mode's, and out of
+ * scope for chant #2315; flagged here because finding it is what closes that
+ * issue's question of whether to lift or reinstate this refusal.
  *
  * A spec's `environment` (#2257) is dropped on the same terms as
  * `permissions:`, and for a stronger reason: Forgejo Actions has no
@@ -147,6 +179,23 @@ export function generateForgejoOpPipeline(
   // 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.`,
+      );
+    }
+  }
+
   // `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.