Struct HomebrewAdapter 

pub struct HomebrewAdapter { /* private fields */ }

The homebrew distribution adapter, operating as homebrew-tap or homebrew-core.

Implementations

impl HomebrewAdapter

pub fn new(adapter: Adapter) -> Self

Construct for a resolved homebrew adapter identity.

Trait Implementations

impl ReleaseAdapter for HomebrewAdapter

fn adapter(&self) -> Adapter

The adapter identity this implementation operates as (a single struct may back several related identities, e.g. cargo-publish and cargo-dist).

fn dry_run( &self, ctx: &EffectCtx<'_>, t: &AdapterTarget, ) -> Result<DryRunReport, AdapterError>

Re-runnable, side-effect-free preview: the exact commands a real cut would run for target.

fn build( &self, _ctx: &EffectCtx<'_>, _t: &AdapterTarget, ) -> Result<BuildArtifacts, AdapterError>

Re-runnable build of the target’s publishable artifacts.

fn publish( &self, ctx: &EffectCtx<'_>, t: &AdapterTarget, ) -> Result<PublishReceipt, AdapterError>

Per-target irreversible publish; returns the durable PublishReceipt.

fn verify( &self, _ctx: &EffectCtx<'_>, _receipt: &PublishReceipt, ) -> Result<VerifyOutcome, AdapterError>

Read-only remote reconcile of a receipt against registry state.

fn timeout(&self) -> Duration

Mandatory wall-clock ceiling for a single publish of this adapter — a hung publish must not wedge a run (ADR-0002 §1).

fn is_ci_delegated(&self) -> bool

Whether this adapter’s publish is CI-delegated — its release artifact is produced out-of-band by the tag-triggered CI (e.g. cargo-dist’s release.yml, a release-please merge job, PyPI’s trusted-publisher workflow), never by the engine’s publish step from this host. The coordinator skips such a target in publish-all (journalling a target_delegated fact) rather than calling publish and treating its honest AdapterError::Unsupported as a phase failure — which would leave the cut stuck after an irreversible crates.io publish.

fn ci_owns_github_release(&self) -> bool

Whether this adapter’s tag-triggered CI owns the shared GitHub Release — its workflow creates and finalizes the Release object (and uploads the cross-platform binaries into it), so the coordinator must NOT create the Release itself or the two clash over the same tag (coordinator-release-vs-cargo-dist-ownership).