Changelog

Manage a project’s Jira versions on the Releases screen, and have each merged change’s fix version suggested, or set.

• Versions. Project admins create a Jira version, give it a release date, and release it. Releasing asks where any unresolved issues move, and never releases a version with open issues silently.
• Fix versions. When a pull request nightlab opened is merged, it suggests the issue’s fix version: the next unreleased version of its Jira project. Keep it, pick another, or decline. A project can turn this off, or choose Automatic, which sets it while writes are on.
• What Jira needs. The screen says when your Jira connection’s account is missing a permission these need, Administer Projects or Edit Issues, and who grants it.

nightlab can tell you which issues it can take, and what the rest are missing.

• Three verdicts. “nightlab can take it”, “Needs something first”, with what’s missing, and “Not for nightlab”, each with its reasons.
• Off until you turn it on, since each triage is a model call. Project admins choose Suggest or Automatic. New issues are triaged as they arrive. The backlog is triaged only when an admin asks, after nightlab shows how many issues and roughly what it costs.
• In the portal. The Issues list has a Triage column, filter and grouping, and a Triage page lists each verdict. Operators can post what’s missing to the issue as one comment; in Automatic, nightlab posts it, while writes are on.

Each draft pull request nightlab opens on GitHub names a person to review it.

• Who. The CODEOWNERS of the changed files first, then whoever most recently changed them. Only people who can push to the repository, never a bot, and not the person who started the run if they’ve added their GitHub username under Your accounts, unless nobody else owns or recently changed those files.
• Where. In the pull request’s description and on the run. In Automatic, nightlab also requests the review on GitHub. GitLab doesn’t have it yet.

Setup is now three sections on one track, Connect, Your defaults and Go live, and no run starts until its four required steps are done.

• Required: connect your code, connect your tracker, add a project, and choose how runs are paid for and approved.
• Defaults to confirm: where models process data, and the monthly limit, come filled in for you to check.
• Optional, with Skip: a model for each action, notifications, inviting people, and a dry run before turning writes on.

Settings now names where each model processes your data: a country, an area such as the EU, Global, or Unknown.

• Each model and each action shows its place, as in “Opus 5.5, Australia”, and a refusal says where a model would have processed the data.
• With your own OpenAI key or endpoint, nightlab can’t tell where it processes, so it says Unknown.