@bakers-build/addon-deployment 0.0.0-stage → 0.1.0-next.38

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 keytec GmbH
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,3 +1,5 @@
-# Temporary Holding Version
+# @bakers-build/addon-deployment
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+bakers.build deployment command plugin: `bakers deployment tickets` — the release batch computed from a git-log range.
+
+Part of the bakers.build CLI. Install the meta package `@bakers-build/bakers` to get the `bakers` CLI with all addons. Source: https://git.key-tec.de/bakers-build/bakers-build (bakers-cli/).

package/dist/src/deployment.d.ts

@@ -0,0 +1,51 @@
+import type { BbRemote } from '@bakers-build/conductor/contract';
+import type { Command } from 'commander';
+export interface GatherResult {
+    range: string;
+    resolved: Array<{
+        identifier: string;
+        uuid: string;
+        title: string;
+    }>;
+    unresolved: string[];
+}
+/**
+ * Deduped ticket identifiers from a git log, in first-seen order — for any
+ * project key, not just `bakers.build` (BB-392 AC-2).
+ *
+ * The parse admits *keys*, not tokens, in two passes: a key is admitted where
+ * it stands in one of the anchored positions above, and every identifier whose
+ * key was admitted is then collected — anchored or bare.
+ *
+ * The second pass is not optional: of the last 300 commits on `develop` only
+ * two carry a `ref:` trailer, the rest name the ticket in the subject, and a
+ * bare `BB-135` in a body is a real reference. What the rule gives up is one
+ * residual case — a delta in which a key appears *only* in bare mid-prose form,
+ * anchored nowhere, yields nothing for that key. That is the deliberate trade:
+ * such a token is indistinguishable from `AC-1` without hardcoding a project
+ * key, which is the defect this replaces. The cheap direction is the other one,
+ * a wrongly admitted key, because it surfaces in `unresolved` rather than as a
+ * wrong ticket.
+ */
+export declare function parseIdentifiers(gitLog: string): string[];
+/**
+ * Compute the release batch from a git-log delta: parse ticket identifiers and
+ * resolve each to a ticket. Unresolved identifiers are reported, never fatal
+ * (the resolver returning null is not an error) — BB-153 AC-2.
+ */
+export declare function gatherBatch(opts: {
+    sinceRef: string;
+    toRef: string;
+    gitLog: string;
+    resolve: (id: string) => Promise<{
+        uuid: string;
+        title: string;
+    } | null>;
+}): Promise<GatherResult>;
+/**
+ * Register the `bakers deployment` command group. `tickets` computes the release's
+ * tickets (git-log identifier parse + resolve over the given range) and prints
+ * them as JSON — pure compute + report, it does not write `referenced_tickets`
+ * (the prepare-deployment skill does, via the documented dropsh path).
+ */
+export declare function registerDeployment(program: Command, resolveRemote: () => Promise<BbRemote>, resolveProject: () => Promise<string>, cwd: () => string): void;

package/dist/src/deployment.js

@@ -0,0 +1,124 @@
+import { exec } from '@bakers-build/core';
+/**
+ * An identifier's shape: a project key plus its number. A key is validated as
+ * `/^[A-Z][A-Z0-9]{1,9}$/` and never contains a hyphen (`BbProject`), so this
+ * is the whole grammar — and it is also the shape of prose like `AC-1`,
+ * `UTF-8` or `SHA-256`, which is why matching it alone is not enough.
+ */
+const IDENTIFIER = '[A-Z][A-Z0-9]{1,9}-\\d+';
+/**
+ * What may precede a subject: the `%x1e` record separator and the abbreviated
+ * or full commit hash that `bakers deployment tickets` asks `git log` to print in
+ * front of `%s`. Both optional, so a bare subject line anchors too.
+ */
+const SUBJECT_HEAD = '^\\x1e?(?:[0-9a-f]{2,40} )?';
+/**
+ * The three positions in which an identifier can only be a ticket reference,
+ * and which therefore admit its project key:
+ *
+ * 1. the `ref:` trailer the commit convention prescribes — `ref:SHOP-42`;
+ * 2. a conventional-commit scope — `feat(BB-134): …`;
+ * 3. the head of a subject line — `BB-375: …`, the legacy form 298 of the
+ *    last 300 commits on `develop` use.
+ *
+ * Positions 2 and 3 are deliberately anchored to the head of a line rather than
+ * to "any token before a colon" or "any parenthesised token": a body bullet
+ * `- AC-2: …` and a body line `(AC-5): parent = …` are exactly those two
+ * shapes, and both occur in this repository's real history. Admitting `AC` from
+ * them puts six phantom identifiers into a 300-commit release batch.
+ */
+const ANCHORED = new RegExp([
+    `ref:[ \\t]*(${IDENTIFIER})\\b`,
+    `${SUBJECT_HEAD}[a-z]+!?\\((${IDENTIFIER})\\):`,
+    `${SUBJECT_HEAD}(${IDENTIFIER}):`,
+].join('|'), 'gm');
+/**
+ * Deduped ticket identifiers from a git log, in first-seen order — for any
+ * project key, not just `bakers.build` (BB-392 AC-2).
+ *
+ * The parse admits *keys*, not tokens, in two passes: a key is admitted where
+ * it stands in one of the anchored positions above, and every identifier whose
+ * key was admitted is then collected — anchored or bare.
+ *
+ * The second pass is not optional: of the last 300 commits on `develop` only
+ * two carry a `ref:` trailer, the rest name the ticket in the subject, and a
+ * bare `BB-135` in a body is a real reference. What the rule gives up is one
+ * residual case — a delta in which a key appears *only* in bare mid-prose form,
+ * anchored nowhere, yields nothing for that key. That is the deliberate trade:
+ * such a token is indistinguishable from `AC-1` without hardcoding a project
+ * key, which is the defect this replaces. The cheap direction is the other one,
+ * a wrongly admitted key, because it surfaces in `unresolved` rather than as a
+ * wrong ticket.
+ */
+export function parseIdentifiers(gitLog) {
+    const admitted = new Set();
+    for (const [, trailer, scope, subject] of gitLog.matchAll(ANCHORED)) {
+        const identifier = trailer ?? scope ?? subject;
+        if (identifier !== undefined) {
+            admitted.add(keyOf(identifier));
+        }
+    }
+    const seen = new Set();
+    const out = [];
+    for (const [identifier] of gitLog.matchAll(new RegExp(`\\b${IDENTIFIER}\\b`, 'g'))) {
+        if (admitted.has(keyOf(identifier)) && !seen.has(identifier)) {
+            seen.add(identifier);
+            out.push(identifier);
+        }
+    }
+    return out;
+}
+/** An identifier's project key — everything left of its `-<number>`. */
+function keyOf(identifier) {
+    return identifier.slice(0, identifier.indexOf('-'));
+}
+/**
+ * Compute the release batch from a git-log delta: parse ticket identifiers and
+ * resolve each to a ticket. Unresolved identifiers are reported, never fatal
+ * (the resolver returning null is not an error) — BB-153 AC-2.
+ */
+export async function gatherBatch(opts) {
+    const resolved = [];
+    const unresolved = [];
+    for (const identifier of parseIdentifiers(opts.gitLog)) {
+        const hit = await opts.resolve(identifier);
+        if (hit) {
+            resolved.push({ identifier, ...hit });
+        }
+        else {
+            unresolved.push(identifier);
+        }
+    }
+    return { range: `${opts.sinceRef}..${opts.toRef}`, resolved, unresolved };
+}
+/**
+ * Register the `bakers deployment` command group. `tickets` computes the release's
+ * tickets (git-log identifier parse + resolve over the given range) and prints
+ * them as JSON — pure compute + report, it does not write `referenced_tickets`
+ * (the prepare-deployment skill does, via the documented dropsh path).
+ */
+export function registerDeployment(program, resolveRemote, resolveProject, cwd) {
+    const dep = program
+        .command('deployment')
+        .description('release / deployment helpers');
+    dep
+        .command('tickets')
+        .description("the release's tickets (git-log identifier parse + resolve over a range) as JSON")
+        .requiredOption('--since <ref>', "the env's currently-deployed ref (git range start)")
+        .requiredOption('--to <ref>', 'the post-merge env branch tip (git range end)')
+        .action(async (opts) => {
+        // Prefix each commit with a record separator (%x1e) so one commit's body
+        // cannot run into the next commit's header line; the identifier parse is
+        // separator-agnostic, but the boundary keeps the log unambiguous.
+        const gitLog = await exec('git', ['log', '--format=%x1e%H %s%n%b', `${opts.since}..${opts.to}`], { cwd: cwd() });
+        const remote = await resolveRemote();
+        const project = await resolveProject();
+        const result = await gatherBatch({
+            sinceRef: opts.since,
+            toRef: opts.to,
+            gitLog,
+            resolve: (id) => remote.resolveTicketByIdentifier(project, id),
+        });
+        console.log(JSON.stringify(result));
+    });
+}

package/dist/src/index.d.ts

@@ -0,0 +1,5 @@
+import { type BbCommandPlugin } from '@bakers-build/core';
+/** The `deployment` command plugin the host mounts (`bakers deployment …`). */
+declare const deploymentCommandPlugin: BbCommandPlugin;
+export default deploymentCommandPlugin;
+export { type GatherResult, gatherBatch, parseIdentifiers, registerDeployment, } from './deployment.js';

package/dist/src/index.js

@@ -0,0 +1,34 @@
+import { composeConductorConfig, loadConductorConfig, selectRemote, } from '@bakers-build/conductor';
+import { loadBbConfig, resolveConfigPath, } from '@bakers-build/core';
+import { registerDeployment } from './deployment.js';
+// BB-224 (Finding 7): `deployment` is its own COMMAND-surface addon, no longer
+// a side-registration of the `conductor` command plugin. The release-batch
+// gathering (`src/deployment.ts`) was already fully dependency-inverted — it
+// takes the remote, the project and the cwd as thunks — so this module only has
+// to reproduce the thunks the conductor command plugin used to pass, over the
+// same split-config resolution:
+//   engine half     `conductor.config.js` via `loadConductorConfig`
+//   connection half `bakers.config.js`      via `loadBbConfig`
+// composed by `composeConductorConfig`, with the remote picked by `selectRemote`.
+//
+// The `@bakers-build/conductor` import is the package MAIN (engine + config loader),
+// not the runtime-light `./contract` subpath — that cost is paid only when a
+// `bakers deployment …` subcommand actually dispatches, because the host mounts
+// this module lazily (the `./preset` accumulator is what `bakers --help` reads).
+/** Resolve + compose the full conductor config (engine + connection halves). */
+async function resolveConfig(host) {
+    const engine = await loadConductorConfig(resolveConfigPath());
+    const connection = await loadBbConfig(host, {});
+    return composeConductorConfig(engine, connection);
+}
+/** The `deployment` command plugin the host mounts (`bakers deployment …`). */
+const deploymentCommandPlugin = {
+    kind: 'command',
+    name: 'deployment',
+    describe: 'release / deployment helpers',
+    register(program, host) {
+        registerDeployment(program, async () => selectRemote(await resolveConfig(host)), async () => (await resolveConfig(host)).project, () => process.cwd());
+    },
+};
+export default deploymentCommandPlugin;
+export { gatherBatch, parseIdentifiers, registerDeployment, } from './deployment.js';

package/dist/src/preset.d.ts

@@ -0,0 +1,2 @@
+import type { BbPreset } from '@bakers-build/core';
+export declare const commands: BbPreset['commands'];

package/dist/src/preset.js

@@ -0,0 +1,8 @@
+export const commands = (acc) => [
+    ...acc,
+    {
+        name: 'deployment',
+        plugin: '@bakers-build/addon-deployment',
+        describe: 'release / deployment helpers',
+    },
+];

package/package.json

@@ -1,6 +1,29 @@
 {
   "name": "@bakers-build/addon-deployment",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.1.0-next.38",
+  "description": "bakers.build deployment command plugin: `bakers deployment tickets` — the release batch computed from a git-log range.",
+  "type": "module",
+  "license": "MIT",
+  "exports": {
+    ".": "./dist/src/index.js",
+    "./preset": "./dist/src/preset.js"
+  },
+  "files": [
+    "dist/src"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://git.key-tec.de/bakers-build/bakers-build.git",
+    "directory": "bakers-cli/addons/deployment"
+  },
+  "dependencies": {
+    "commander": "^12.1.0"
+  },
+  "peerDependencies": {
+    "@bakers-build/conductor": "^0.1.0-next.38",
+    "@bakers-build/core": "^0.1.0-next.38"
+  }
+}