jmelovich ab1d8c0d28 ci: attach the build to a release the web UI already created ...

Cutting a release from GitHub's "Draft a new release" page would have produced a
release with no app in it.

Publishing there creates the tag and the release in one action, so by the time
the tag event reaches the release job a release for that tag already exists.
`gh release create` fails on that, the job errors, and the ZIP is never
attached - leaving a published release that looks finished and contains nothing
installable. The catalog would then have no artifact to pin.

Check for an existing release first. If there is one, upload the assets into it
with --clobber and leave its title and notes alone, since whoever wrote them in
the UI meant them; otherwise create the draft as before. Both routes now end
with the same three assets attached.

The contentVersion rule is unchanged and still enforced either way: the web
route means editing sce_sys/param.json in the browser and committing it before
drafting the release, because the tag the UI creates points at the current head
of the branch. For v1.0.0 that happens to need no edit, the committed baseline
already being 01.000.000.

Tested: make test passes (13 tests, including a new assertion that the workflow
handles an existing release); the YAML parses and every run: block passes
bash -n. The round trip is exercised against the real repository next.

2026-10-10 13:21:02 -07:00

..

workflows

ci: attach the build to a release the web UI already created

2026-10-10 13:21:02 -07:00