Goal
Publish the compiled first-party opy-provider binaries and checksums as assets of the GitHub Release created by the same release-plz run.
Context
opy-provider is a repository-specific executable distributed alongside opy-rs releases for Wright's first-party provider resolver. The current implementation builds provider binaries in a separate tag-triggered workflow and then rediscovers/waits for the GitHub Release before uploading assets.
That creates an unnecessary second release lifecycle. release-plz already creates the tag and GitHub Release, and its action exposes whether a release was created plus the corresponding release metadata. The shared WrightKit release workflow should expose that generic information to callers; opy-rs can then build and attach its repository-specific binaries as downstream jobs of the same release flow.
Scope
- Consume the release result/metadata exposed by the shared release-plz workflow.
- When the opy-rs release is created, build the supported
opy-provider target matrix from that release revision.
- Attach each provider archive and matching
.sha256 file to the GitHub Release created by that release-plz run.
- Remove the separate tag-triggered provider release lifecycle once the integrated flow replaces it.
- Preserve the asset naming contract consumed by Wright's first-party provider resolver.
Non-goals
- No provider runtime or LPP changes.
- No OPY compiler/semantic changes.
- No Wright dependency or provider-resolution changes.
- No provider-specific logic in the shared
.github reusable workflow.
- No independent tag/release polling or rediscovery protocol.
- No redesign of release-plz versioning or crate publication.
Acceptance criteria
- Provider binary publication is downstream of the same release-plz invocation that creates the opy-rs GitHub Release.
- No separate
push.tags / release workflow is required solely to attach provider assets.
- No polling or fixed-delay wait is used to synchronize with GitHub Release creation.
- A release builds every supported provider target and attaches each archive plus its matching
.sha256 asset to that release.
- Published asset names remain compatible with Wright's first-party provider resolver.
- Runs where release-plz creates no release do not build or publish provider release assets.
- A subsequent release can repeat the complete flow without manual intervention.
Dependencies / ownership
Refs #170
Refs #175
Goal
Publish the compiled first-party
opy-providerbinaries and checksums as assets of the GitHub Release created by the same release-plz run.Context
opy-provideris a repository-specific executable distributed alongside opy-rs releases for Wright's first-party provider resolver. The current implementation builds provider binaries in a separate tag-triggered workflow and then rediscovers/waits for the GitHub Release before uploading assets.That creates an unnecessary second release lifecycle.
release-plzalready creates the tag and GitHub Release, and its action exposes whether a release was created plus the corresponding release metadata. The shared WrightKit release workflow should expose that generic information to callers; opy-rs can then build and attach its repository-specific binaries as downstream jobs of the same release flow.Scope
opy-providertarget matrix from that release revision..sha256file to the GitHub Release created by that release-plz run.Non-goals
.githubreusable workflow.Acceptance criteria
push.tags/releaseworkflow is required solely to attach provider assets..sha256asset to that release.Dependencies / ownership
wrightkit/.githubowns only the reusable release-plz output contract.opy-rsowns provider build, packaging, asset naming, and publication.Refs #170
Refs #175