Skip to content

v0.38.0 — Jira Cloud, validated as a user would

Choose a tag to compare

@keparlak keparlak released this 05 Sep 23:20
· 19 commits to main since this release
61b107b

Baron now speaks Jira — and this release was run the way a user would run it before it shipped.

Jira Cloud

npx @lonca/baron-cli@latest init --provider jira. Issues on Jira, branches and pull requests on
GitHub, one contract. Jira is the provider the role contract was hardest to fit, and the reason it
now fits: a status cannot be set on Jira. The workflow permits some transitions from the issue's
current status, and a transition may carry a screen that demands fields. The adapter reads both
from Jira's transitions endpoint, and the core verifies against them before writing
TRANSITION_NOT_PERMITTED names what the workflow would accept, TRANSITION_FIELDS_REQUIRED names
every field a screen wants, and the caller passes them back as fields.

Roles key on the status name, so a confirmed policy.json reads "In Review" rather than an
id. Jira's three categories (To Do / In Progress / Done) cannot tell in_review from
in_progress, so baron init proposes from names and you confirm. Sprints are declared
unsupported for now (they live on the Jira Software agile API); the gap policy decides. The
setup walkthrough is transcribed
from a real run.

Found by running it as a user

Before publishing, the whole path was driven from a publish-equivalent tree on a fresh project —
init, doctor, every task-* recipe with Jira issues and a private GitHub repository, the MCP
server over JSON-RPC, a headless Claude Code session using the plugin skills, and the Docker image.
It found four things the test suites could not, all fixed here:

  • task-land no longer dies on a private repository with a fine-grained token. The check-runs
    403 had been translated into a CredentialPermissionError before the fallback to Actions runs
    and commit statuses could see it, so the fallback never ran. Public repositories hid this: their
    check runs are readable without any permission. It now warns with the exact remedy and lands.
  • task-sync-report reports "merged but still in review". Jira does not close an item when its
    PR merges, so that is the ordinary aftermath of every land there — and the sweep was silent about
    it. A third drift class, auto-fixable with task-move to done.
  • The proposal reads Jira correctly. Its unordered statuses handed in_progress the review
    state, and a "Subtask" listed before "Task" took the task role. Fixed in the core, with the real
    site's introspection as the regression test.
  • A wrong JIRA_SITE is refused by name, with the shape it wants, instead of a raw fetch error.
    A host without a scheme is accepted.

Also: baron_native_request works on Jira, and the transition tool no longer promises that stray
fields are ignored — Jira refuses a field its screen does not carry, and that refusal is right.

For contributors

Under pnpm 11, pnpm deploy rewrites the workspace manifests in place; RELEASING.md says to deploy
from a throwaway copy, and how the user-journey pass is repeated.