Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
7 tasks
Unique-Divine opened this issue Nov 1, 2023 · 0 comments
Open
7 tasks

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

Unique-Divine opened this issue Nov 1, 2023 · 0 comments
Labels
ci GitHub actions or other continuous integration changes epic Project or large task that groups multiple tickets and PRs type: docs Improvements or additions to documentation type: enhancement New feature or request

Comments

@Unique-Divine
Copy link
Member

Unique-Divine commented Nov 1, 2023

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

@Unique-Divine Unique-Divine added type: docs Improvements or additions to documentation type: enhancement New feature or request epic Project or large task that groups multiple tickets and PRs ci GitHub actions or other continuous integration changes labels Nov 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci GitHub actions or other continuous integration changes epic Project or large task that groups multiple tickets and PRs type: docs Improvements or additions to documentation type: enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

1 participant