Skip to content

epic(ci): tag-wise publishing for gh releases  #87

@Unique-Divine

Description

@Unique-Divine

Intro

Create a GitHub action appropriate for a Rust monorepo.

The setup used in the CosmWasm/cw-plus repo seems close to what we're looking for, but there are better-managed monorepos we can take cues from.

  • Rust code: Crates are expected to be on crates.io, so they aren't published with release assets. Because of crates have their own release, we don't need to try to manage everything through tags.
  • Release Assets: Instead of releasing crate-wise, releases are done tag-wise and include compiled Wasm bytecode for smart contracts along with schema.json files and other important generated assets.
  • Versioning: The tag/release versions do not follow strict semver rules because the contracts have different purposes and aren't necessarily versioned in sync.
    .

Core contracts

Contracts like "token-vesting", "nibi-stargate", "shifter", or ones for the Go bindings can be grouped together as "core contracts" and have grouped releases. This can help keep the versions more semnatic without coupling them too tightly to unrelated code.

Future smart contracts that become core or essential to the protocol can be kept here as well.

Completion Checklist

  • Create an initial manual release for the "core contracts" to identify what steps need to be included in the automation.
  • Decide on a scheme that makes sense based on the practices of MystenLabs/sui and aptos-labs/aptos-core. Aptos and Solana have releases that can have a scope, which seems to work well. Node changes can have a release. CLI changes can have a release, and packages can have a release, all in an independent and semver-compliant manner
  • As part of the publishing workflow:
    • Automate wasm bytecode generation
    • Automate schema generation
    • Add a manually testable version to scripts and the justfile.
  • Document this process in the repo somewhere in markdown

More on Versioning

The Cosmos-SDK repo has a clever convention for managing many dependencies in tandem by prefixing tags with a scope. For instance, tags for separate packages of cosmossdk.io are prefixed.

image

Metadata

Metadata

Assignees

No one assigned

    Labels

    ciGitHub actions or other continuous integration changesepicProject or large task that groups multiple tickets and PRstype: docsImprovements or additions to documentationtype: enhancementNew feature or request

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions