Lexicon Garden

at.happyproto.registry.publishRelease

Publish a version of a plugin to the caller's repo. Writes a software.release.manifest carrying the artifact, the changelog as a site.standard.document when one is given, the software.release.version, and the channel named by track, moved to the new version, in that order. A record is written only once everything it points at exists, so a failure part-way leaves no dangling reference. Calling again with the same input after such a failure finishes the release rather than refusing it.

Repository @happyproto.at did:plc:mo7vq4jbioxwafy5zkcc3eux namespace authority
Details · procedure
Kindprocedure
Authorityregistry.happyproto.at
Indexed

Showing version bafyreiccjd6dykih6i6yj2heb6jyzceinjqv7ibyxpkqxzso5ejg3v34pq. Show the latest

Compare Edit in builder → Fork →

Procedure

procedure · POST

Input

application/json

artifact

requiredref

The plugin. Every blob it references must already be uploaded to the caller's repo.

Reference

changelog

string

Release notes as CommonMark. The registry writes them to the caller's repo as a site.standard.document and links it from the version.

  • maxLength: 200000
  • maxGraphemes: 20000

name

requiredstring

The project's name, which is the record key of its software.release.project: 1 to 64 lowercase letters, digits and interior hyphens.

  • minLength: 1
  • maxLength: 64

track

requiredstring

The channel to move to the new version.

  • knownValues: latest | beta | alpha

validateOnly

boolean

Check the input against every rule the registry applies, and write nothing. Works without authentication, but only a signed-in call is also checked against the caller's existing records.

  • default: false

version

requiredstring

A semver version without build metadata, with an optional lowercase prerelease, such as `1.2.0` or `1.2.0-beta.1`.

  • minLength: 1
  • maxLength: 64

Output

application/json

changelog

ref

The changelog's site.standard.document, when a changelog was given.

Reference

channel

ref

The software.release.channel. Absent when validateOnly was set.

Reference

manifest

ref

The software.release.manifest. Absent when validateOnly was set.

Reference

resumed

boolean

True when the version already existed with this artifact, so this call only finished what an earlier one started.

valid

requiredboolean

Always true; invalid input is an error, not a result.

version

ref

The software.release.version. Absent when validateOnly was set.

Reference

Errors

AuthRequired

The caller's identity could not be determined, so there is no repo to write to.

NotConfigured

The registry has no identity configured. An operator problem, not a caller's.

InvalidRecord

The input breaks a rule the registry applies, so it would refuse the records. The message names the field.

InvalidRequest

The input breaks the method's lexicon, such as a field of the wrong format or past its length, and HappyView refused it before the registry saw it. The message names the field.

Upstream

A record could not be written to the caller's repo. Records written before the failure stay, and the same call can be made again.

ProjectMissing

The caller has no project of that name, or the registry has not indexed its at.happyproto.registry.project record. Call putProject first.

VersionExists

That version is already published with a different artifact. A version never changes once published; publish a new one.

NotInstallable

The project is unavailable or retired, so the channel cannot be moved to a new version.

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • at.happyproto.registry.promoteRelease

    procedure

    Publish an existing version's artifact under a new version, such as `1.2.0-rc.1` as `1.2.0`, without uploading it again. The new software.release.version points at the existing manifest. Optionally moves a channel to it and adds a changelog.

  • at.happyproto.registry.putProject

    procedure

    Create or update a plugin project in the caller's repo. The first call writes the site.standard.publication, the at.happyproto.registry.project and the software.release.project, in that order, so each is indexed after what it depends on. Later calls update the publication and the at.happyproto.registry.project only; the project record itself is never changed.

  • at.happyproto.plugin.release

    record

    One version of a package. The record key is '<slug>:<version>'. A release at a given version is never modified: a registry that later sees a different CID at this key keeps the first and flags the conflict.

  • at.happyproto.registry.project

    record

    The HappyView facts about a software.release.project that make it a plugin. The record key is the project's name, and the record lives in the same repo as the project. The registry indexes a project's releases only while this record exists and is valid.

  • at.happyproto.registry.withdrawRelease

    procedure

    Delete a release record the caller published. This is how a publisher withdraws a release: it deletes from the caller's own repo as them, where com.atproto.repo.deleteRecord sent through a HappyView instance goes wherever that instance's proxy routing points. The release stays indexed and served by exact version, marked withdrawn, and the version can never be published again.