Skip to content

v0.1.4 — verify-build CI hardening and safe-plugin-update poll correctness

Choose a tag to compare

@Gmulti Gmulti released this 15 May 04:44
· 17 commits to develop since this release
7115c87

Patch release. Closes the three remaining v0.1.0 read-through findings (#1, #2, #4).

CI — verify-build runs on develop (#1)

verify-build triggered on pushes to main, but the repository's default branch is develop. Direct pushes to develop (doc fixes, release prep, maintainer rebases) skipped build verification, so skills/ drift could land on the default branch unnoticed until the next PR happened to touch it.

Trigger now covers both branches:

 on:
   push:
-    branches: [main]
+    branches: [main, develop]
   pull_request:

CI — drift check catches untracked files (#2)

git diff --quiet -- skills/ only inspects tracked files, so a brand-new file under skills/ (e.g. a freshly added workflow) was invisible to the check. CI passed green even when the contributor forgot to commit the new file.

The check now uses git status --porcelain, which surfaces untracked, modified, and deleted entries:

-          if ! git diff --quiet -- skills/; then
+          DRIFT=$(git status --porcelain -- skills/)
+          if [ -n "$DRIFT" ]; then
             echo "::error::skills/ is out of sync with src/. Run 'scripts/build.sh' and commit the regenerated output."
+            echo "Drift detected:"
+            echo "$DRIFT"
+            git diff -- skills/
             exit 1
           fi

Reliability — safe-plugin-update polling matches terminal codes only (#4)

Step 6 of safe-plugin-update exited the poll loop as soon as .code was any non-empty value. The /processes status enum in openapi-public.json includes pending, so a queued process surfaces a non-empty but non-terminal code — the loop could declare success while the update was still running, and the workflow would proceed to "verify and report" against an in-flight operation.

The poll now matches terminal codes explicitly via case, with missing .code defaulting to pending so the still-running signal is unambiguous:

-    | jq -r ".data[] | select(.id==\"$PROCESS_ID\") | .code // empty")
-  if [ -n "$STATUS" ]; then
-    echo "Process finished with code: $STATUS"
-    break
-  fi
-  sleep 5
+    | jq -r ".data[] | select(.id==\"$PROCESS_ID\") | .code // \"pending\"")
+  case "$STATUS" in
+    success|failed|finished)
+      echo "Process finished with code: $STATUS"
+      break
+      ;;
+    *)
+      sleep 5
+      ;;
+  esac

SKILL.md section 6 now documents the canonical terminal codes (success, failed, finished) so future workflow authors do not re-introduce the bug.

Install / update

/plugin update umbrella@wp-umbrella

Full changelog: v0.1.3...v0.1.4