CD: tagged releases as Defold library dependency #13

New issue

Closed

opened 2026-08-19 07:05:40 +00:00 by yuris · 1 comment

yuris commented

2026-08-19 07:05:40 +00:00

Owner

Defold consumes libraries by URL pointing at a git ref, so "CD" here is release hygiene, not a deploy pipeline.

Decide tag scheme (v0.1.0) and what constitutes a releasable state (green CI + vertical slice playable)
Workflow on tag push: run full CI, then create a Forgejo release with notes
Verify a fresh Defold project can add https://git.nokopia.com/yuris/spacetimedb-defold/archive/v0.1.0.zip as a dependency and require("stdb")
Document the consumer snippet in README

Blocked on #2 — nothing worth tagging until the vertical slice runs.

Defold consumes libraries by URL pointing at a git ref, so "CD" here is release hygiene, not a deploy pipeline. - [ ] Decide tag scheme (`v0.1.0`) and what constitutes a releasable state (green CI + vertical slice playable) - [ ] Workflow on tag push: run full CI, then create a Forgejo release with notes - [ ] Verify a fresh Defold project can add `https://git.nokopia.com/yuris/spacetimedb-defold/archive/v0.1.0.zip` as a dependency and `require("stdb")` - [ ] Document the consumer snippet in README Blocked on #2 — nothing worth tagging until the vertical slice runs.

yuris added the

area:infra

phase:breadth

labels

2026-08-19 07:05:40 +00:00

yuris commented

2026-08-19 10:11:48 +00:00

Author

Owner

Closed in `394c228` + `8768170`. v0.1.0 is published.

https://git.nokopia.com/yuris/spacetimedb-defold/archive/v0.1.0.zip
https://github.com/defold/extension-websocket/archive/refs/tags/4.2.3.zip

Forgejo serves /archive/<tag>.zip for any tag, with or without a release object, so CD is just "push a tag". .forgejo/workflows/release.yml publishes the notes and gives the tag a page — curl-only, no nix, no toolchain, so it does not inherit the runner problems in #7.

Verified by actually consuming it

Not "the zip exists" — a separate project with no local copy of stdb/ anywhere, resolved with bob resolve, bundled headless, run in a real engine:

CONSUMER: has subscribe_query=true
CONSUMER: has unsubscribe=true
CONSUMER: has call_procedure=true
CONSUMER: decode_payload=hi
CONSUMER: rows=0
CONSUMER: OK

Two findings, both now in the README

1. Forgejo refuses basic auth for archive downloads. bob only speaks https://user:token@host/..., and gets a flat 404. Measured against the private repo:

auth form	status
`-u user:token` (basic)	404
`https://user:token@host/…`	404
`Authorization: token …` header	200
`?token=…` query param	200

So a private Forgejo library URL needs the token as a query parameter — the same shape Defold documents for GitLab. This is the one that would have silently blocked anyone trying to use a private repo.

2. Defold does not resolve dependencies transitively. A consumer listing only this SDK compiles fine and then fails at connect. Confirmed the failure is actionable rather than a nil deref, by building exactly that project:

CONSUMER: err=stdb/init.lua:70: extension-websocket missing: add it to game.project dependencies

Two bugs in the first release run, caught by reading the output

The notes were the commit message, not the tag annotation — this runner's actions/checkout materialises a lightweight tag, so git tag --format='%(contents:body)' silently falls back to the commit. Now read from /api/v1/repos/<repo>/tags/<tag>, and the checkout step is gone entirely.
github.server_url is the runner's internal address (http://<forgejo-host>:5858), so the published dependency URL pointed somewhere no user can reach. Public host hardcoded.

Re-tagged and re-ran to confirm both fixes landed in the actual release body.

## Closed in 394c228 + 8768170. **v0.1.0 is published.** ``` https://git.nokopia.com/yuris/spacetimedb-defold/archive/v0.1.0.zip https://github.com/defold/extension-websocket/archive/refs/tags/4.2.3.zip ``` Forgejo serves `/archive/<tag>.zip` for **any** tag, with or without a release object, so CD is just "push a tag". `.forgejo/workflows/release.yml` publishes the notes and gives the tag a page — curl-only, no nix, no toolchain, so it does not inherit the runner problems in #7. ## Verified by actually consuming it Not "the zip exists" — a separate project with **no local copy of `stdb/` anywhere**, resolved with `bob resolve`, bundled headless, run in a real engine: ``` CONSUMER: has subscribe_query=true CONSUMER: has unsubscribe=true CONSUMER: has call_procedure=true CONSUMER: decode_payload=hi CONSUMER: rows=0 CONSUMER: OK ``` ## Two findings, both now in the README **1. Forgejo refuses basic auth for archive downloads.** bob only speaks `https://user:token@host/...`, and gets a flat 404. Measured against the private repo: | auth form | status | |---|---| | `-u user:token` (basic) | **404** | | `https://user:token@host/…` | **404** | | `Authorization: token …` header | 200 | | `?token=…` query param | 200 | So a private Forgejo library URL needs the token as a **query parameter** — the same shape Defold documents for GitLab. This is the one that would have silently blocked anyone trying to use a private repo. **2. Defold does not resolve dependencies transitively.** A consumer listing only this SDK compiles fine and then fails at `connect`. Confirmed the failure is actionable rather than a nil deref, by building exactly that project: ``` CONSUMER: err=stdb/init.lua:70: extension-websocket missing: add it to game.project dependencies ``` ## Two bugs in the first release run, caught by reading the output 1. The notes were the **commit message**, not the tag annotation — this runner's `actions/checkout` materialises a *lightweight* tag, so `git tag --format='%(contents:body)'` silently falls back to the commit. Now read from `/api/v1/repos/<repo>/tags/<tag>`, and the checkout step is gone entirely. 2. `github.server_url` is the runner's **internal** address (`http://<forgejo-host>:5858`), so the published dependency URL pointed somewhere no user can reach. Public host hardcoded. Re-tagged and re-ran to confirm both fixes landed in the actual release body.

yuris closed this issue

2026-08-19 10:11:49 +00:00

yuris referenced this issue

2026-08-19 12:07:19 +00:00

Documentation: SDK usage + API reference #12