Tags: busabase/busabase
Tags
test(server): point the archived-Base e2e at the status page it now r… …enders An archived node's URL used to fall through to the Trash list; it now resolves to a dedicated status page carrying the node's name and a Restore action, so the spec's "Trash" heading no longer exists at that URL. Scopes the name assertion to that status page (the breadcrumb names the archived node too, so an unscoped match resolves to two elements) and adds the Restore assertion the spec's own comment implies but never checked.
ci(release): cut a GitHub Release once npm + Docker artifacts exist (#49 ) The releases page currently shows two orphan tags cut on 2026-08-26 (v0.19.1, v0.19.2) while npm ships 0.40.1 — it understates the project by 21 minor versions. That reads as "barely released" to anyone assessing maturity, and after a listing lands, curated lists like awesome-selfhosted read `current_release` from that page and flag live projects as unmaintained. This is a third workflow rather than a step at the end of publish-npm.yml because `Publish npm` and `Docker` are independent workflows with different path filters — a commit under apps/busabase-cli/** runs only the first. Appending a release to either would announce artifacts that do not exist yet. Instead it runs after EITHER completes and gates on the artifacts themselves: the release is created only once busabase@<version> is on npm AND the matching Docker Hub tag exists. Whichever workflow finishes last finds both and cuts the release; the earlier one no-ops. No barrier, so a single-workflow commit still releases. Idempotent like the rest of this repo's publishing: an existing release exits 0. Tags the commit the triggering run actually built, not the branch tip. Nothing is backfilled — GitHub cannot backdate published_at, so backfilled releases would all claim today's date and misrepresent the history more than their absence does. Co-authored-by: Claude Opus 5 <[email protected]>
PreviousNext