Changes in release-process.yml

7cca98e5 - Update some github actions versions (#12762)

Wed, 11 Mar 2026 19:46:02 +0000

Update some github actions versions (#12762)CI is warning us about these, so try updating. List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

df89aa5b - Explicitly require write permissions on release process (#9198)

Thu, 05 Sep 2024 14:31:04 +0000

Explicitly require write permissions on release process (#9198)The default token for this repository is now read-only but this workflowneeds writable permissions. Local testing seems to show that this shouldwork so let's try it out here. List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

14226457 - Refactor how release notes are managed (#8680)

Thu, 23 May 2024 16:35:23 +0000

Refactor how release notes are managed (#8680)* Refactor how release notes are managedThis commit updates how Wasmtime manages release notes across releasedversions of Wasmtime. One of the most onerous parts about releases rightnow is writing release notes in all the locations and making surethey're all up-to-date and in-sync. This is inevitably forgotten in somecases and various pieces will slip through the cracks. The basic idea ofthis PR is to change our release notes to only document the releasebranch that they're on. All historical release notes are relegated tohistorical branches.With this change there's no longer any need to backport or forward-portrelease notes for any changes. Instead release notes are written onceon one branch and that's it.The major downside of this change is that there's no easy way to get abird's eye view of all release notes for Wasmtime any more. If necessarythat could theoretically be automated in the future (likehttps://releases.rs/), but for now this feels like an acceptablecompromise to make releases much easier.The contents of this PR are to update `RELEASES.md` with back-links tohistorical release notes as well as the various pieces of automation wehave about managing release notes.* Add more notes about the release process* Fix a typo* Make it more obvious that patch releases are documented List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

f3d31342 - ci: format descriptions for PR’s (#7959)

Tue, 20 Feb 2024 15:38:18 +0000

ci: format descriptions for PR’s (#7959)The construction before was readable in the GitHub Action itself, but IMO the descriptions in the [opened PR’s](https://github.com/bytecodealliance/wasmtime/pull/7958) are not as pretty to read. This will fix this by making every sentence on one line. List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

849b2fca - ci: Update to `actions/checkout@v4` from `v3`. (#7674)

Tue, 12 Dec 2023 15:18:20 +0000

ci: Update to `actions/checkout@v4` from `v3`. (#7674)This mainly updates to use Node 20 rather than Node 16 internally. List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

c6201624 - Update vet metadata on patch releases (#6903)

Thu, 24 Aug 2023 17:58:12 +0000

Update vet metadata on patch releases (#6903)This should fix the CI error that cropped up on #6901 List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

860d46b4 - Run `cargo vet` on automated version bumps (#6687)

Wed, 05 Jul 2023 15:38:59 +0000

Run `cargo vet` on automated version bumps (#6687)* Run `cargo vet` on automated version bumpsAs shown in the original CI of #6686 the recent changes for `cargo vet`0.8.0 mean that the previous release process no longer works since itrequires changes to the lock file for `cargo vet`. This updates theversion bumping process to run `cargo vet` as part of the committedchanges which hopefully will get everything to succeed. To ensure thatthe same version of `cargo vet` is used in both locations theinstallation procedure was extracted into its own separate little action.* Configure shell to run in List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

15b2c90b - Update submodules as part of the release process (#6425)

Mon, 22 May 2023 15:55:03 +0000

Update submodules as part of the release process (#6425)Avoids an accidental submodule reset as shown in #6418 hopefully. List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

1efee4ab - Update CI to use GitHub's Merge Queue (#5766)

Thu, 16 Feb 2023 19:18:42 +0000

Update CI to use GitHub's Merge Queue (#5766)GitHub recently made its merge queue feature available for use in publicrepositories owned by organizations meaning that the Wasmtime repositoryis a candidate for using this. GitHub's Merge Queue feature is a systemthat's similar to Rust's bors integration where PRs are tested beforemerging and only passing PRs are merged. This implements the "not rocketscience" rule where the `main` branch of Wasmtime, for example, isalways tested and passes CI. This is in contrast to our currentimplementation of CI where PRs are merged when they pass their own CI,but the code that was tested is not guaranteed to be the state of `main`when the PR is merged, meaning that we're at risk now of a failing`main` branch despite all merged PRs being green. While this hashappened with Wasmtime this is not a common occurrence, however.The main motivation, instead, to use GitHub's Merge Queue feature isthat it will enable Wasmtime to greatly reduce the amount of CI runningon PRs themselves. Currently the full test suite runs on every push toevery PR, meaning that our workers on GitHub Actions are frequentlyclogged throughout weekdays and PRs can take quite some time to comeback with a successful run. Through the use of a Merge Queue, however,we're able to configure only a small handful of checks to run on PRswhile deferring the main body of checks to happening on themerge-via-the-queue itself. This is hoped to free up capacity on CI andoverall improve CI times for Wasmtime and Cranelift developers.The implementation of all of this required quite a lot of plumbing andretooling of our CI. I've been testing this in an [externalrepository][testrepo] and I think everything is working now. A list ofchanges made in this PR are:* The `build.yml` workflow is merged back into the `main.yml` workflow as the original reason to split it out is not longer applicable (it'll run on all merges). This was also done to fit in the dependency graph of jobs of one workflow.* Publication of the `gh-pages` branch, the `dev` tag artifacts, and release artifacts have been moved to a separate `publish-artifacts.yml` workflow. This workflow runs on all pushes to `main` and all tags. This workflow no longer actually preforms any builds, however, and relies on a merge queue or similar being used for branches/tags where artifacts are downloaded from the workflow run to be uploaded. For pushes to `main` this works because a merge queue is run meaning that by the time the push happens all artifacts are ready. For release branches this is handled by..* The `push-tag.yml` workflow is subsumed by the `main.yml` workflow. CI for a tag being pushed will upload artifacts to a release in GitHub, meaning that all builds must finish first for the commit. The `main.yml` workflow at the end now scans commits for the preexisting magical marker and pushes a tag if necessary.* CI is currently a flat list of "run all these jobs" and this is now rearchitected to a "fan out" approach where some jobs run to determine the next jobs to run which then get "joined" into a finish step. The purpose for this is somewhat nuanced and this has implications for CI runtime as well. The Merge Queue feature requires branches to be protected with "these checks must pass" and then the same checks are gates both to enter the merge queue as well as pass the merge queue. The saving grace, however, is that a "skipped" check counts as passing, meaning checks can be skipped on PRs but run to completion on the merge queue. A problem with this though is the build matrix used for tests where PRs want to only run one element of the build matrix ideally but there's no means on GitHub Actions right now for the skipped entries to show up as skipped easily (or not that I know of). This means that the "join" step serves the purpose of being the single gate for both PR and merge queue CI and there's just more inputs to it for merge queue CI. The major consequence of this decision is that GitHub's actions scheduling doesn't work out well here. Jobs are scheduled in a FIFO order meaning that the job for "ok complete the CI run" is queued up after everything else has completed, possibly after lots of other CI requests in the middle for other PRs. The hope here is that by using a merge queue we can keep CI relatively under control and this won't affect merge times too much.* All jobs in the `main.yml` workflow will not automatically cancel the entire run if they fail. Previously this fail-fast behavior was only part of the matrix runs (and just for that matrix), but this is required to make the merge queue expedient. The gate of the merge queue is the final "join" step which is only executed once all dependencies have finished. This means, for example, that if rustfmt fails quickly then the tests which take longer might run for quite awhile before the join step reports failure, meaning that the PR sits in the queue for longer than needed being tested when we know it's already going to fail. By having all jobs cancel the run this means that failures immediately bail out and mark the whole job as cancelled.* A new "determine" CI job was added to determine what CI actually needs to run. This is a "choke point" which is scheduled at the start of CI that quickly figures out what else needs to be run. This notably indicates whether large swaths of ci (the `run-full` flag) like the build matrix are executed. Additionally this dynamically calculates a matrix of tests to run based on a new `./ci/build-test-matrix.js` script. Various inputs are considered for this such as: 1. All pushes, meaning merge queue branches or release-branch merges, will run full CI. 2. PRs to release branches will run full CI. 3. PRs to `main`, the most common, determine what to run based on what's modified and what's in the commit message. Some examples for (3) above are if modifications are made to `cranelift/codegen/src/isa/*` then that corresponding builder is executed on CI. If the `crates/c-api` directory is modified then the CMake-based tests are run on PRs but are otherwise skipped. Annotations in commit messages such as `prtest:*` can be used to explicitly request testing.Before this PR merges to `main` would perform two full runs of CI: oneon the PR itself and one on the merge to `main`. Note that the one as amerge to `main` was quite frequently cancelled due to a merge happeninglater. Additionally before this PR there was always the risk of a badmerge where what was merged ended up creating a `main` that failed CI toto a non-code-related merge conflict.After this PR merges to `main` will perform one full run of CI, the oneas part of the merge queue. PRs themselves will perform one test jobmost of the time otherwise. The `main` branch is additionally alwaysguaranteed to pass tests via the merge queue feature.For release branches, before this PR merges would perform two fullbuilds - one for the PR and one for the merge. A third build was thenrequired for the release tag itself. This is now cut down to two fullbuilds, one for the PR and one for the merge. The reason for this isthat the merge queue feature currently can't be used for ourwildcard-based `release-*` branch protections. It is now possible,however, to turn on required CI checks for the `release-*` branch PRs sowe can at least have a "hit the button and forget" strategy for mergingPRs now.Note that this change to CI is not without its risks. The Merge Queuefeature is still in beta and is quite new for GitHub. One bug thatTrevor and I uncovered is that if a PR is being tested in the mergequeue and a contributor pushes to their PR then the PR isn't removedfrom the merge queue but is instead merged when CI is successful, losingthe changes that the contributor pushed (what's merged is what wastested). We suspect that GitHub will fix this, however.Additionally though there's the risk that this may increase merge timefor PRs to Wasmtime in practice. The Merge Queue feature has the abilityto "batch" PRs together for a merge but this is only done if concurrentbuilds are allowed. This means that if 5 PRs are batched together then 5separate merges would be created for the stack of 5 PRs. If the CI forall 5 merged together passes then everything is merged, otherwise a PRis kicked out. We can't easily do this, however, since a major purposefor the merge queue for us would be to cut down on usage of CI buildersmeaning the max concurrency would be set to 1 meaning that only one PRat a time will be merged. This means PRs may sit in the queue for awhilesince previously many `main`-based builds are cancelled due tosubsequent merges of other PRs, but now they must all run to 100%completion.[testrepo]: https://github.com/bytecodealliance/wasmtime-merge-queue-testing List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

7669a961 - Reduce warnings on CI from GitHub Actions (#5083)

Fri, 21 Oct 2022 04:11:38 +0000

Reduce warnings on CI from GitHub Actions (#5083)* Upgrade our github actions to "node16" Each github actions run has a lot of warnings about using node12 so this upgrades our repository to using node16. I'm hoping no other changes are needed and I suspect other actions we're using are on node12 and will need further updates, but this should help pin down what's remaining. * Update `actions/checkout` workflow to `v3` * Update to `actions/cache@v3` * Update to `actions/upload-artifact@v3` * Drop usage of `actions-rs/toolchain` * Update to `actions/setup-python@v4` * Update mdbook version List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

63c9e5d4 - Allow empty commits for the release (#4927)

Tue, 20 Sep 2022 14:45:18 +0000

Allow empty commits for the release (#4927)The release process failed last night due to me filling out the dates in the release notes early (rather than leaving "Unreleased") which mean there were no changes for each commit. Switch to passing `--allow-empty` when making a commit to prevent this. List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

839c4cce - Remove the 'skip ci' annotation from the release process (#4476)

Wed, 20 Jul 2022 16:26:32 +0000

Remove the 'skip ci' annotation from the release process (#4476)With branch protections enabled that would otherwise mean that the PR cannot be landed since CI is now required to run. These date-update PRs typically come at odd off-hours for Wasmtime anyway so it should be fine to run CI. List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

99e9e139 - Update more workflows to only this repository (#4062)

Thu, 21 Apr 2022 16:45:48 +0000

Update more workflows to only this repository (#4062)* Update more workflows to only this repository This adds `if: github.repository == 'bytecodealliance/wasmtime'` to a few more workflows related to the release process which should only run in this repository and no other (e.g. forks). * Also only run verify-publish in the upstream repo No need for local deelopment to be burdened with ensuring everything is actually publish-able, that's just a concern for the main repository. * Gate workflows which need secrets on this repository List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

bea0433b - Fix the release process's latest step (#4055)

Wed, 20 Apr 2022 18:31:38 +0000

Fix the release process's latest step (#4055)* Fix the release process's latest step 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 * Replace sed with rust List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

76f7cde6 - Add m1 to build matrix and release (#3983)

Thu, 07 Apr 2022 00:40:04 +0000

Add m1 to build matrix and release (#3983)* Add m1 to release process This will create a pre-compiled binary for m1 macs and adds a link to review embark studios CI for verification. * remove test for macos arm Tests will not succeed for macos arm until GitHub provides a an m1 hosted runner. Co-authored-by: Bailey Hayes List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

35377bd3 - Fixup release documentation (#3988)

Tue, 05 Apr 2022 19:14:44 +0000

Fixup release documentation (#3988)* Fill out some missing comments on the workflow itself * Fix some formatting in the book to properly render sub-bullets List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml

c89dc551 - Add a two-week delay to Wasmtime's release process (#3955)

Fri, 01 Apr 2022 18:11:10 +0000

Add a two-week delay to Wasmtime's release process (#3955)* Bump to 0.36.0 * Add a two-week delay to Wasmtime's release process This commit is a proposal to update Wasmtime's release process with a two-week delay from branching a release until it's actually officially released. We've had two issues lately that came up which led to this proposal: * In #3915 it was realized that changes just before the 0.35.0 release weren't enough for an embedding use case, but the PR didn't meet the expectations for a full patch release. * At Fastly we were about to start rolling out a new version of Wasmtime when over the weekend the fuzz bug #3951 was found. This led to the desire internally to have a "must have been fuzzed for this long" period of time for Wasmtime changes which we felt were better reflected in the release process itself rather than something about Fastly's own integration with Wasmtime. This commit updates the automation for releases to unconditionally create a `release-X.Y.Z` branch on the 5th of every month. The actual release from this branch is then performed on the 20th of every month, roughly two weeks later. This should provide a period of time to ensure that all changes in a release are fuzzed for at least two weeks and avoid any further surprises. This should also help with any last-minute changes made just before a release if they need tweaking since backporting to a not-yet-released branch is much easier. Overall there are some new properties about Wasmtime with this proposal as well: * The `main` branch will always have a section in `RELEASES.md` which is listed as "Unreleased" for us to fill out. * The `main` branch will always be a version ahead of the latest release. For example it will be bump pre-emptively as part of the release process on the 5th where if `release-2.0.0` was created then the `main` branch will have 3.0.0 Wasmtime. * Dates for major versions are automatically updated in the `RELEASES.md` notes. The associated documentation for our release process is updated and the various scripts should all be updated now as well with this commit. * Add notes on a security patch * Clarify security fixes shouldn't be previewed early on CI List of files: /wasmtime-44.0.1/.github/workflows/release-process.yml