@invarn/cibuild 2.6.9 → 2.7.1

package/dist/src/commands/ios-scanner.d.ts

@@ -44,18 +44,54 @@ export interface IosScanResult {
  *
  *  1. named after the project or workspace — the commonest case, and
  *     unambiguous;
- *  2. launches the product named after the project, and is not named like a
- *     companion. `thebaselab/codeapp` is why this outranks the next one: its
- *     `Code App` scheme launches `Code.app` and declares no tests at all,
- *     while `Code UI` has two test bundles and launches `CodeUI.app`;
- *  3. launches an `.app`, declares tests (the template runs them), and is not
- *     named like a companion; among several, the iOS or Debug one, then the
- *     shortest;
- *  4. launches an `.app` and is not named like a companion;
+ *  2. launches the product named after the project, and is not a companion.
+ *     `thebaselab/codeapp` is why this outranks the next one: its `Code App`
+ *     scheme launches `Code.app` and declares no tests at all, while `Code UI`
+ *     has two test bundles and launches `CodeUI.app`;
+ *  3. launches an `.app`, declares tests (the template runs them), and is not a
+ *     companion; among several, the iOS or Debug one, then the shortest;
+ *  4. launches an `.app` and is not a companion;
  *  5. whatever order it came in.
  *
  * Every scheme stays in the list — this reorders, it does not filter, so a
  * caller wanting the extension can still find it.
+ *
+ * **What "companion" has to mean, and why a name is not enough.**
+ * `mozilla-mobile/firefox-ios` broke tiers 1-4 without touching the directory
+ * order this function was written for. Its project is `Client.xcodeproj`, so
+ * `projectName` is `Client`. An app extension is launched *through its host
+ * app*, so the `Today` widget scheme's LaunchAction runnable is `Client.app` —
+ * identical to `Fennec`'s. Both landed in tier 1, neither name carries an `iOS`
+ * or `Debug` token, and the tie fell to name length:
+ *
+ *     "Today"  -> 5 characters      <- won
+ *     "Fennec" -> 6 characters
+ *
+ * The build then failed compiling `ActionExtension` rather than the browser
+ * (`bld_b1b38dda58f4111080415283`).
+ *
+ * Launching the app binary is therefore not sufficient, and the answer is not a
+ * longer name blocklist either — `Today` names nothing. Xcode states the fact
+ * outright: it writes `wasCreatedForAppExtension = "YES"` onto the `<Scheme>`
+ * element of a scheme it created for an extension target, so that is what is
+ * read.
+ *
+ * Measured over all 125 shared schemes in the thirty-app study's clones: 29
+ * carry the attribute, and **all 29 are extension schemes** — no false
+ * positive. It is also the only signal that would have worked. Two that were
+ * considered and are wrong on this same evidence:
+ *
+ *  - *require an `.app` among the BuildAction entries.* 27 of the 29 extension
+ *    schemes build the host app too — `Today` builds
+ *    `["Today.appex", "Client.app"]` — so this demotes 2 of 29 and leaves
+ *    firefox-ios picking `Today`.
+ *  - *demote anything building an `.appex`.* `chenqi92/primuse`'s `Primuse`
+ *    scheme is the real app scheme and builds two widget extensions alongside
+ *    `Primuse.app`.
+ *
+ * The attribute is a sufficient signal, not a necessary one: a hand-written or
+ * pre-Xcode-10 scheme may omit it, and its absence changes nothing, so nothing
+ * that ranked before can regress on a scheme that does not carry it.
  */
 export declare function rankSchemes(root: string, projectPath: string, schemes: string[]): string[];
 /** The ranking, plus the sentence explaining its first entry. */

package/dist/src/commands/ios-scanner.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"ios-scanner.d.ts","sourceRoot":"","sources":["../../../src/commands/ios-scanner.ts"],"names":[],"mappings":"AAGA,MAAM,MAAM,kBAAkB,GAAG,cAAc,GAAG,SAAS,GAAG,gBAAgB,GAAG,WAAW,CAAC;AAE7F,MAAM,MAAM,kBAAkB,GAAG,SAAS,GAAG,MAAM,CAAC;AAEpD,MAAM,WAAW,UAAU;IACzB,QAAQ,EAAE,kBAAkB,CAAC;IAC7B,QAAQ,EAAE,kBAAkB,CAAC;IAC7B,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,aAAa;IAC5B,QAAQ,EAAE,UAAU,EAAE,CAAC;IACvB;;;OAGG;IACH,eAAe,EAAE,MAAM,EAAE,CAAC;IAC1B,uEAAuE;IACvE,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,oDAAoD;IACpD,YAAY,EAAE,OAAO,CAAC;IACtB,0DAA0D;IAC1D,MAAM,EAAE,OAAO,CAAC;IAChB,+DAA+D;IAC/D,WAAW,EAAE,MAAM,CAAC;IACpB,6DAA6D;IAC7D,gBAAgB,EAAE,OAAO,CAAC;IAC1B,iFAAiF;IACjF,eAAe,EAAE,MAAM,CAAC;CACzB;AA8ED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,wBAAgB,WAAW,CACzB,IAAI,EAAE,MAAM,EACZ,WAAW,EAAE,MAAM,EACnB,OAAO,EAAE,MAAM,EAAE,GAChB,MAAM,EAAE,CAEV;AAED,iEAAiE;AACjE,wBAAgB,qBAAqB,CACnC,IAAI,EAAE,MAAM,EACZ,WAAW,EAAE,MAAM,EACnB,OAAO,EAAE,MAAM,EAAE,GAChB;IAAE,OAAO,EAAE,MAAM,EAAE,CAAC;IAAC,MAAM,CAAC,EAAE,MAAM,CAAA;CAAE,CA4CxC;AAmLD,wBAAsB,cAAc,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,aAAa,CAAC,CAgGhF;AAaD,wBAAgB,mBAAmB,CAAC,MAAM,EAAE,aAAa,GAAG,MAAM,CAkDjE"}
+{"version":3,"file":"ios-scanner.d.ts","sourceRoot":"","sources":["../../../src/commands/ios-scanner.ts"],"names":[],"mappings":"AAGA,MAAM,MAAM,kBAAkB,GAAG,cAAc,GAAG,SAAS,GAAG,gBAAgB,GAAG,WAAW,CAAC;AAE7F,MAAM,MAAM,kBAAkB,GAAG,SAAS,GAAG,MAAM,CAAC;AAEpD,MAAM,WAAW,UAAU;IACzB,QAAQ,EAAE,kBAAkB,CAAC;IAC7B,QAAQ,EAAE,kBAAkB,CAAC;IAC7B,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,aAAa;IAC5B,QAAQ,EAAE,UAAU,EAAE,CAAC;IACvB;;;OAGG;IACH,eAAe,EAAE,MAAM,EAAE,CAAC;IAC1B,uEAAuE;IACvE,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,oDAAoD;IACpD,YAAY,EAAE,OAAO,CAAC;IACtB,0DAA0D;IAC1D,MAAM,EAAE,OAAO,CAAC;IAChB,+DAA+D;IAC/D,WAAW,EAAE,MAAM,CAAC;IACpB,6DAA6D;IAC7D,gBAAgB,EAAE,OAAO,CAAC;IAC1B,iFAAiF;IACjF,eAAe,EAAE,MAAM,CAAC;CACzB;AAuFD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiEG;AACH,wBAAgB,WAAW,CACzB,IAAI,EAAE,MAAM,EACZ,WAAW,EAAE,MAAM,EACnB,OAAO,EAAE,MAAM,EAAE,GAChB,MAAM,EAAE,CAEV;AAED,iEAAiE;AACjE,wBAAgB,qBAAqB,CACnC,IAAI,EAAE,MAAM,EACZ,WAAW,EAAE,MAAM,EACnB,OAAO,EAAE,MAAM,EAAE,GAChB;IAAE,OAAO,EAAE,MAAM,EAAE,CAAC;IAAC,MAAM,CAAC,EAAE,MAAM,CAAA;CAAE,CA8CxC;AAmLD,wBAAsB,cAAc,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,aAAa,CAAC,CAgGhF;AAaD,wBAAgB,mBAAmB,CAAC,MAAM,EAAE,aAAa,GAAG,MAAM,CAkDjE"}

package/dist/src/commands/ios-scanner.js

@@ -60,9 +60,13 @@ function readSchemeFacts(root, name) {
         if (!xml)
             continue;
         const launch = /<LaunchAction[\s\S]*?<\/LaunchAction>/.exec(xml)?.[0] ?? "";
+        // Attribute values carry no `>`, so the opening tag alone is a safe scope
+        // and no attribute deeper in the document can be mistaken for it.
+        const schemeTag = /<Scheme\b[^>]*>/.exec(xml)?.[0] ?? "";
         return {
             runnable: /BuildableName\s*=\s*"([^"]+)"/.exec(launch)?.[1],
             testable: /<TestableReference/.test(xml),
+            appExtension: /wasCreatedForAppExtension\s*=\s*"YES"/.test(schemeTag),
         };
     }
     return undefined;
@@ -84,18 +88,54 @@ function readSchemeFacts(root, name) {
  *
  *  1. named after the project or workspace — the commonest case, and
  *     unambiguous;
- *  2. launches the product named after the project, and is not named like a
- *     companion. `thebaselab/codeapp` is why this outranks the next one: its
- *     `Code App` scheme launches `Code.app` and declares no tests at all,
- *     while `Code UI` has two test bundles and launches `CodeUI.app`;
- *  3. launches an `.app`, declares tests (the template runs them), and is not
- *     named like a companion; among several, the iOS or Debug one, then the
- *     shortest;
- *  4. launches an `.app` and is not named like a companion;
+ *  2. launches the product named after the project, and is not a companion.
+ *     `thebaselab/codeapp` is why this outranks the next one: its `Code App`
+ *     scheme launches `Code.app` and declares no tests at all, while `Code UI`
+ *     has two test bundles and launches `CodeUI.app`;
+ *  3. launches an `.app`, declares tests (the template runs them), and is not a
+ *     companion; among several, the iOS or Debug one, then the shortest;
+ *  4. launches an `.app` and is not a companion;
  *  5. whatever order it came in.
  *
  * Every scheme stays in the list — this reorders, it does not filter, so a
  * caller wanting the extension can still find it.
+ *
+ * **What "companion" has to mean, and why a name is not enough.**
+ * `mozilla-mobile/firefox-ios` broke tiers 1-4 without touching the directory
+ * order this function was written for. Its project is `Client.xcodeproj`, so
+ * `projectName` is `Client`. An app extension is launched *through its host
+ * app*, so the `Today` widget scheme's LaunchAction runnable is `Client.app` —
+ * identical to `Fennec`'s. Both landed in tier 1, neither name carries an `iOS`
+ * or `Debug` token, and the tie fell to name length:
+ *
+ *     "Today"  -> 5 characters      <- won
+ *     "Fennec" -> 6 characters
+ *
+ * The build then failed compiling `ActionExtension` rather than the browser
+ * (`bld_b1b38dda58f4111080415283`).
+ *
+ * Launching the app binary is therefore not sufficient, and the answer is not a
+ * longer name blocklist either — `Today` names nothing. Xcode states the fact
+ * outright: it writes `wasCreatedForAppExtension = "YES"` onto the `<Scheme>`
+ * element of a scheme it created for an extension target, so that is what is
+ * read.
+ *
+ * Measured over all 125 shared schemes in the thirty-app study's clones: 29
+ * carry the attribute, and **all 29 are extension schemes** — no false
+ * positive. It is also the only signal that would have worked. Two that were
+ * considered and are wrong on this same evidence:
+ *
+ *  - *require an `.app` among the BuildAction entries.* 27 of the 29 extension
+ *    schemes build the host app too — `Today` builds
+ *    `["Today.appex", "Client.app"]` — so this demotes 2 of 29 and leaves
+ *    firefox-ios picking `Today`.
+ *  - *demote anything building an `.appex`.* `chenqi92/primuse`'s `Primuse`
+ *    scheme is the real app scheme and builds two widget extensions alongside
+ *    `Primuse.app`.
+ *
+ * The attribute is a sufficient signal, not a necessary one: a hand-written or
+ * pre-Xcode-10 scheme may omit it, and its absence changes nothing, so nothing
+ * that ranked before can regress on a scheme that does not carry it.
  */
 export function rankSchemes(root, projectPath, schemes) {
     return rankSchemesWithReason(root, projectPath, schemes).schemes;
@@ -107,10 +147,12 @@ export function rankSchemesWithReason(root, projectPath, schemes) {
     const projectName = projectPath.replace(/\.(xcodeproj|xcworkspace)$/, "").split("/").pop();
     const scored = schemes.map((name, index) => {
         const facts = readSchemeFacts(root, name);
-        const companion = COMPANION_SCHEME.test(name);
+        // Two ways to be a companion: the name says so, or Xcode does. Xcode's
+        // word outranks a name match, so it disqualifies tier 0 as well.
+        const companion = COMPANION_SCHEME.test(name) || (facts?.appExtension ?? false);
         const app = facts?.runnable?.endsWith(".app") ?? false;
         let tier = 4;
-        if (name === projectName)
+        if (name === projectName && !facts?.appExtension)
             tier = 0;
         else if (facts?.runnable === `${projectName}.app` && !companion)
             tier = 1;

package/dist/src/commands/ios-scheme-ranking.test.js

@@ -27,11 +27,11 @@ afterEach(() => {
     rmSync(root, { recursive: true, force: true });
 });
 /** An `.xcscheme` with the parts the ranking reads, in Xcode's own shape. */
-function scheme(project, name, { runnable, testable }) {
+function scheme(project, name, { runnable, testable, appExtension }) {
     const dir = join(root, `${project}.xcodeproj`, "xcshareddata", "xcschemes");
     mkdirSync(dir, { recursive: true });
     writeFileSync(join(dir, `${name}.xcscheme`), `<?xml version="1.0" encoding="UTF-8"?>
-<Scheme LastUpgradeVersion = "1600" version = "1.7">
+<Scheme LastUpgradeVersion = "1600"${appExtension ? `\n   wasCreatedForAppExtension = "YES"` : ""} version = "1.7">
    <TestAction buildConfiguration = "Debug">
       <Testables>${testable
         ? `
@@ -149,4 +149,111 @@ describe("rankSchemes", () => {
         expect(pick("Solo.xcodeproj", ["Solo", "Other"])).toBe("Solo");
     });
 });
+/**
+ * An app extension is launched *through its host app*, so an extension scheme's
+ * LaunchAction runnable is the host `.app` — the same value the app's own
+ * scheme carries. Launching the app binary is therefore not sufficient to be
+ * the app scheme, and no name blocklist reaches the case: `Today` names nothing.
+ *
+ * Xcode states the fact itself, on the `<Scheme>` element of any scheme it
+ * created for an extension target. Measured across all 125 shared schemes in
+ * the thirty-app study's clones: 29 carry `wasCreatedForAppExtension`, all 29
+ * are extension schemes, and 27 of them build the host `.app` too — which is
+ * why "require an `.app` among the BuildAction entries" does not separate them.
+ */
+describe("rankSchemes and app-extension schemes", () => {
+    /**
+     * `mozilla-mobile/firefox-ios`, all thirteen schemes of
+     * `firefox-ios/Client.xcodeproj`, read off the clone. The project is
+     * `Client.xcodeproj`, so five schemes launch `Client.app` and land in the
+     * same tier; none carries an `iOS` or `Debug` token, so the tie fell to name
+     * length and `Today` (5) beat `Fennec` (6). The build then failed compiling
+     * `ActionExtension` — `bld_b1b38dda58f4111080415283`.
+     */
+    const FIREFOX_IOS = [
+        ["Account", { runnable: "libAccount.a", testable: true }],
+        ["Fennec", { runnable: "Client.app", testable: true }],
+        ["Fennec_Enterprise", { runnable: "Client.app", testable: true }],
+        ["Firefox", { runnable: "Client.app", testable: true }],
+        ["FirefoxBeta", { runnable: "Client.app", testable: true }],
+        ["FirefoxStaging", { runnable: "Client.app", testable: true }],
+        ["L10nSnapshotTests", { runnable: "L10nSnapshotTests.xctest", testable: true }],
+        ["Periphery", {}],
+        ["ShareTo", { runnable: "ShareTo.appex", appExtension: true }],
+        ["Storage", { runnable: "libStorage.a", testable: true }],
+        ["Sync", { runnable: "Sync.framework", testable: true }],
+        ["Telemetry", { runnable: "libSyncTelemetry.a", testable: true }],
+        ["Today", { runnable: "Client.app", testable: true, appExtension: true }],
+    ];
+    function firefoxIos() {
+        for (const [name, shape] of FIREFOX_IOS)
+            scheme("Client", name, shape);
+        return FIREFOX_IOS.map(([name]) => name);
+    }
+    test("picks the browser, not its widget", () => {
+        const names = firefoxIos();
+        expect(pick("Client.xcodeproj", names)).toBe("Fennec");
+    });
+    // The defect only became visible because a five-character extension name won
+    // a length tiebreak. The answer must not depend on the order either.
+    test("picks the browser whatever order the filesystem lists", () => {
+        const names = firefoxIos();
+        const orders = [
+            names,
+            [...names].reverse(),
+            ["Today", ...names.filter((n) => n !== "Today")],
+            ["ShareTo", "Today", ...names.filter((n) => n !== "Today" && n !== "ShareTo")],
+        ];
+        for (const order of orders) {
+            expect([order[0], pick("Client.xcodeproj", order)]).toEqual([order[0], "Fennec"]);
+        }
+    });
+    test("still keeps every scheme in the list", () => {
+        const names = firefoxIos();
+        expect([...rankSchemes(root, "Client.xcodeproj", names)].sort()).toEqual([...names].sort());
+    });
+    // The narrow statement, without the other twelve schemes around it.
+    test("an extension scheme launching the host app is not the app scheme", () => {
+        scheme("Client", "Fennec", { runnable: "Client.app", testable: true });
+        scheme("Client", "Today", { runnable: "Client.app", testable: true, appExtension: true });
+        expect(pick("Client.xcodeproj", ["Today", "Fennec"])).toBe("Fennec");
+    });
+    // Xcode's own word about the target outranks a name coincidence, so it
+    // disqualifies the name-match tier too.
+    test("outranks a scheme named exactly after the project", () => {
+        scheme("Widget", "Widget", { runnable: "Host.app", appExtension: true });
+        scheme("Widget", "HostApp", { runnable: "Host.app", testable: true });
+        expect(pick("Widget.xcodeproj", ["Widget", "HostApp"])).toBe("HostApp");
+    });
+    /**
+     * The attribute is a sufficient signal, not a necessary one — a hand-written
+     * or pre-Xcode-10 scheme may omit it. Its absence must change nothing, or
+     * every scheme that ranked correctly before this could regress.
+     *
+     * `chenqi92/primuse` is the row that makes the point concrete: its `Primuse`
+     * scheme is the real app scheme and builds two widget `.appex` bundles
+     * alongside `Primuse.app`, so "demote anything that builds an extension"
+     * would have taken the wrong one.
+     */
+    test("an untagged app scheme ranks exactly as it did before", () => {
+        scheme("Primuse", "Primuse", { runnable: "Primuse.app", testable: true });
+        scheme("Primuse", "PrimuseWidgets", { runnable: "Primuse.app" });
+        expect(pick("Primuse.xcodeproj", ["PrimuseWidgets", "Primuse"])).toBe("Primuse");
+    });
+    // When every candidate is an extension scheme there is no app scheme to
+    // find. Both land in the bottom tier, nothing is filtered out, and the
+    // pre-existing within-tier rule decides — so the caller still gets a
+    // deterministic answer rather than one that depends on the directory order.
+    test("still answers deterministically when every scheme is an extension", () => {
+        scheme("Client", "ShareTo", { runnable: "ShareTo.appex", appExtension: true });
+        scheme("Client", "Today", { runnable: "Client.app", appExtension: true });
+        for (const order of [
+            ["Today", "ShareTo"],
+            ["ShareTo", "Today"],
+        ]) {
+            expect([order[0], pick("Client.xcodeproj", order)]).toEqual([order[0], "Today"]);
+        }
+        expect(rankSchemes(root, "Client.xcodeproj", ["ShareTo", "Today"])).toHaveLength(2);
+    });
+});
 //# sourceMappingURL=ios-scheme-ranking.test.js.map

package/dist/src/yaml/env-resolver.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"env-resolver.d.ts","sourceRoot":"","sources":["../../../src/yaml/env-resolver.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAMH,OAAO,KAAK,EAAE,YAAY,EAAE,YAAY,EAAc,QAAQ,EAAE,MAAM,YAAY,CAAC;AAgEnF,qBAAa,+BAAgC,SAAQ,KAAK;aAEtC,YAAY,EAAE,MAAM;aACpB,QAAQ,CAAC,EAAE,MAAM;aACjB,IAAI,CAAC,EAAE,MAAM;gBAFb,YAAY,EAAE,MAAM,EACpB,QAAQ,CAAC,EAAE,MAAM,YAAA,EACjB,IAAI,CAAC,EAAE,MAAM,YAAA;CAUhC;AAED;;;;;;;GAOG;AACH,qBAAa,wBAAyB,SAAQ,KAAK;aAE/B,QAAQ,EAAE,MAAM;aAChB,QAAQ,CAAC,EAAE,MAAM;gBADjB,QAAQ,EAAE,MAAM,EAChB,QAAQ,CAAC,EAAE,MAAM,YAAA;CAKpC;AAED;;GAEG;AACH,qBAAa,WAAW;IACtB,OAAO,CAAC,OAAO,CAAsB;IACrC,OAAO,CAAC,cAAc,CAA0B;IAChD,OAAO,CAAC,cAAc,CAAiB;gBAGrC,QAAQ,EAAE,YAAY,EACtB,QAAQ,EAAE,YAAY,EACtB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,QAAQ,EAClB,KAAK,CAAC,EAAE,MAAM,EACd,YAAY,CAAC,EAAE,MAAM;IA0BvB;;;;OAIG;IACH,GAAG,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS;IAKrC;;;;OAIG;IACH,GAAG,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO;IAI1B;;;;OAIG;IACH,kBAAkB,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI;IAMtC;;;OAGG;IACH,MAAM,IAAI,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC;IAQhC;;;;;;;;;;;;OAYG;IACH,WAAW,CAAC,GAAG,EAAE,MAAM,EAAE,QAAQ,CAAC,EAAE,MAAM,GAAG,MAAM;IA0BnD;;;;;OAKG;IACH,iBAAiB,CAAC,GAAG,EAAE,GAAG,EAAE,QAAQ,CAAC,EAAE,MAAM,GAAG,GAAG;IAoBnD;;;OAGG;IACH,sBAAsB,IAAI,IAAI;IAQ9B;;;;;;OAMG;IACH,OAAO,CAAC,UAAU;IAalB;;;;;OAKG;IACH,OAAO,CAAC,eAAe;IA0BvB;;;;;OAKG;IACH,OAAO,CAAC,cAAc;IA4FtB;;;OAGG;IACH,OAAO,CAAC,YAAY;IAkBpB;;;;OAIG;IACH,OAAO,CAAC,sBAAsB;IAuB9B;;;;;OAKG;IACH,OAAO,CAAC,mBAAmB;CAS5B;AAED;;;;;;;GAOG;AACH,wBAAgB,iBAAiB,CAC/B,QAAQ,EAAE,YAAY,EACtB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,QAAQ,EAClB,KAAK,CAAC,EAAE,MAAM,GACb,WAAW,CAOb"}
+{"version":3,"file":"env-resolver.d.ts","sourceRoot":"","sources":["../../../src/yaml/env-resolver.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAMH,OAAO,KAAK,EAAE,YAAY,EAAE,YAAY,EAAc,QAAQ,EAAE,MAAM,YAAY,CAAC;AAiEnF,qBAAa,+BAAgC,SAAQ,KAAK;aAEtC,YAAY,EAAE,MAAM;aACpB,QAAQ,CAAC,EAAE,MAAM;aACjB,IAAI,CAAC,EAAE,MAAM;gBAFb,YAAY,EAAE,MAAM,EACpB,QAAQ,CAAC,EAAE,MAAM,YAAA,EACjB,IAAI,CAAC,EAAE,MAAM,YAAA;CAUhC;AAED;;;;;;;GAOG;AACH,qBAAa,wBAAyB,SAAQ,KAAK;aAE/B,QAAQ,EAAE,MAAM;aAChB,QAAQ,CAAC,EAAE,MAAM;gBADjB,QAAQ,EAAE,MAAM,EAChB,QAAQ,CAAC,EAAE,MAAM,YAAA;CAKpC;AAED;;GAEG;AACH,qBAAa,WAAW;IACtB,OAAO,CAAC,OAAO,CAAsB;IACrC,OAAO,CAAC,cAAc,CAA0B;IAChD,OAAO,CAAC,cAAc,CAAiB;gBAGrC,QAAQ,EAAE,YAAY,EACtB,QAAQ,EAAE,YAAY,EACtB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,QAAQ,EAClB,KAAK,CAAC,EAAE,MAAM,EACd,YAAY,CAAC,EAAE,MAAM;IA0BvB;;;;OAIG;IACH,GAAG,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS;IAKrC;;;;OAIG;IACH,GAAG,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO;IAI1B;;;;OAIG;IACH,kBAAkB,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI;IAMtC;;;OAGG;IACH,MAAM,IAAI,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC;IAQhC;;;;;;;;;;;;OAYG;IACH,WAAW,CAAC,GAAG,EAAE,MAAM,EAAE,QAAQ,CAAC,EAAE,MAAM,GAAG,MAAM;IAqCnD;;;;;OAKG;IACH,iBAAiB,CAAC,GAAG,EAAE,GAAG,EAAE,QAAQ,CAAC,EAAE,MAAM,GAAG,GAAG;IAoBnD;;;OAGG;IACH,sBAAsB,IAAI,IAAI;IAQ9B;;;;;;OAMG;IACH,OAAO,CAAC,UAAU;IAalB;;;;;OAKG;IACH,OAAO,CAAC,eAAe;IA0BvB;;;;;OAKG;IACH,OAAO,CAAC,cAAc;IA4FtB;;;OAGG;IACH,OAAO,CAAC,YAAY;IAkBpB;;;;OAIG;IACH,OAAO,CAAC,sBAAsB;IAuB9B;;;;;OAKG;IACH,OAAO,CAAC,mBAAmB;CAS5B;AAED;;;;;;;GAOG;AACH,wBAAgB,iBAAiB,CAC/B,QAAQ,EAAE,YAAY,EACtB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,QAAQ,EAClB,KAAK,CAAC,EAAE,MAAM,GACb,WAAW,CAOb"}

package/dist/src/yaml/env-resolver.js

@@ -8,6 +8,7 @@ import * as fs from 'fs';
 import * as path from 'path';
 import { execSync } from 'child_process';
 import { SecretsManager } from './secrets-manager.js';
+import { shellAssignedNamesIn } from './shell-assignments.js';
 /**
  * Hints for common variables that require user configuration
  */
@@ -174,21 +175,31 @@ export class EnvResolver {
      */
     interpolate(str, stepName) {
         let result = str;
+        // A name this very string assigns is the shell's own, and substituting it
+        // is worse than demanding it: `IOS_DIR=$(dirname "$IOS_PROJECT_PATH")`
+        // followed by `"$IOS_DIR"` would get a pipeline value pasted in instead of
+        // the one `dirname` had just computed, so a defined variable would corrupt
+        // the script and an undefined one would refuse the build. Left for the
+        // shell, which is the only thing that can evaluate it. Only the assignment
+        // target is spared — the right-hand side is still resolved here.
+        const selfAssigned = shellAssignedNamesIn(str);
         // Format 1: {{checksum "file"}}
         result = result.replace(/\{\{checksum "([^"]+)"\}\}/g, (match, filePath) => {
             return this.computeChecksum(filePath, stepName);
         });
-        // Format 2: {{getenv "VAR"}}
+        // Format 2: {{getenv "VAR"}} — an explicit request, so it is honoured even
+        // where the snippet also assigns that name. Asking by name is not the same
+        // as a bare `$VAR` the shell was always going to expand itself.
         result = result.replace(/\{\{getenv "([^"]+)"\}\}/g, (match, varName) => {
             return this.resolveVar(varName, stepName);
         });
         // Format 3: ${VAR}
         result = result.replace(/\$\{([A-Z_][A-Z0-9_]*)\}/g, (match, varName) => {
-            return this.resolveVar(varName, stepName);
+            return selfAssigned.has(varName) ? match : this.resolveVar(varName, stepName);
         });
         // Format 4: $VAR (must not be followed by alphanumeric or underscore)
         result = result.replace(/\$([A-Z_][A-Z0-9_]*)(?![A-Z0-9_])/g, (match, varName) => {
-            return this.resolveVar(varName, stepName);
+            return selfAssigned.has(varName) ? match : this.resolveVar(varName, stepName);
         });
         return result;
     }

package/dist/src/yaml/shell-assignments.d.ts

@@ -0,0 +1,40 @@
+/**
+ * Which names a shell snippet binds for itself.
+ *
+ * Two different parts of this codebase scan a step's inputs for `$UPPERCASE`
+ * and act on every hit — the pre-execution validator, which demands each one
+ * be supplied, and the env resolver, which *substitutes* each one. For a
+ * `script` step the inputs are the shell body, so a variable the script
+ * computes is indistinguishable from one it needs handed to it. Both were
+ * wrong about the same thing, so they share one answer.
+ *
+ * A generated multiplatform pipeline made it plain. Its prepare step opens
+ *
+ *     INTEGRATION="$KMM_IOS_INTEGRATION"
+ *     IOS_DIR=$(dirname "$IOS_PROJECT_PATH")
+ *     for WORKSPACE in "$IOS_DIR"/*.xcworkspace; do …
+ *
+ * and no build could start: the validator refused for three values nothing was
+ * meant to provide, and the resolver would have gone further and *rewritten*
+ * the body, replacing `"$IOS_DIR"` with a pipeline value instead of the one
+ * `dirname` had just computed. Substituting a shell local is not a missing
+ * value at all; it is a corrupted script.
+ *
+ * **Only the assignment target is collected, never the right-hand side.** That
+ * is what keeps this from being a hole: `INTEGRATION="$KMM_IOS_INTEGRATION"`
+ * still needs `KMM_IOS_INTEGRATION`, so a script cannot excuse itself from a
+ * value it reads by mentioning it.
+ *
+ * Assignment order is deliberately not modelled. A snippet that reads a
+ * variable before setting it is a bug in the snippet, and guessing about it
+ * here would trade one wrong answer for another; "does the script set this
+ * itself?" is the question worth asking.
+ */
+/** The names one snippet of shell assigns to itself. */
+export declare function shellAssignedNamesIn(text: string): Set<string>;
+/**
+ * The same question asked of a whole inputs object, walked recursively — what
+ * the validator needs, because it reasons about a step rather than a string.
+ */
+export declare function shellAssignedNames(obj: unknown): Set<string>;
+//# sourceMappingURL=shell-assignments.d.ts.map

package/dist/src/yaml/shell-assignments.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shell-assignments.d.ts","sourceRoot":"","sources":["../../../src/yaml/shell-assignments.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AAaH,wDAAwD;AACxD,wBAAgB,oBAAoB,CAAC,IAAI,EAAE,MAAM,GAAG,GAAG,CAAC,MAAM,CAAC,CAa9D;AAED;;;GAGG;AACH,wBAAgB,kBAAkB,CAAC,GAAG,EAAE,OAAO,GAAG,GAAG,CAAC,MAAM,CAAC,CAa5D"}

package/dist/src/yaml/shell-assignments.js

@@ -0,0 +1,77 @@
+/**
+ * Which names a shell snippet binds for itself.
+ *
+ * Two different parts of this codebase scan a step's inputs for `$UPPERCASE`
+ * and act on every hit — the pre-execution validator, which demands each one
+ * be supplied, and the env resolver, which *substitutes* each one. For a
+ * `script` step the inputs are the shell body, so a variable the script
+ * computes is indistinguishable from one it needs handed to it. Both were
+ * wrong about the same thing, so they share one answer.
+ *
+ * A generated multiplatform pipeline made it plain. Its prepare step opens
+ *
+ *     INTEGRATION="$KMM_IOS_INTEGRATION"
+ *     IOS_DIR=$(dirname "$IOS_PROJECT_PATH")
+ *     for WORKSPACE in "$IOS_DIR"/*.xcworkspace; do …
+ *
+ * and no build could start: the validator refused for three values nothing was
+ * meant to provide, and the resolver would have gone further and *rewritten*
+ * the body, replacing `"$IOS_DIR"` with a pipeline value instead of the one
+ * `dirname` had just computed. Substituting a shell local is not a missing
+ * value at all; it is a corrupted script.
+ *
+ * **Only the assignment target is collected, never the right-hand side.** That
+ * is what keeps this from being a hole: `INTEGRATION="$KMM_IOS_INTEGRATION"`
+ * still needs `KMM_IOS_INTEGRATION`, so a script cannot excuse itself from a
+ * value it reads by mentioning it.
+ *
+ * Assignment order is deliberately not modelled. A snippet that reads a
+ * variable before setting it is a bug in the snippet, and guessing about it
+ * here would trade one wrong answer for another; "does the script set this
+ * itself?" is the question worth asking.
+ */
+/** `NAME=…`, `export NAME=…`, `local/readonly/declare/typeset NAME=…`, `NAME+=…` */
+const ASSIGNMENT = /(?:^|[\n;&|(]|\|\||&&)[ \t]*(?:(?:export|readonly|local|declare|typeset)[ \t]+)?([A-Z_][A-Z_0-9]*)\+?=/g;
+/** `for NAME in …`, `select NAME in …` */
+const LOOP = /(?:^|[\n;&|(])[ \t]*(?:for|select)[ \t]+([A-Z_][A-Z_0-9]*)[ \t]+in\b/g;
+/** `read NAME`, `read -r NAME OTHER`, `while read -r NAME` */
+const READ = /(?:^|[\n;&|(]|\|\||&&)[ \t]*(?:while[ \t]+)?read[ \t]+((?:-\S+[ \t]+)*)([A-Z_][A-Z_0-9]*(?:[ \t]+[A-Z_][A-Z_0-9]*)*)/g;
+/** The names one snippet of shell assigns to itself. */
+export function shellAssignedNamesIn(text) {
+    const names = new Set();
+    for (const re of [ASSIGNMENT, LOOP]) {
+        re.lastIndex = 0;
+        let m;
+        while ((m = re.exec(text)) !== null)
+            names.add(m[1]);
+    }
+    READ.lastIndex = 0;
+    let m;
+    while ((m = READ.exec(text)) !== null) {
+        for (const n of m[2].trim().split(/[ \t]+/))
+            names.add(n);
+    }
+    return names;
+}
+/**
+ * The same question asked of a whole inputs object, walked recursively — what
+ * the validator needs, because it reasons about a step rather than a string.
+ */
+export function shellAssignedNames(obj) {
+    const names = new Set();
+    const walk = (value) => {
+        if (typeof value === 'string') {
+            for (const n of shellAssignedNamesIn(value))
+                names.add(n);
+        }
+        else if (Array.isArray(value)) {
+            value.forEach(walk);
+        }
+        else if (value && typeof value === 'object') {
+            Object.values(value).forEach(walk);
+        }
+    };
+    walk(obj);
+    return names;
+}
+//# sourceMappingURL=shell-assignments.js.map

package/dist/src/yaml/step-validator-self-assigned.test.js

@@ -21,7 +21,9 @@
  */
 import { describe, test, expect } from '@jest/globals';
 import '../yaml/steps/index.js';
-import { StepValidator, shellAssignedNames } from './step-validator.js';
+import { StepValidator } from './step-validator.js';
+import { EnvResolver } from './env-resolver.js';
+import { shellAssignedNames } from './shell-assignments.js';
 import { loadConfig } from '../config.js';
 const config = loadConfig();
 /** A one-script workflow, so the only issues are about its variables. */
@@ -126,4 +128,64 @@ describe('pre-execution validation and self-assigned variables', () => {
         ]);
     });
 });
+/**
+ * The resolver half, and the worse half.
+ *
+ * `StepValidator` only *demands* a script's own locals. `EnvResolver`
+ * SUBSTITUTES them — so a defined `IOS_DIR` would paste a pipeline value over
+ * the one `dirname` had just computed, and an undefined one refuses the build.
+ * Both are wrong; leaving the reference for the shell is the only correct
+ * answer, and it is the same thing `registerStepOutput` already does for a
+ * value a previous step exports.
+ */
+describe('EnvResolver leaves a script its own locals', () => {
+    const PREPARE = [
+        'INTEGRATION="$KMM_IOS_INTEGRATION"',
+        'IOS_DIR=$(dirname "$IOS_PROJECT_PATH")',
+        'echo "$INTEGRATION in $IOS_DIR"',
+        'for WORKSPACE in "$IOS_DIR"/*.xcworkspace; do echo "$WORKSPACE"; done',
+    ].join('\n');
+    function resolver(envs) {
+        const pipeline = {
+            format_version: '1',
+            app: { envs: Object.entries(envs).map(([k, v]) => ({ [k]: v })) },
+            workflows: { primary: { steps: [] } },
+        };
+        return new EnvResolver(pipeline, pipeline.workflows.primary, 'primary', 'macos');
+    }
+    test('does not substitute or demand what the snippet assigns', () => {
+        const out = resolver({
+            KMM_IOS_INTEGRATION: 'cocoapods',
+            IOS_PROJECT_PATH: 'iosApp/iosApp.xcodeproj',
+        }).interpolate(PREPARE, 'Prepare the iOS build');
+        // The right-hand sides ARE resolved…
+        expect(out).toContain('INTEGRATION="cocoapods"');
+        expect(out).toContain('IOS_DIR=$(dirname "iosApp/iosApp.xcodeproj")');
+        // …and the locals are left for the shell, verbatim.
+        expect(out).toContain('echo "$INTEGRATION in $IOS_DIR"');
+        expect(out).toContain('for WORKSPACE in "$IOS_DIR"/*.xcworkspace');
+        expect(out).toContain('echo "$WORKSPACE"');
+    });
+    // Before the fix this threw MissingEnvironmentVariableError for INTEGRATION,
+    // which is what stopped every generated KMM and iOS pipeline before step 1.
+    test('does not throw for a local the snippet assigns', () => {
+        expect(() => resolver({
+            KMM_IOS_INTEGRATION: 'direct',
+            IOS_PROJECT_PATH: 'iosApp/iosApp.xcodeproj',
+        }).interpolate(PREPARE, 'Prepare the iOS build')).not.toThrow();
+    });
+    // The regression guard: a value the script only READS is still required.
+    test('still throws for a variable the snippet only reads', () => {
+        expect(() => resolver({}).interpolate(PREPARE, 'Prepare the iOS build')).toThrow(/Missing environment variable: 'KMM_IOS_INTEGRATION'/);
+    });
+    test('substitutes normally where the snippet assigns nothing', () => {
+        expect(resolver({ IOS_SCHEME: 'Hush iOS' }).interpolate('xcodebuild -scheme "$IOS_SCHEME"'))
+            .toBe('xcodebuild -scheme "Hush iOS"');
+    });
+    // `{{getenv "X"}}` is an explicit request by name, not a bare shell
+    // expansion, so it is honoured even where the snippet also assigns X.
+    test('still honours an explicit {{getenv}} for an assigned name', () => {
+        expect(resolver({ IOS_DIR: 'from-pipeline' }).interpolate('IOS_DIR=x\necho {{getenv "IOS_DIR"}}')).toContain('echo from-pipeline');
+    });
+});
 //# sourceMappingURL=step-validator-self-assigned.test.js.map

package/dist/src/yaml/step-validator.d.ts

@@ -8,38 +8,6 @@
 import type { YAMLPipeline } from './types.js';
 import type { CIConfig } from '../types.js';
 import type { WorkflowValidationResult } from './validation-types.js';
-/**
- * Names a shell snippet assigns to itself, in every form a step script uses.
- *
- * The auto-discovery below treats every `$UPPERCASE` it finds in a step's
- * inputs as a value the pipeline must supply. For a `script` step the inputs
- * *are* the shell body, so a variable the script computes reads exactly like
- * one it needs handed to it — and the run is refused for a value nothing was
- * ever supposed to provide.
- *
- * That is not hypothetical. A generated multiplatform pipeline whose prepare
- * step opens with
- *
- *     INTEGRATION="$KMM_IOS_INTEGRATION"
- *     IOS_DIR=$(dirname "$IOS_PROJECT_PATH")
- *     for WORKSPACE in "$IOS_DIR"/*.xcworkspace; do …
- *
- * was refused before step 1 on "3 required value(s) missing — INTEGRATION,
- * IOS_DIR, WORKSPACE", while the two variables it genuinely reads were both
- * declared and present. The shell was correct; the reader was not.
- *
- * Only the assignment *target* is collected, never the right-hand side, so
- * `INTEGRATION="$KMM_IOS_INTEGRATION"` still requires `KMM_IOS_INTEGRATION`.
- * That is what keeps this from becoming a hole: a script cannot excuse itself
- * from a value it reads by mentioning it.
- *
- * Assignment order is deliberately not modelled. A snippet that reads `$FOO`
- * before setting it is a bug in the snippet, and guessing about it here would
- * trade a false refusal for a different false refusal; "the script sets this
- * somewhere" is the question worth asking, and erring toward letting the build
- * run is the right direction for a check that cannot prompt.
- */
-export declare function shellAssignedNames(obj: unknown): Set<string>;
 /**
  * StepValidator orchestrates pre-execution validation for a workflow.
  * It iterates through all steps, collects validation requirements,

package/dist/src/yaml/step-validator.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"step-validator.d.ts","sourceRoot":"","sources":["../../../src/yaml/step-validator.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAOH,OAAO,KAAK,EAAE,YAAY,EAA4B,MAAM,YAAY,CAAC;AACzE,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,aAAa,CAAC;AAC5C,OAAO,KAAK,EAGV,wBAAwB,EAGzB,MAAM,uBAAuB,CAAC;AAwB/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAgB,kBAAkB,CAAC,GAAG,EAAE,OAAO,GAAG,GAAG,CAAC,MAAM,CAAC,CA6B5D;AAED;;;;GAIG;AACH,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAe;IAC/B,OAAO,CAAC,QAAQ,CAAe;IAC/B,OAAO,CAAC,YAAY,CAAS;IAC7B,OAAO,CAAC,MAAM,CAAW;IACzB,OAAO,CAAC,WAAW,CAAc;IACjC,OAAO,CAAC,YAAY,CAAC,CAAS;IAG9B,OAAO,CAAC,gBAAgB,CAAoE;IAG5F,OAAO,CAAC,mBAAmB,CAA6B;IAKxD,OAAO,CAAC,QAAQ,CAAC,cAAc,CAAU;gBAGvC,QAAQ,EAAE,YAAY,EACtB,YAAY,EAAE,MAAM,EACpB,MAAM,EAAE,QAAQ,EAChB,YAAY,CAAC,EAAE,MAAM;IA0BvB;;;OAGG;IACG,gBAAgB,IAAI,OAAO,CAAC,wBAAwB,CAAC;IAwN3D;;OAEG;YACW,mBAAmB;IAmEjC;;;;;;;;;OASG;IACH,OAAO,CAAC,yBAAyB;IAsBjC;;;;;;;;;OASG;IACH,OAAO,CAAC,mBAAmB;IAoB3B;;OAEG;IACH,OAAO,CAAC,SAAS;CA8BlB;AAED;;GAEG;AACH,wBAAgB,sBAAsB,CAAC,MAAM,EAAE,wBAAwB,GAAG,MAAM,CA4D/E"}
+{"version":3,"file":"step-validator.d.ts","sourceRoot":"","sources":["../../../src/yaml/step-validator.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAQH,OAAO,KAAK,EAAE,YAAY,EAA4B,MAAM,YAAY,CAAC;AACzE,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,aAAa,CAAC;AAC5C,OAAO,KAAK,EAGV,wBAAwB,EAGzB,MAAM,uBAAuB,CAAC;AAwB/B;;;;GAIG;AACH,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAe;IAC/B,OAAO,CAAC,QAAQ,CAAe;IAC/B,OAAO,CAAC,YAAY,CAAS;IAC7B,OAAO,CAAC,MAAM,CAAW;IACzB,OAAO,CAAC,WAAW,CAAc;IACjC,OAAO,CAAC,YAAY,CAAC,CAAS;IAG9B,OAAO,CAAC,gBAAgB,CAAoE;IAG5F,OAAO,CAAC,mBAAmB,CAA6B;IAKxD,OAAO,CAAC,QAAQ,CAAC,cAAc,CAAU;gBAGvC,QAAQ,EAAE,YAAY,EACtB,YAAY,EAAE,MAAM,EACpB,MAAM,EAAE,QAAQ,EAChB,YAAY,CAAC,EAAE,MAAM;IA0BvB;;;OAGG;IACG,gBAAgB,IAAI,OAAO,CAAC,wBAAwB,CAAC;IAwN3D;;OAEG;YACW,mBAAmB;IAmEjC;;;;;;;;;OASG;IACH,OAAO,CAAC,yBAAyB;IAsBjC;;;;;;;;;OASG;IACH,OAAO,CAAC,mBAAmB;IAoB3B;;OAEG;IACH,OAAO,CAAC,SAAS;CA8BlB;AAED;;GAEG;AACH,wBAAgB,sBAAsB,CAAC,MAAM,EAAE,wBAAwB,GAAG,MAAM,CA4D/E"}