Feature: simulate publishing #2194
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@imsnif I'd be very happy if you could go through the steps in |
har7an
force-pushed
the
features/simulate-publish
branch
from
c502e17
to
375d030
Compare
that allow specifying a custom git remote to push to and a custom cargo registry to publish packages to.
because it's not meant to be released at all.
so we see what crate is currently being published, too.
because otherwise it tries to pick up the debug builds of the plugins, which aren't part of released version of `zellij utils`.
which explains how to simulate a zellij release.
because recent versions cause havoc in the release process in GitHub pipelines and it's primary goal is to only reduce binary size. Current rust versions seem to produce very compact wasm binaries themselves, though.
har7an
force-pushed
the
features/simulate-publish
branch
from
375d030
to
ad24cfb
Compare
joshheyse
pushed a commit
to joshheyse/zellij
that referenced
this pull request
Mar 11, 2023
* xtask: Add arguments to `publish` that allow specifying a custom git remote to push to and a custom cargo registry to publish packages to. * xtask/publish: Don't release `xtask` subcrate because it's not meant to be released at all. * xtask/publish: Add status messages to publish so we see what crate is currently being published, too. * xtask/publish: Disable default features on `zellij` because otherwise it tries to pick up the debug builds of the plugins, which aren't part of released version of `zellij utils`. * xtask/publish: Fix handling of custom registry * docs: Add `RELEASE.md` which explains how to simulate a zellij release. * xtask: Apply rustfmt * xtask: Remove `wasm-opt` from build steps because recent versions cause havoc in the release process in GitHub pipelines and it's primary goal is to only reduce binary size. Current rust versions seem to produce very compact wasm binaries themselves, though. * .github: Don't install wasm-opt in workflows
joshheyse
pushed a commit
to joshheyse/zellij
that referenced
this pull request
Mar 11, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rationale
Zellij is a complex application, consisting of multiple subcrates that need to be released/published separately, along with a few application assets such as plugins, which are usually bundled with the application. For this reasons, it has depended for a long time now on external build-tools such as
cargo-make/makers.Recent contributions to the project have necessitated a different handling of these application assets (in particular: The bundled plugin binaries, see #1924) and introduced a new build system,
xtask, to replace the previouscargo-makefor a plethora of reasons (See #2012). All of these changes, although not obvious at first glance, introduce risk and uncertainty to the release process.This is especially problematic because releasing a zellij version is not an atomic operation and can fail in the process, as it has a few times previously. Since there is no "undo"-button, a half-finished release sticks around and is visible for the public, although it is entirely unusable. Unfortunately, up until now, it is only possible to tell whether a release was successful after the release is performed. In turn, this means that a failure during release isn't uncovered until we're in the release process. This usually necessitates a decent amount of live-patching during the release process, as can be understood by looking at the release "history" between 0.34.0 and 0.34.3 (See 66593ec..67ac119).
This is both cumbersome to users and stressful to the maintainers responsible for the release. In order to alleviate this, I'm proposing this PR as a means to simulate a zellij release ahead of time.
Changes in this PR
This PR adds two new CLI flags to the
cargo xtask publishcommand:--git-remote: Allows specifying a git remote (other than the defaultorigin) to push release commits to. In conjunction with a privatezellijfork, this allows us to safely test release commits before we publish them to the main repository.--cargo-registry: Allows specifying a different cargo registry to publish the zellij subcrates to. Just like--git-remote, this allows us to push/publish crates somewhere else than into the maincrates.ioregistry.In combination with a private registry, these allow us to simulate a full release ahead of time. Because the procedure requires a lot of manual setup and isn't exactly trivial (yet?), there is now a new piece of documentation in
RELEASE.md, which explains how to set this up correctly.I hope that in the future, this will make releases frictionless, even in the face of significant changes to the build/plugin system.