Release Process Proposal

Release Process Proposal

Goal: avoid committing binaries to this repo.

Proposal: Use github releases as the provider for binary artifacts. Use bazel
to reference github release archive URLs to access the necessary binary
artifacts.

Pre-work

1. Allow attaching additional bazel repos into the provisioning extensions repo.
   These additional repos get symlinked into a hub repo named
   @provisioning_exts_extra. These additional repos are:

   • presign_perso
   • presign_rom_ext
   • perso_release
   • rom_ext_release

   The URIs and names of these additional repos are controlled by
   //skus/extras.json.

Release Process

1. Tag the codebase:
   • ROM_EXT_BUILD_20260513_rc00
   • PERSO_BUILD_20260513_rc00
2. Build the ROM_EXT or perso binaries at the tag. Publish the resulting
   archives as a github release. Note: the release archive contains both
   presigning binaries and digests.
3. Create a branch at the tag and update the presign_ member(s) of
   extras.json. Push the branch.
4. Perform the offline signing ceremony and sign the digests in the presigning
   archive.
5. Create a PR with the signatures from the offline ceremony. Submit that PR to
   the branch.
6. Build signed binaries from the the release branch using the presigning
   binaries from the archive. Publish the signed binaries as a github release.
7. Update the release member(s) of extras.json. Tag the branch with a
   release tag (e.g. ROM_EXT_RELEASE_20260513_rc00). Push the branch and
   tags.
8. Merge the changes to extras.json from the branch into the main branch.

Automation

Add github actions to assist with automating the two halves of the release
process.

• Pre-signing automation: Steps 1..3.
• Post-signing release: Steps 5..8.

Potential Problems

The opentitan codebase currently uses a repository extension to hook the
ot-sku codebase into the opentitan codebase (as @provisioning_exts). The
opentitan repo doesn't watch the extras.json file in the downstream codebase.
Updates to extras.json require refreshing the repository mapping to allow the
hub repo @provisioning_exts_extra to see the updates.

TODO: Investigate making the @provisioning_exts repo a bazel_dep and use the
commandline --override_repository=provisioning_exts=<path> to connect ot-sku
into the main repo. Build the hub repository as an extension inside of the
ot-sku repo. Does this resolve the issue?