Use deterministic official plugin release tags #347

New issue

Closed

opened 2026-06-06 19:36:04 +00:00 by steve · 0 comments

steve commented

2026-06-06 19:36:04 +00:00

Owner

Problem

The app repo publishes many plugin versions into shared
official-plugin-assets-* releases. Even with targeted scanning, detecting
existing versions still requires release discovery and asset pagination. The
registry repo also defaults to scanning release pages before choosing the latest
asset per plugin.

Goal

Use one deterministic Forgejo/GitHub release tag per plugin version:
official-plugin-assets-<plugin-id>-<version>. Default publishing remains
duplicate-safe, while an explicit force flag can replace same-version assets for
repair workflows.

Scope

Update lapis-notes official plugin asset publishing and workflow behavior.
Update lapis-plugin-registry Forgejo sync so maintainers can pass exact
plugin@version pairs and avoid broad release scans.
Update relevant docs/spec pages in both repos.

Non-goals

Do not migrate existing batch-tagged release assets or registry URLs.
Do not change asset names, signed release manifest schema, or install-time
registry metadata shape.
Do not make overwriting the default path.

Acceptance Criteria

registry-assets:publish derives official-plugin-assets-<plugin-id>-<version>
for each selected plugin version and publishes each plugin/version to its own
release.
Existing plugin versions are checked by direct release-tag lookup rather than
repo-wide release scans.
--resume skips already-uploaded assets in the deterministic release.
--force-overwrite is accepted only with explicit --plugins, replaces
same-name assets, and logs the required registry re-sync/sign follow-up.
The Forgejo workflow no longer depends on a shared release tag for normal
operation and exposes a disabled-by-default force_overwrite input.
/Users/stevejuma/code/lapis-plugin-registry supports
registry:sync:forgejo -- --plugin-versions <plugin@version,...> and fetches
the matching deterministic tags directly.
Legacy batch-tag sync remains supported for historical releases.

Implementation Notes

Preserve existing dirty files in /Users/stevejuma/code/lapis-plugin-registry:
entries/official/lapis-markdown-lint.jsonc,
generated/v1/plugins/lapis-markdown-lint.json, and
generated/v1/plugins/lapis-markdown-lint.sig.
Keep GitHub mirror tags equal to the Forgejo deterministic tag.
Keep staged asset names and signed release manifest contents compatible with
existing registry verification.

Suggested Files or Specs To Inspect

scripts/publish-official-plugin-assets.mjs
scripts/publish-release-assets.mjs
.forgejo/workflows/publish-official-plugin-assets.yml
spec/src/80-maintenance/monorepo-scripts.md
spec/src/30-cross-package-contracts/plugin-registry.md
/Users/stevejuma/code/lapis-plugin-registry/scripts/sync-forgejo-releases.mjs
/Users/stevejuma/code/lapis-plugin-registry/docs/publishing-official-plugins.md

Validation Commands

pnpm test:scripts
pnpm check:all
mdbook build spec
In /Users/stevejuma/code/lapis-plugin-registry: pnpm test
In /Users/stevejuma/code/lapis-plugin-registry: pnpm check

Follow-up to #346 — Stabilize official plugin asset publish observability and memory usage

Follow-up Tasks

Implementation Summary

Fixed release helper script test-runner regressions by storing serializable request summaries in forgejo/github release tests and running the combined script test batch with --test-concurrency=1 to avoid Node worker deserialize failures in CI.

Reopen Reason

Fix Node 22 forgejo-release test-runner regression after deterministic release tag changes

Official plugin asset publication still uses shared batch release tags, which forces Forgejo release/asset scans to detect whether a plugin version is already published. Move future publishes to deterministic per-plugin-version tags and teach the registry sync repo to consume those tags directly. ## Problem The app repo publishes many plugin versions into shared `official-plugin-assets-*` releases. Even with targeted scanning, detecting existing versions still requires release discovery and asset pagination. The registry repo also defaults to scanning release pages before choosing the latest asset per plugin. ## Goal Use one deterministic Forgejo/GitHub release tag per plugin version: `official-plugin-assets-<plugin-id>-<version>`. Default publishing remains duplicate-safe, while an explicit force flag can replace same-version assets for repair workflows. ## Scope - Update `lapis-notes` official plugin asset publishing and workflow behavior. - Update `lapis-plugin-registry` Forgejo sync so maintainers can pass exact `plugin@version` pairs and avoid broad release scans. - Update relevant docs/spec pages in both repos. ## Non-goals - Do not migrate existing batch-tagged release assets or registry URLs. - Do not change asset names, signed release manifest schema, or install-time registry metadata shape. - Do not make overwriting the default path. ## Acceptance Criteria - `registry-assets:publish` derives `official-plugin-assets-<plugin-id>-<version>` for each selected plugin version and publishes each plugin/version to its own release. - Existing plugin versions are checked by direct release-tag lookup rather than repo-wide release scans. - `--resume` skips already-uploaded assets in the deterministic release. - `--force-overwrite` is accepted only with explicit `--plugins`, replaces same-name assets, and logs the required registry re-sync/sign follow-up. - The Forgejo workflow no longer depends on a shared release tag for normal operation and exposes a disabled-by-default `force_overwrite` input. - `/Users/stevejuma/code/lapis-plugin-registry` supports `registry:sync:forgejo -- --plugin-versions <plugin@version,...>` and fetches the matching deterministic tags directly. - Legacy batch-tag sync remains supported for historical releases. ## Implementation Notes - Preserve existing dirty files in `/Users/stevejuma/code/lapis-plugin-registry`: `entries/official/lapis-markdown-lint.jsonc`, `generated/v1/plugins/lapis-markdown-lint.json`, and `generated/v1/plugins/lapis-markdown-lint.sig`. - Keep GitHub mirror tags equal to the Forgejo deterministic tag. - Keep staged asset names and signed release manifest contents compatible with existing registry verification. ## Suggested Files or Specs To Inspect - `scripts/publish-official-plugin-assets.mjs` - `scripts/publish-release-assets.mjs` - `.forgejo/workflows/publish-official-plugin-assets.yml` - `spec/src/80-maintenance/monorepo-scripts.md` - `spec/src/30-cross-package-contracts/plugin-registry.md` - `/Users/stevejuma/code/lapis-plugin-registry/scripts/sync-forgejo-releases.mjs` - `/Users/stevejuma/code/lapis-plugin-registry/docs/publishing-official-plugins.md` ## Validation Commands - `pnpm test:scripts` - `pnpm check:all` - `mdbook build spec` - In `/Users/stevejuma/code/lapis-plugin-registry`: `pnpm test` - In `/Users/stevejuma/code/lapis-plugin-registry`: `pnpm check` ## Related Issues - Follow-up to #346 — [Stabilize official plugin asset publish observability and memory usage](../closed/346-stabilize-official-plugin-asset-publish-observability-and-memory-usage.md) ## Follow-up Tasks ## Implementation Summary Fixed release helper script test-runner regressions by storing serializable request summaries in forgejo/github release tests and running the combined script test batch with --test-concurrency=1 to avoid Node worker deserialize failures in CI. ## Reopen Reason Fix Node 22 forgejo-release test-runner regression after deterministic release tag changes

steve added this to the Full Registry V1 milestone

2026-06-06 19:36:04 +00:00

steve

2026-06-06 19:36:04 +00:00