Three related improvements to the release workflow: fix the macOS notarization failure, make the workflow able to rebuild old tags, and let a manual run target a subset of platforms.

1. Notarization fix — invalidAsn1

The macOS release build fails at notarization:

Submitting notarization request...
Conducting pre-submission checks for notarize.zip and initiating connection to the Apple notary service...
Error: invalidAsn1
Error: notarytool did not report an Accepted status

First run of the notarization step added in #243 (v0.21.1).

Root cause. invalidAsn1 means xcrun notarytool could not parse the .p8 key as a PKCS#8 (ASN.1) private key while building its App Store Connect JWT — a key-format problem, not a binary/signing problem. Code signing (which runs first) succeeds, so DEV_ID_CERT_* is fine; the issue is isolated to the API key. The AC_API_PRIVATE_KEY_P8 secret is stored base64-encoded (same convention as DEV_ID_CERT_P12, consumed as base64 by apple-actions/import-codesign-certs via p12-file-base64), but the ported step wrote it to AuthKey.p8 verbatim — so notarytool received a base64 blob instead of PEM.

Fix. Decode the secret back to PEM before handing it to notarytool: auto-detect raw-PEM vs base64 input, strip CR from CRLF pastes, fail fast on an empty secret, and validate the materialized key with openssl pkey so a malformed key produces a clear warning instead of the opaque invalidAsn1.

2. Self-healing release checkout

GitHub always executes the release.yml baked into the triggering ref, so a bug in an old tag's workflow can't be fixed by re-publishing/re-running that tag — exactly why the §1 fix wouldn't retroactively apply to the v0.21.1 tag.

actions/checkout now checks out the target tag's source (release tag for the release event, or the release_tag input for workflow_dispatch, falling back to the triggering commit). This decouples which workflow runs from which source is built: dispatch from a branch carrying the fixed workflow and pass release_tag=v0.21.1, and the fixed workflow rebuilds the v0.21.1 source and uploads notarized artifacts onto that release. Asset names/protoc version are static and the binary version comes from the checked-out Cargo.toml, so changing the checkout ref has no naming/version side effects.

3. Build-target selector

New targets workflow_dispatch input (comma-separated windows, linux, macos, or all; empty = all) so a manual run can build a subset of platforms. A new setup job resolves the input into a filtered build matrix that build consumes via fromJSON(needs.setup.outputs.includes) — one source of truth for the platform list. Real release events always build every target (the input only filters manual dispatch). Input is case/space-insensitive and rejects unknown tokens.

Combined with §2, this allows rebuilding just one platform of a past tag — e.g. re-notarize only macOS for v0.21.1 without rebuilding Linux/Windows.

Verification

• Notarization: simulated both secret formats with a throwaway EC P-256 PKCS#8 key — base64 → decoded → valid; raw PEM → as-is → valid; old behavior (base64 verbatim) → openssl INVALID, reproducing invalidAsn1.
• Target selector: extracted the embedded setup script from the YAML and ran it for every input — ''/all→6 targets, macos→1, linux,macos→5, Windows, MacOS→2 (case/space ok), dedup ok, bogus→exit 1.
• Workflow YAML validated with yaml.safe_load; build.needs == setup and matrix.include == fromJSON(...) confirmed.

Recovering v0.21.1 after merge

# Rebuild + re-notarize only macOS for v0.21.1:
gh workflow run release.yml --repo lablup/all-smi \
  --ref main -f release_tag=v0.21.1 -f targets=macos