fix(cli): bind --tag to tag_name in release create/update dispatcher #34

Open
ses wants to merge 2 commits from fix/release-create-tag-flag into main
Owner

Summary

  • --tag now actually fills tag_name when used on release create /
    release update; the help line was previously a lie because the parser
    wrote to the orphan key tag while the dispatcher read tag_name.
  • Drop the --new-tag alias (same key, now reachable through --tag).
  • Align release update's help line and its "at least one of" error
    message with the unified flag.

Why

Bug report: forgejoctl release create --tag vX.Y.Z ... exited 1 with
"error: --tag is required for release create" despite the user having
supplied exactly that flag. Workaround --new-tag worked.

The fix is one parser key rename plus two help-line touch-ups. The
MCP/OpenCode adapters were unaffected — they take tag_name directly.

Verification

Local only — no live host touch.

bun run typecheck
bun run lint
bun run test   # 620 pass / 0 fail (3 new dispatcher smokes)
bun run build  # CLI, plugin, MCP bundles

The three new tests in src/adapters/cli/main.test.ts (in the existing
describe("CLI release/tag subcommands via main()")) cover:

  1. release create --tag vX.Y.Z posts {tag_name: "vX.Y.Z", …}.
  2. --tag=vX.Y.Z (= form) is accepted.
  3. Missing --tag exits 2 with the documented error and never hits
    fetch.

Pre-fix the first two tests failed with code: 2 (the bug reproduced
through main()). Post-fix all three pass.

Manual live smoke against forge.sebatec.eu is intentionally not
included here — the user's environment policy is "nicht auf Produktion
testen", so any release/tag dance against the real host is for them,
not for CI.

Out of scope

  • Auto-tagging from the default branch (would need a second API call
    to POST /tags); the user's documented flow is
    git push vX.Y.Z && forgejoctl release create --tag vX.Y.Z, which
    the Forgejo server accepts as-is.
  • Idempotency on 409 ("release already exists for tag"); the server
    enforces a unique constraint on LowerTagName and we just propagate
    the 409. Belongs in a separate policy decision.
## Summary - `--tag` now actually fills `tag_name` when used on `release create` / `release update`; the help line was previously a lie because the parser wrote to the orphan key `tag` while the dispatcher read `tag_name`. - Drop the `--new-tag` alias (same key, now reachable through `--tag`). - Align `release update`'s help line and its "at least one of" error message with the unified flag. ## Why Bug report: `forgejoctl release create --tag vX.Y.Z ...` exited 1 with "error: --tag is required for release create" despite the user having supplied exactly that flag. Workaround `--new-tag` worked. The fix is one parser key rename plus two help-line touch-ups. The MCP/OpenCode adapters were unaffected — they take `tag_name` directly. ## Verification Local only — no live host touch. ```sh bun run typecheck bun run lint bun run test # 620 pass / 0 fail (3 new dispatcher smokes) bun run build # CLI, plugin, MCP bundles ``` The three new tests in `src/adapters/cli/main.test.ts` (in the existing `describe("CLI release/tag subcommands via main()")`) cover: 1. `release create --tag vX.Y.Z` posts `{tag_name: "vX.Y.Z", …}`. 2. `--tag=vX.Y.Z` (= form) is accepted. 3. Missing `--tag` exits 2 with the documented error and never hits fetch. Pre-fix the first two tests failed with `code: 2` (the bug reproduced through `main()`). Post-fix all three pass. Manual live smoke against `forge.sebatec.eu` is intentionally **not** included here — the user's environment policy is "nicht auf Produktion testen", so any release/tag dance against the real host is for them, not for CI. ## Out of scope - Auto-tagging from the default branch (would need a second API call to `POST /tags`); the user's documented flow is `git push vX.Y.Z && forgejoctl release create --tag vX.Y.Z`, which the Forgejo server accepts as-is. - Idempotency on 409 ("release already exists for tag"); the server enforces a unique constraint on `LowerTagName` and we just propagate the 409. Belongs in a separate policy decision.
Three cases cover the bug-report path that had no regression test:
  - --tag <v> binds to tag_name and POSTs the release
  - --tag=<v> (= form) is accepted
  - missing --tag returns exit 2 with the documented error

Fails on the unfixed parser (--tag written to flags.tag, but the
release create dispatcher reads flags.tag_name). Passes after the
companion fix in src/adapters/cli/main.ts.
fix(cli): bind --tag to tag_name in release create/update dispatcher
All checks were successful
ci / test (pull_request) Successful in 57s
92c7a13a2c
The --tag parser branch in parseFlags wrote to key 'tag', but the
release create/update dispatchers read flags.tag_name, so --tag was
silently ignored and the 'required' error pointed at a flag the user
had actually supplied. Drop the orphan --new-tag alias and align the
release update help line and missing-fields error with --tag.

Fixes the regression covered by the prior commit (dispatcher smoke).
All checks were successful
ci / test (pull_request) Successful in 57s
Required
Details
This pull request has changes conflicting with the target branch.
  • src/adapters/cli/main.test.ts
  • src/adapters/cli/main.ts
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin fix/release-create-tag-flag:fix/release-create-tag-flag
git switch fix/release-create-tag-flag
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
sebatec-eu/forgejoctl!34
No description provided.