Walkthrough: adding an application to the catalog

This page continues Walkthrough: release end-to-end after its catalog step: how an application without a release manifest joins the pipeline, and how the scripts adopt wrote are brought up to date.

Add an application that has no manifest yet

An application checkout without a .wisent-release.json joins the pipeline with one command, which reads what the checkout's own project states instead of a hand-copied manifest:

stado release catalog adopt /path/to/app-ios --kind ios-xcode
stado release catalog adopt /path/to/app-ios --kind ios-xcode --apply \
  --owner <vault-owner-host> --client <submitting-host>

--kind ios-xcode reads the one *.xcodeproj at the checkout root. The project name is the default scheme (--scheme overrides it). The bundle identifier is the shortest one that is not a test bundle. It also reads the DEVELOPMENT_TEAM and the MARKETING_VERSION, which must be two or three numbers. The product name defaults to the folder name (--product overrides it). It refuses, by name, a checkout with no or several projects, a project without a name before .xcodeproj, one that states no application PRODUCT_BUNDLE_IDENTIFIER, no DEVELOPMENT_TEAM or no MARKETING_VERSION, and a MARKETING_VERSION in another shape, quoting what it states.

Without --apply the command prints the two files it would write and changes nothing:

• .wisent-release.json, with the version read from the project file and no quality step: a release runs only the tests a product declares, and none is declared until the operator approves one;
• release/build.sh, which archives, signs with the declared distribution certificate and provisioning profile, and exports the IPA.

With --apply it writes those files and registers the product exactly as catalog sync --root registers a checkout. When --owner and --client are given, it first declares the publisher exactly as catalog publisher declare does.

Refusals, each naming its cause:

• the path is not a git checkout;
• it already declares a .wisent-release.json (use catalog sync --root, or --refresh below);
• there is no Xcode project at its root, or there are several;
• the project states no application bundle, team or readable marketing version;
• a file it would write already exists.

The files must then be committed and pushed. A release builds a pushed commit, and it signs only once the declared signing credential holds the provisioning profile.

Refresh the scripts adopt wrote

A script adopt wrote keeps what the generator wrote then. When the generator changes (a build moved to kompilator, say), bring an adopted product up to date:

stado release catalog adopt /path/to/app --kind kompilator --refresh
stado release catalog adopt /path/to/app --kind kompilator --refresh --apply

--refresh plans the same files for that --kind, leaves .wisent-release.json as it is, and keeps only the release scripts whose second line begins # Written by `stado release catalog adopt and whose text differs from what adopt writes today. Without --apply it prints would rewrite <path> for each; with --apply it rewrites them and prints rewrote <path>; when none differs it says the scripts are already what adopt writes. It refuses a checkout with no .wisent-release.json (nothing was adopted), a script at a planned path that adopt did not write (naming it, so a hand-written script is never overwritten), and --owner, --client, --target or --reload beside it.