ci: document and script the release process#295
Conversation
Previously, the release process for wasi-sdk was undocumented and manual. The `RELEASING.md` document in this commit describes the steps necessary to publish a new version of `wasi-sdk` as a GitHub release and provides helpful scripts to automate some of the steps. With this in place, a future change could add a workflow trigger that allows running the steps automatically in GitHub actions. Keeping the steps as scripts in the repository, however, allows developers to re-run steps themselves in the (likely) case that something goes awry.
sbc100
left a comment
sbc100
left a comment
There was a problem hiding this comment.
Wow, nice work. I didn't get a chance to review those new scripts but this looks like a create step forward.
| @@ -0,0 +1,71 @@ | |||
| #!/usr/bin/env bash | |||
There was a problem hiding this comment.
Did you write all these new shell scripts from scratch?
Do you expect these scripts to run during ci? If not perhaps they should just live under scripts/ or at the top level like the rest of the current .sh scripts?
There was a problem hiding this comment.
Yes, I wrote them as I fought through issues with CI/Git/GitHub while trying to publish the wasi-sdk-20+threads pre-release (it was a fight: not every CI run has the right tag applied, e.g.). I had to do things enough times that this work already paid for itself, but in the back of my head it seemed like a good idea to record how one might publish new wasi-sdk releases. I was hoping at some point to integrate these in CI with a GitHub workflow trigger but that could be done later. I don't mind moving them to scripts or the top-level directory... tell me which is best and I'll move them. (Maybe we move all the *.sh files to scripts?).
There was a problem hiding this comment.
I talked to @sunfishcode a bit more about this kind of PR and I think I'm going to go ahead and merge soon; @sbc100, any strong preference on where to put these scripts?
| # -1 prints each file on a separate line | ||
| # -n1 runs the command once for each item | ||
| # -q means quietly | ||
| # -o allows unzip to overwrite existing files (e.g., multiple copies of `libclang_rt.builtins-wasm32-wasi-...`) |
There was a problem hiding this comment.
for linux, assets from the docker job should be used.
btw, please fix the linux assets for wasi-sdk-20+threads.
There was a problem hiding this comment.
I'm not sure I understand why?
There was a problem hiding this comment.
assets from ubuntu job (dist-ubuntu-latest) requires newer glibc.
assets from docker job (dist-ubuntu-bionic) is compatible with wider distributions.
| WORKFLOW_RUN_ID=$2 | ||
| GITHUB_TOKEN=$3 | ||
| GITHUB_API_VERSION=2022-11-28 | ||
| GITHUB_API_URL=https://api.github.com/repos/WebAssembly/wasi-sdk |
There was a problem hiding this comment.
why do you prefer to have a low-level script here while there are many handy commands/scripts (eg. hub) and even github actions available?
There was a problem hiding this comment.
Not everyone has all of that installed; I went with an environment I thought @sunfishcode would like 😁. (The idea was that these scripts would be runnable both from CI or from a maintainer's shell if something goes wrong).
There was a problem hiding this comment.
i suspect it's easier to install one of them than maintaining this script by ourselves. but i don't insist.
- Fix utimensat to avoid passing uninitialized values into WASI calls. - Optimize memcpy etc. using bulk-memory - Update to musl 1.2.3. - Fix `gettimeofday` to correctly handle a null argument. - Remove support for `__original_main`. (WebAssembly#295)
3 participants
Previously, the release process for wasi-sdk was undocumented and manual. The
RELEASING.mddocument in this commit describes the steps necessary to publish a new version ofwasi-sdkas a GitHub release and provides helpful scripts to automate some of the steps.With this in place, a future change could add a workflow trigger that allows running the steps automatically in GitHub actions. Keeping the steps as scripts in the repository, however, allows developers to re-run steps themselves in the (likely) case that something goes awry.