bvandeusen/FabledCurator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 33 Wiki Activity

fix(ext-ci): jq→python + bump ext to 1.0.3 + rollback-on-upload-failure #18

Merged
bvandeusen merged 0 commits from dev into main 2026-05-25 23:14:51 -04:00
Conversation 0 Commits - Files Changed -
bvandeusen commented 2026-05-25 23:14:40 -04:00 (Migrated from git.fabledsword.com)
Copy Link
Copy Source

Why

PR #17's fix unblocked web-ext sign but the next step (upload signed XPI to a Forgejo ext-<version> cache release) failed:

+ jq -r .id release.json
/var/run/act/workflow/5.sh: 21: jq: not found

jq isn't in the ci-python:3.14 image and per ci-requirements.md we don't add image deps for single-consumer projects.

Worse, that failure ran AFTER the workflow had already POST'd a new empty ext-1.0.2 release to Forgejo — partial-failure state. AMO has v1.0.2 locked (signed but the XPI isn't in our cache), so the next workflow run would have done: cache-check sees release-exists-no-asset → AMO re-sign → 409 "Version already exists". Stuck.

Fix

  1. Replace jq with python3 for JSON parsing — ci-python has stdlib json. Single-line python3 -c "..." replaces both jq -r '.id' calls.
  2. Bump extension 1.0.2 → 1.0.3 to escape the AMO lock. v1.0.2 will sit signed-on-AMO-but-uncached forever; no real harm.
  3. Add rollback-on-upload-failure to the asset upload step. If asset upload returns non-2xx AND this run created the release (vs. found-existing), delete the just-created release + tag so the next run's cache-check correctly sees "no release" instead of the poison "release exists, no asset" state. Implemented via a bash trap.

Already cleaned up the orphaned ext-1.0.2 release manually via MCP (id 125 + tag deleted).

Expected post-merge

  1. build.yml runs on main
  2. sign-extension cache-check for ext-1.0.3 → no release → cache miss
  3. AMO sign for 1.0.3 succeeds (new version)
  4. Create ext-1.0.3 Forgejo release + upload signed XPI as asset (fabledcurator-1.0.3.xpi)
  5. build-web downloads artifact → bundles in frontend/public/extension/ → tags :main + :latest with XPI

Once green, I'll cut v26.05.25.6 to seal "v26.05.25.5 extension publish completed". The v26.05.25.5 tag stays where it is for historical record; v26.05.25.6 is the deployable.

🤖 Generated with Claude Code

## Why PR #17's fix unblocked `web-ext sign` but the next step (upload signed XPI to a Forgejo `ext-<version>` cache release) failed: ``` + jq -r .id release.json /var/run/act/workflow/5.sh: 21: jq: not found ``` `jq` isn't in the `ci-python:3.14` image and per `ci-requirements.md` we don't add image deps for single-consumer projects. Worse, that failure ran AFTER the workflow had already POST'd a new empty `ext-1.0.2` release to Forgejo — partial-failure state. AMO has v1.0.2 locked (signed but the XPI isn't in our cache), so the next workflow run would have done: cache-check sees release-exists-no-asset → AMO re-sign → 409 "Version already exists". Stuck. ## Fix 1. **Replace `jq` with `python3`** for JSON parsing — ci-python has stdlib `json`. Single-line `python3 -c "..."` replaces both `jq -r '.id'` calls. 2. **Bump extension 1.0.2 → 1.0.3** to escape the AMO lock. v1.0.2 will sit signed-on-AMO-but-uncached forever; no real harm. 3. **Add rollback-on-upload-failure** to the asset upload step. If asset upload returns non-2xx AND this run created the release (vs. found-existing), delete the just-created release + tag so the next run's cache-check correctly sees "no release" instead of the poison "release exists, no asset" state. Implemented via a bash trap. Already cleaned up the orphaned `ext-1.0.2` release manually via MCP (id 125 + tag deleted). ## Expected post-merge 1. `build.yml` runs on main 2. `sign-extension` cache-check for `ext-1.0.3` → no release → cache miss 3. AMO sign for 1.0.3 succeeds (new version) 4. Create `ext-1.0.3` Forgejo release + upload signed XPI as asset (`fabledcurator-1.0.3.xpi`) 5. `build-web` downloads artifact → bundles in `frontend/public/extension/` → tags `:main` + `:latest` with XPI Once green, I'll cut **v26.05.25.6** to seal "v26.05.25.5 extension publish completed". The v26.05.25.5 tag stays where it is for historical record; v26.05.25.6 is the deployable. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
bvandeusen
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bvandeusen/FabledCurator#18
Delete Branch "dev"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?