feat(extension)!: retarget fork at own Forgejo repository and add release pipeline #5

Merged

YoshuFGJ merged 5 commits from forgejo-extension-releases into master

2026-09-01 00:26:35 +00:00

YoshuFGJ commented

2026-08-31 23:08:48 +00:00

Owner

Points this fork's metadata at its own Forgejo repository and adds a release pipeline so Blender can check for updates against it.

Extension identity

website and the preferences panel link now point at this fork; a second button keeps a link to upstream.
The extension id becomes textools_fork, so this fork and an upstream TexTools install no longer collide as the same extension. This makes Blender treat it as a new extension: existing installs must be removed and reinstalled.
Enabling this fork and upstream simultaneously still conflicts at runtime (shared texToolsSettings, operator bl_idnames and panel category). The id only separates their identity, not their registration.
Bumped to 1.7.1. SemVer has no granularity below PATCH: build metadata is ignored when comparing versions and pre-releases rank below the matching release, so any published change is a patch bump.

Release pipeline

Pushing a v* tag builds the extension and publishes two releases:

Release	Contents	Purpose
`v<version>`	the extension zip	keeps old builds downloadable
`latest`	zip + `index.json`	the extension repository Blender polls; rewritten each run

The rolling latest release exists so the index URL never changes between versions. server-generate writes a relative archive_url, which is why the index and its zip must share a release.

The workflow refuses to publish when the tag and the manifest version disagree, so the two cannot drift.

Runner notes

Runs on debian:bookworm-slim rather than an act image: replacing actions/checkout with a plain git clone removes the only JavaScript action, so the container needs no Node and drops from ~1GB to ~30MB. Blender remains the dominant cost at 366MB per run; its checksum is verified and bundled assets are skipped on extraction.

A first tagged run surfaced one bug, fixed here: GITHUB_SERVER_URL resolves to the instance's internal address (http://forgejo:3000), which job containers cannot reach, so the clone and API calls use the public URL instead.

Points this fork's metadata at its own Forgejo repository and adds a release pipeline so Blender can check for updates against it. ## Extension identity - `website` and the preferences panel link now point at this fork; a second button keeps a link to upstream. - The extension id becomes `textools_fork`, so this fork and an upstream TexTools install no longer collide as the same extension. **This makes Blender treat it as a new extension: existing installs must be removed and reinstalled.** - Enabling this fork *and* upstream simultaneously still conflicts at runtime (shared `texToolsSettings`, operator `bl_idname`s and panel category). The id only separates their identity, not their registration. - Bumped to 1.7.1. SemVer has no granularity below PATCH: build metadata is ignored when comparing versions and pre-releases rank below the matching release, so any published change is a patch bump. ## Release pipeline Pushing a `v*` tag builds the extension and publishes two releases: | Release | Contents | Purpose | | --- | --- | --- | | `v<version>` | the extension zip | keeps old builds downloadable | | `latest` | zip + `index.json` | the extension repository Blender polls; rewritten each run | The rolling `latest` release exists so the index URL never changes between versions. `server-generate` writes a *relative* `archive_url`, which is why the index and its zip must share a release. The workflow refuses to publish when the tag and the manifest version disagree, so the two cannot drift. ## Runner notes Runs on `debian:bookworm-slim` rather than an act image: replacing `actions/checkout` with a plain `git clone` removes the only JavaScript action, so the container needs no Node and drops from ~1GB to ~30MB. Blender remains the dominant cost at 366MB per run; its checksum is verified and bundled assets are skipped on extraction. A first tagged run surfaced one bug, fixed here: `GITHUB_SERVER_URL` resolves to the instance's internal address (`http://forgejo:3000`), which job containers cannot reach, so the clone and API calls use the public URL instead.

YoshuFGJ added 4 commits

2026-08-31 23:08:49 +00:00

🔖 feat(extension)!: point fork at own Forgejo repository 4482c40125

Retarget the fork's metadata at git.villapinkhouse.com instead of the
upstream GitHub repositories, and rename the extension id to
textools_fork so this fork and an upstream TexTools install no longer
collide as the same extension.

The id change makes Blender treat this as a new extension: existing
installs must be removed and reinstalled. Note that enabling both this
fork and upstream at once still conflicts at runtime (shared
texToolsSettings, operator bl_idnames and panel category) - the id only
separates their identity, not their registration.

Document the fork status and the two installation paths in the README,
including that only extensions installed from a remote repository are
ever checked for updates.

Bump to 1.7.1: SemVer has no granularity below PATCH, build metadata is
ignored when comparing versions and pre-releases rank below the matching
release, so any published change is a patch bump.

👷 ci(forgejo): publish releases to a Blender extension repository 7aa1f51f04

Build the extension and publish it on every v* tag, so Blender can check
for updates against this repository.

Each run publishes two releases: v<version> keeps the versioned zip, and
latest is rewritten with the zip plus index.json. The rolling latest
release exists so the index URL Blender polls never changes between
versions; server-generate writes a relative archive_url, which is why the
index and its zip must share a release.

The workflow refuses to publish when the tag and the manifest version
disagree, so the two cannot drift.

Run on debian:bookworm-slim rather than an act image: replacing
actions/checkout with a plain git clone removes the only JavaScript
action, so the container no longer needs Node and drops from ~1GB to
~30MB. Blender itself stays the dominant cost at 366MB per run; its
checksum is verified and the bundled assets are skipped on extraction.

Exclude /.forgejo/ from the built zip alongside the other tooling paths.

🗃️ chore(graph): refresh knowledge graph

Build and publish extension / release (push) Failing after 27s

Details

2fdd020c1d

Regenerated with graphify update after the manifest and panel changes.

🐛 fix(ci): clone and call the API over the public instance URL 4b38d097f2

The first tagged run failed at checkout: GITHUB_SERVER_URL resolves to the
instance's internal address (http://forgejo:3000), and the job container
sits on a different Docker network, so the hostname does not resolve.

Point the clone and the release API calls at the instance's public URL
instead. publish.py still falls back to GITHUB_SERVER_URL when SERVER_URL
is unset.

YoshuFGJ added 1 commit

2026-08-31 23:16:07 +00:00

👷 ci(forgejo): fail fast when the instance is unreachable 79fe751571

Runners are isolated in their own network zone with no route to the
instance's Docker network, so they reach Forgejo over its public URL and
depend on NAT loopback being in place.

Check that path before cloning and report what to look at, instead of
surfacing a bare DNS or connection error.

YoshuFGJ force-pushed forgejo-extension-releases from 79fe751571 to 9444c4f150

2026-09-01 00:24:02 +00:00

Compare

YoshuFGJ self-assigned this

2026-09-01 00:26:25 +00:00

YoshuFGJ merged commit 98007295b3 into master

2026-09-01 00:26:35 +00:00

YoshuFGJ referenced this pull request from a commit

2026-09-01 00:26:35 +00:00

Merge pull request 'feat(extension)!: retarget fork at own Forgejo repository and add release pipeline' (#5) from forgejo-extension-releases into master

YoshuFGJ deleted branch forgejo-extension-releases

2026-09-01 00:26:35 +00:00