@wix/himalaya-cli 0.1626.0 → 0.1628.0

package/dist/cli.mjs

@@ -29474,6 +29474,7 @@ function resolveIdiom(tokens2, ctx = {}) {
 var IDIOM_CONTEXTS, UNSAFE_KEYS;
 var init_idiom = __esm({
   "../../core/ts/src/idiom.ts"() {
+    "use strict";
     init_define_HHP_CATALOG();
     IDIOM_CONTEXTS = {
       ios: { native: ["ios"] },

package/guides/qa-builds.md

@@ -204,11 +204,19 @@ each job records what it places before placing it: its signing folder (which hol
 until it is imported), the identity it imports into the agent keychain, and every copy of the App
 Store Connect key (`~/.private_keys/AuthKey_<id>.p8`, also when it replaces a file already there,
 and the temporary copy `altool` reads). The records live in `~/.himalaya/customer-secret-claims` in the account home.
-At the start of the next customer build on that Mac, before the pre-existing check, Himi removes
-what a job whose process has ended recorded, and leaves alone what a running job recorded, since a
-Mac may run more than one job at once. A matching identity that a running job owns, or that no
-record names, is still refused. SIGTERM and process exit remove the key copies directly, as they do
-the signing directory.
+Every dist job on a Mac, customer or not, starts by removing what a job whose process has ended
+recorded, and leaves alone what a running job recorded, since a Mac may run more than one job at
+once. An identity is removed only by a job that has the agent's `KEYCHAIN_PASSWORD` (a Job Service
+job), which unlocks the keychain first; a job without it leaves that record as it is. A customer
+build sweeps again after unlocking, before the pre-existing check. A matching identity that a
+running job owns, or that no record names, is still refused. SIGTERM and process exit remove the
+key copies directly, as they do the signing directory.
+
+App Store validation (the purpose-string and required-reason scans, the APNs check and `altool`)
+runs in a child process the job waits on without blocking, so a SIGTERM that lands while `altool`
+runs is handled at once: the job removes the key copies and the identity, and kills the child's
+process group. `altool` stops after 10 minutes, and the whole validation after 15
+(`customer_app_store_validation_timeout`).
 
 Outside that runner mode, Himi creates a temporary keychain and deletes it during cleanup. That
 keychain is recorded the same way before it is created, and the next customer build deletes one an
@@ -1260,10 +1268,14 @@ himi dist --app <app> --platform android --aab --wait --target bo
   can make one (`appStoreBuild` in the signing marker), `CheckIfBuildIsAllowed` finds a
   saved bundle id and an eligible plan (so an ineligible site never reaches Apple), then
   `PrepareAppleCertificates` registers the bundle id in the owner's Apple account and answers the
-  certificate, profile and key, and only then `ValidateStoreBuild` locks the bundle id (so a bundle id
-  Apple refuses can still change), and only while it is still the prepared one (`expected_store_id`:
-  a bundle id saved in between is refused and stays changeable). The owner must already have the app
-  in App Store Connect under that bundle id. The files
+  certificate, profile and key, and only then `CreateBuildRecordIfAllowed` locks the bundle id (so a
+  bundle id Apple refuses can still change), and only while it is still the prepared one
+  (`expected_store_id`: a bundle id saved in between is refused and stays changeable). That call also
+  opens Wix's record of the build, as for a bundle: the job id is reported at dispatch, and the build's
+  end once its upload settles (`UPLOADED` is the success, reported with the IPA; an upload `FAILED`
+  for good is the failure, with its `error`; a build that fails or is canceled on the pool is
+  reported so). A built IPA waiting for its upload reports nothing yet. The owner must already have
+  the app in App Store Connect under that bundle id. The files
   and the key are never stored: the pool and the upload each fetch them again, the job keeps only
   their hashes. The upload starts on its own once the pool reports the validated IPA: the pool's
   callback starts it in the background, and so does every list read of the app's builds (the owner

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1626.0",
+  "version": "0.1628.0",
   "type": "module",
   "description": "himi — the Himalaya authoring CLI. Build a Tier-5 content package on your own machine, push it to the production serve as a draft, preview it on web + Himi Player, and read worker logs back — the remote dev loop. Wraps @himalaya/serve-cli for transport.",
   "keywords": [
@@ -72,5 +72,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "869790bb3cee9edb5ddd63f3befb4a65c1999a3ba9f388e5ad711509"
+  "falconPackageHash": "186c60ced3f6652ebc1c45bc98791fe0b8c55718eaed2223bf2bf300"
 }