Stream: git-wasmtime

Topic: wasmtime / PR #2936 ci: Remove "publish" step

Wasmtime GitHub notifications bot (May 25 2021 at 16:28):

alexcrichton opened PR #2936 from rm-publish-for-realz to main:

This commit removes the publish step in GitHub actions, insteading
folding all functionality into the release build steps. This avoids
having a separately scheduled job after all the release build jobs which
ends up getting delayed for quite a long time given the current
scheduling algorithm.

This involves refactoring the tarball assembly scripts and refactoring the
github asset upload script too. Tarball assembly now manages everything
internally and does platform-specific bits where necessary. The upload
script is restructured to be run in parallel (in theory) and hopefully
catches various errors and tries to not stomp over everyone else's work.
The main trickiness here is handling dev, which is less critical for
correctness than than tags themselves.

As a small tweak build-wise the QEMU build for cross-compiled builders
is now cached unlike before where it was unconditionally built, shaving
a minute or two off build time.

<!--

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

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

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

Wasmtime GitHub notifications bot (May 25 2021 at 16:59):

alexcrichton updated PR #2936 from rm-publish-for-realz to main.

Wasmtime GitHub notifications bot (May 25 2021 at 17:29):

cfallin submitted PR review.

Wasmtime GitHub notifications bot (May 25 2021 at 17:29):

cfallin created PR review comment:

Is it worth distinguishing the "tag already exists because race" case from other error cases? There's a potential that e.g. a network hiccup is taken as a collision and we end up without a dev release, otherwise, I think. Perhaps it's not really worth worrying too much about; not sure (the dev release is certainly less important than named releases).

Wasmtime GitHub notifications bot (May 25 2021 at 17:29):

cfallin submitted PR review.

Wasmtime GitHub notifications bot (May 25 2021 at 17:29):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (May 25 2021 at 17:40):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (May 25 2021 at 17:40):

alexcrichton created PR review comment:

I don't currently know how to handle the right errors (it feels like it's just a bunch of string matching?), but I figured that it's always possible to inject more JS later to figure this out if it becomes an issue. I don't think it's as easy as like if (e instanceof TheErrorWeCareAbout) since I think we'd have to inspect the error which is just the JSON response and figure out the cause of the error from that.

Wasmtime GitHub notifications bot (May 25 2021 at 17:52):

alexcrichton merged PR #2936.

Last updated: Nov 22 2024 at 16:03 UTC