@intentius/chant-lexicon-forgejo 0.64.0 → 0.65.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (6) hide show
  1. package/dist/components/generate-op-pipeline.d.ts +24 -13
  2. package/dist/components/generate-op-pipeline.d.ts.map +1 -1
  3. package/dist/integrity.json +2 -2
  4. package/dist/manifest.json +1 -1
  5. package/package.json +3 -3
  6. package/src/components/generate-op-pipeline.ts +24 -13
package/dist/components/generate-op-pipeline.d.ts CHANGED
@@ -52,28 +52,39 @@
52
52
  * live Forgejo's own OpenAPI spec) returns pull requests interleaved with
53
53
  * issues exactly as GitHub's endpoint does, and the `.pull_request == null`
54
54
  * filter and the marker `startswith` match both behave identically to
55
- * GitHub. The *write* half does not: `postOrUpdateGithubIssue`'s POST and
56
- * PATCH calls carry only `GH_TOKEN` (in fact, on the `issue` path, not even
57
- * that — `reconcilePr` hands it `execAsync` with no `env` override at all,
55
+ * GitHub. The *write* half did not: `postOrUpdateGithubIssue`'s POST and
56
+ * PATCH calls carried only `GH_TOKEN` (in fact, on the `issue` path, not even
57
+ * that — `reconcilePr` handed it `execAsync` with no `env` override at all,
58
58
  * chant #2320), and `gh`'s own documented environment variables (`gh help
59
59
  * environment`) scope `GH_TOKEN`/`GITHUB_TOKEN` to "github.com or a subdomain
60
60
  * of ghe.com" — never a self-hosted Forgejo. A `GH_DEBUG=api` POST against
61
61
  * the live instance, with `GH_TOKEN` and `GITHUB_API_URL` set exactly as the
62
62
  * generated workflow sets them, sent no `Authorization` header at all and
63
63
  * Forgejo answered `{"message":"token is required"}` (HTTP 401); adding
64
- * `GH_HOST` alongside `GH_TOKEN` made no difference. Only `GH_ENTERPRISE_TOKEN`
65
- * paired with a matching `GH_HOST` authenticated the same call. Since neither
66
- * `postOrUpdateGithubIssue` nor its caller sets either, every write this mode
67
- * makes on Forgejo fails — not a slow search, a 401 on every run. The same
68
- * shape (`GH_TOKEN` only, no `GH_HOST`/`GH_ENTERPRISE_TOKEN`) is what
69
- * `postOrUpdateComment`'s writes carry too, which means #2304's "verified
64
+ * `GH_HOST` alongside `GH_TOKEN` made no difference. The same shape was what
65
+ * `postOrUpdateComment`'s writes carried too, which is why #2304's "verified
70
66
  * against a real Forgejo instance" could not have gone through the generated
71
67
  * workflow's own credential path — either that session had a `gh auth login`
72
68
  * already stored for the test instance, which a real Actions job's fresh
73
- * checkout never has, or a different `gh` build was in play. That is
74
- * `comment` mode's problem to re-verify, not `issue` mode's, and out of
75
- * scope for chant #2315; flagged here because finding it is what closes that
76
- * issue's question of whether to lift or reinstate this refusal.
69
+ * checkout never has, or a different `gh` build was in play.
70
+ *
71
+ * Chant #2333 fixed that credential for both modes: `ghCredentialEnv` now
72
+ * forwards the resolved token as `GH_ENTERPRISE_TOKEN` beside `GH_TOKEN`,
73
+ * which is the variable `gh` reads for a host in neither of the two classes
74
+ * above. #2333's own probe against the same image also narrowed the claim
75
+ * made here: `GH_ENTERPRISE_TOKEN` authenticated the identical call *without*
76
+ * a `GH_HOST` beside it, because the full URL #2291 built already names the
77
+ * host. So the premise this refusal was reinstated on no longer holds, and
78
+ * both halves of `postOrUpdateGithubIssue` — the paginated read and the
79
+ * POST/PATCH write — were driven green end to end against a live
80
+ * 12.0.4+gitea-1.22.0 instance under #2333, from a shell with no stored
81
+ * `gh auth login`.
82
+ *
83
+ * The refusal below is nonetheless left standing here, because lifting it is
84
+ * a generator behavior change with its own YAML surface to settle and #2333
85
+ * was scoped to the credential. Lifting it is filed separately; this comment
86
+ * is corrected rather than acted on so the stated reason does not outlive the
87
+ * fact it rested on.
77
88
  *
78
89
  * A spec's `environment` (#2257) is dropped on the same terms as
79
90
  * `permissions:`, and for a stronger reason: Forgejo Actions has no
package/dist/components/generate-op-pipeline.d.ts.map CHANGED
@@ -1 +1 @@
1
- {"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"}
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,CA4ClB"}
package/dist/integrity.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "algorithm": "sha256",
3
3
  "artifacts": {
4
- "manifest.json": "b27a0caa6602113e3055867aa963f678a9711619cf73741170ae05938f562af0",
4
+ "manifest.json": "7c055ebe55f88f4b9c3d2455c54adfd1007d90a7981206a257a67bb483c90d2c",
5
5
  "meta.json": "44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
6
6
  "types/index.d.ts": "66204549b2a864ab5489e3f02c1878e73ab4b3c9d938cfb480b66f71543a43de",
7
7
  "rules/delegate-to-github.ts": "1060cda40f4b73d6cca3ba3fa13b80b4886147d4034c88584c2d80c5510dbe5e",
@@ -9,5 +9,5 @@
9
9
  "rules/wfj011.ts": "fcb8bf6685d744af20ad804ce929488257995c74b9a3353b2eacae3768d1c83e",
10
10
  "skills/chant-forgejo.md": "a1a560429db736c187e0b34cf8dd9efc6ad771afefcbf6f802d160d3d5274257"
11
11
  },
12
- "composite": "a8a40b48d5887134deb8e9feb9ffa1ea5502fd1e4c9ce7462f48d10368e1d881"
12
+ "composite": "384cf230f6d8b9439dd31c9818b6fdaefd1a3c26ea9474fb864931ab3f927f07"
13
13
  }
package/dist/manifest.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "forgejo",
3
- "version": "0.64.0",
3
+ "version": "0.65.0",
4
4
  "chantVersion": ">=0.1.0",
5
5
  "namespace": "Forgejo",
6
6
  "intrinsics": [],
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@intentius/chant-lexicon-forgejo",
3
- "version": "0.64.0",
3
+ "version": "0.65.0",
4
4
  "description": "Forgejo / Codeberg / Gitea Actions lexicon for chant — a thin GitHub Actions dialect",
5
5
  "license": "Apache-2.0",
6
6
  "homepage": "https://intentius.io/chant",
@@ -54,8 +54,8 @@
54
54
  },
55
55
  "peerDependencies": {
56
56
  "zod": "^4.3.6",
57
- "@intentius/chant": "^0.64.0",
58
- "@intentius/chant-lexicon-github": "^0.64.0"
57
+ "@intentius/chant": "^0.65.0",
58
+ "@intentius/chant-lexicon-github": "^0.65.0"
59
59
  },
60
60
  "scripts": {
61
61
  "generate": "tsx src/codegen/generate-cli.ts",
package/src/components/generate-op-pipeline.ts CHANGED
@@ -52,28 +52,39 @@
52
52
  * live Forgejo's own OpenAPI spec) returns pull requests interleaved with
53
53
  * issues exactly as GitHub's endpoint does, and the `.pull_request == null`
54
54
  * filter and the marker `startswith` match both behave identically to
55
- * GitHub. The *write* half does not: `postOrUpdateGithubIssue`'s POST and
56
- * PATCH calls carry only `GH_TOKEN` (in fact, on the `issue` path, not even
57
- * that — `reconcilePr` hands it `execAsync` with no `env` override at all,
55
+ * GitHub. The *write* half did not: `postOrUpdateGithubIssue`'s POST and
56
+ * PATCH calls carried only `GH_TOKEN` (in fact, on the `issue` path, not even
57
+ * that — `reconcilePr` handed it `execAsync` with no `env` override at all,
58
58
  * chant #2320), and `gh`'s own documented environment variables (`gh help
59
59
  * environment`) scope `GH_TOKEN`/`GITHUB_TOKEN` to "github.com or a subdomain
60
60
  * of ghe.com" — never a self-hosted Forgejo. A `GH_DEBUG=api` POST against
61
61
  * the live instance, with `GH_TOKEN` and `GITHUB_API_URL` set exactly as the
62
62
  * generated workflow sets them, sent no `Authorization` header at all and
63
63
  * Forgejo answered `{"message":"token is required"}` (HTTP 401); adding
64
- * `GH_HOST` alongside `GH_TOKEN` made no difference. Only `GH_ENTERPRISE_TOKEN`
65
- * paired with a matching `GH_HOST` authenticated the same call. Since neither
66
- * `postOrUpdateGithubIssue` nor its caller sets either, every write this mode
67
- * makes on Forgejo fails — not a slow search, a 401 on every run. The same
68
- * shape (`GH_TOKEN` only, no `GH_HOST`/`GH_ENTERPRISE_TOKEN`) is what
69
- * `postOrUpdateComment`'s writes carry too, which means #2304's "verified
64
+ * `GH_HOST` alongside `GH_TOKEN` made no difference. The same shape was what
65
+ * `postOrUpdateComment`'s writes carried too, which is why #2304's "verified
70
66
  * against a real Forgejo instance" could not have gone through the generated
71
67
  * workflow's own credential path — either that session had a `gh auth login`
72
68
  * already stored for the test instance, which a real Actions job's fresh
73
- * checkout never has, or a different `gh` build was in play. That is
74
- * `comment` mode's problem to re-verify, not `issue` mode's, and out of
75
- * scope for chant #2315; flagged here because finding it is what closes that
76
- * issue's question of whether to lift or reinstate this refusal.
69
+ * checkout never has, or a different `gh` build was in play.
70
+ *
71
+ * Chant #2333 fixed that credential for both modes: `ghCredentialEnv` now
72
+ * forwards the resolved token as `GH_ENTERPRISE_TOKEN` beside `GH_TOKEN`,
73
+ * which is the variable `gh` reads for a host in neither of the two classes
74
+ * above. #2333's own probe against the same image also narrowed the claim
75
+ * made here: `GH_ENTERPRISE_TOKEN` authenticated the identical call *without*
76
+ * a `GH_HOST` beside it, because the full URL #2291 built already names the
77
+ * host. So the premise this refusal was reinstated on no longer holds, and
78
+ * both halves of `postOrUpdateGithubIssue` — the paginated read and the
79
+ * POST/PATCH write — were driven green end to end against a live
80
+ * 12.0.4+gitea-1.22.0 instance under #2333, from a shell with no stored
81
+ * `gh auth login`.
82
+ *
83
+ * The refusal below is nonetheless left standing here, because lifting it is
84
+ * a generator behavior change with its own YAML surface to settle and #2333
85
+ * was scoped to the credential. Lifting it is filed separately; this comment
86
+ * is corrected rather than acted on so the stated reason does not outlive the
87
+ * fact it rested on.
77
88
  *
78
89
  * A spec's `environment` (#2257) is dropped on the same terms as
79
90
  * `permissions:`, and for a stronger reason: Forgejo Actions has no