Stream: git-wasmtime

Topic: wasmtime / PR #4055 Fix the release process's latest step


view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 14:38):

alexcrichton edited PR #4055 from fix-release to main:

The automated release of 0.36.0 was attempted last night but it failed
due to a [failure on CI][bad]. This failure comes about because it was
trying to change the release date of 0.35.0 which ended up not modifying
any fails so git failed to commit as no files were changed.

The original bug though was that 0.35.0 was being changed instead of
0.36.0. The reason for this is that the script used
--sort=-committerdate to determine the latest branch. I forgot,
though, that with backports it's possible for 0.35.0 to have a more
recent commit date than 0.36.0 (as is currently the case). This commit
updates the script to perform a numerical sort outside of git to get the
latest release branch.

Additionally this adds in some set -ex commands for the shell which
should help print out commands as they're run and assist in future
debugging.

[bad]: https://github.com/bytecodealliance/wasmtime/runs/6087188708

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

Please ensure all communication adheres to the code of conduct.
-->

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 14:39):

alexcrichton updated PR #4055 from fix-release to main.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 14:40):

alexcrichton requested cfallin for a review on PR #4055.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 16:16):

cfallin submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 16:16):

cfallin created PR review comment:

Unfortunately I don't think the -n on sort does what we want here, if we're dealing with semvers rather than plain integers. I just tested with an input of

0.1.0
0.10.0
0.2.0

and sort -n -r on that gives 0.2.0, 0.10.0, 0.1.0 for me.

We have all two-digit versions for now so it will kind of work but this will bite us if/when we hit three-digit or go back to one-digit versions...

I know this is a big ask, but the complexity here is starting to get to the point where I might wonder if it would be better to write a small Rust script that understands versions, and is more resilient than sed commands on magic strings?

Alternately I don't think it's a huge deal to ask a human to edit the date in a final PR, compared to the effort and risk that goes into automating the last mile here...

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 16:16):

cfallin submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 17:33):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 17:33):

alexcrichton created PR review comment:

Ok yeah if the "obvious" (that's in quotes because nothing about bash is obvious) thing isn't working I definitely agree it's time to use a Real Language.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 17:43):

alexcrichton updated PR #4055 from fix-release to main.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 18:28):

cfallin submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 18:31):

alexcrichton merged PR #4055.


Last updated: Dec 23 2024 at 12:05 UTC