Skip to main content
Slopsentral uses one product version for authored plugins, checkout tooling, and provider archives. package.json owns that version. Release Please proposes one patch increment for the root component. Dependency pins and schema revisions keep separate versions. A release promotes tested retained bytes. Publication never rebuilds the candidates or replaces conflicting existing assets. The release concept explains the source-to-artifact relationship.

Version PRs and publication

  1. A main push starts Validate Source for its exact source revision.
  2. Successful qualification keeps provider archives, the Pi package, installer assets, and source-bound receipts.
  3. Release Slopsentral admits an unpublished shared version from a successful main run.
  4. The publisher admits the original producer and every candidate digest.
  5. It publishes those bytes under slopsentral-vX.Y.Z.
  6. It examines actual downloads before the release becomes current.
  7. It completes the matching merged version PR’s labels.
  8. Release Please proposes the next version after a successful release workflow.
A successful release workflow can report that no new release is needed. Ordinary commits cannot republish an existing version. A failed main run keeps an unpublished increment pending for repair. Release Please version PRs have a separate admission rule. The PR must come from the configured App and advance one patch. Its exact head must pass both validation jobs. It can change only declared version files and CHANGELOG.md. Forks, drafts, stale heads, and mixed source changes fail admission. Ordinary code PRs keep their normal merge process. The App token makes a merged version PR trigger normal main validation. The publisher then uses the candidates from that source run. autorelease: pending remains until publication succeeds. Completion adds autorelease: tagged and removes the pending label. The matching PR must belong to the released source history. Release configuration owns the complete version-target set. It includes root npm and Python metadata, both lockfiles, canonical plugins, and marketplace plugin references. Generated provider trees are not version-update targets. A new plugin needs a declared version target. Publish Harnesses separately maintains provider branches and the Codex/Copilot trees on main. Those branches advance. A stable release archive remains immutable. Historical Pi 0.1.N releases also remain immutable. The unified version line starts at 4.0.1.

Required GitHub App setup

Release PR creation needs a repository-scoped GitHub App installed on amichne/slopsentral. Grant Contents, Pull requests, and Issues read/write access. The workflow needs no webhook, administration permission, or Actions-write permission. Store these values through GitHub’s private secret interface: The job creates a repository-scoped token and revokes it afterward. It does not reuse that token for release publication. The workflow has no fallback to GITHUB_TOKEN for version PR creation. Never put credentials in source, issues, or session text. A local workflow result cannot establish remote secret configuration. For an authorized retry on main, use:

Verification and recovery

For a release-policy change, run:
The updater test uses the action’s exact Release Please library version. It changes a disposable checkout and makes sure that uv accepts the resulting lock unchanged. Keep the dependency pin, action pin, and updater assertions aligned. A failed qualification run supplies no publication authority. If a version PR merges before failure, repair the cause through a normal PR. The next successful main run can publish that still-unpublished version. The publisher completes the original version PR even when the released source includes that repair. Interrupted publication can leave a tag or draft. Inspect that state before retry and preserve conflicting existing bytes. If publication succeeds but labels fail, examine downloads before the idempotent label-finalization operation. Do not remove a pending label to imply publication success. Version selection owns version and PR admission. Provider candidates, Pi candidates, and setup packaging own their receipts. The publisher workflow composes those owners. Setup receipts accept complete two-file, five-file, seven-file, and nine-file inventories. The seven-file inventory adds the canonical Kotlin detector and its lock. The nine-file inventory adds both audit modules. Partial inventories and duplicate filenames fail admission. Receipt schema 2 binds the version to package.json at the admitted source commit. Run identity and producer attempts remain separate facts. Use the Pi recovery guide for consumer rollback. Local tests establish policy and candidate behavior. An actual hosted run and download establish publication.