From 00feefe9a7cf10625bf97257ea7ba170787bec1d Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Mon, 8 Nov 2021 10:37:53 -0600 Subject: [PATCH] Change the bump-version workflow's schedule (#3512) * Change the bump-version workflow's schedule Either I don't understand cron or GitHub doesn't understand cron. It's not clear which. I think that https://github.com/bytecodealliance/wasmtime/pull/3511 may have fallen within our schedule but it was supposed to be on a weekday. Otherwise https://github.com/bytecodealliance/wasmtime/pull/3499 was certainly spurious. This commit moves to a simpler "just do it on the same day each month" and we can manually figure out weekdays and such. Hopefully this should reduce the number of spurious PRs we're getting to bump versions. This also removes the script to force a version bump since I found a button on the GitHub UI to do the same thing. Additionally I've updated the patch-release documentation to use this button. Note that this button takes inputs as well which means we can further automate patch releases to look even more like normal release process, differing only in one part of the argument used to trigger the workflow. * Fix a typo --- .github/workflows/bump-version.yml | 27 +++++++++++++++++---------- ci/force-ci-bump-version.sh | 16 ---------------- docs/contributing-release-process.md | 21 ++++++++++----------- 3 files changed, 27 insertions(+), 37 deletions(-) delete mode 100644 ci/force-ci-bump-version.sh diff --git a/.github/workflows/bump-version.yml b/.github/workflows/bump-version.yml index 5e1de9bf5f..873928191b 100644 --- a/.github/workflows/bump-version.yml +++ b/.github/workflows/bump-version.yml @@ -11,18 +11,19 @@ name: "Bump version number" on: schedule: - # “At 00:00 on every day-of-month from 8 through 14 and on Monday.” + # “At 00:00 on day-of-month 5.” # - # https://crontab.guru/#0_0_8-14_*_1 - - cron: '0 0 8-14 * 1' + # https://crontab.guru/#0_0_5_*_* + - cron: '0 0 5 * *' - # Allow manually triggering this workflow remotely via a curl request, - # described at - # https://docs.github.com/en/rest/reference/actions#create-a-workflow-dispatch-event - # - # Note that this can be also triggered by running the script in - # `ci/force-ci-bump-version.sh` + # Allow manually triggering this request via the button at + # https://github.com/bytecodealliance/wasmtime/actions/workflows/bump-version.yml workflow_dispatch: + inputs: + publish_cmd: + description: 'Publish script argument: "bump" or "bump-patch"' + required: false + default: 'bump' jobs: bump_version: @@ -36,7 +37,13 @@ jobs: id: bump run: | rustc scripts/publish.rs - ./publish bump + if [ "${{ github.event.inputs.publish_cmd }}" != "" ]; then + # this was manually triggered + ./publish ${{ github.event.inputs.publish_cmd }} + else + # this was cron-triggered. + ./publish bump + fi version=$(grep '^version =' Cargo.toml | head -n 1 | sed 's/.*"\(.*\)"/\1/') echo "::set-output name=version::$version" diff --git a/ci/force-ci-bump-version.sh b/ci/force-ci-bump-version.sh deleted file mode 100644 index 72aa665ff9..0000000000 --- a/ci/force-ci-bump-version.sh +++ /dev/null @@ -1,16 +0,0 @@ -#!/bin/bash - -if [ -z "$PERSONAL_ACCESS_TOKEN" ]; then - echo "need to set \$PERSONAL_ACCESS_TOKEN to a github token" - exit 1 -fi - -exec curl --include --request POST \ - https://api.github.com/repos/bytecodealliance/wasmtime/actions/workflows/bump-version.yml/dispatches \ - --header "Authorization: token $PERSONAL_ACCESS_TOKEN" \ - --data @- << EOF -{ - "ref": "main" -} -EOF - diff --git a/docs/contributing-release-process.md b/docs/contributing-release-process.md index 5c972e4718..7f3cbed6a9 100644 --- a/docs/contributing-release-process.md +++ b/docs/contributing-release-process.md @@ -19,16 +19,16 @@ Specifically what happens for a major version release is: * Commit the changes with a special marker in the commit message * Push these changes to a branch * Open a PR with this branch against `main` -1. A maintainer of Wasmtime signs off on the PR and merges it. +2. A maintainer of Wasmtime signs off on the PR and merges it. * Most likely someone will need to push updates to `RELEASES.md` beforehand. * A maintainer should double-check there are [no open security issues][rustsec-issues]. -1. The `.github/workflow/push-tag.yml` workflow is triggered on all commits to +3. The `.github/workflow/push-tag.yml` workflow is triggered on all commits to `main`, including the one just created with a PR merge. This workflow will: * Scan the git logs of pushed changes for the special marker added by `bump-version.yml`. * If found, tags the current `main` commit and pushes that to the main repository. -1. Once a tag is created CI runs in full on the tag itself. CI for tags will +4. Once a tag is created CI runs in full on the tag itself. CI for tags will create a GitHub release with release artifacts and it will also publish crates to crates.io. This is orchestrated by `.github/workflows/main.yml`. @@ -49,20 +49,19 @@ time the process for making a patch release of `2.0.1` the process is: `scripts/publish.rs` do not have semver-API-breaking changes (in the strictest sense). All security fixes must be done in such a way that the API doesn't break between the patch version and the original version. -1. Locally check out `release-2.0.1` and make sure you're up-to-date. -1. Run `rustc scripts/publish.rs` -1. Run `./publish bump-patch` -1. Update `RELEASES.md` -1. Commit the changes. Include the marker - `[automatically-tag-and-release-this-commit]` in your commit message. -1. Make a PR against the `release-2.0.1` branch. -1. Merge the PR when CI is green +2. Visit [this patch][bump-version] and manually trigger the `bump-version.yml` + workflow for the `release-2.0.1` branch with the `bump-patch` argument. This + will simulate step (1) of the above release process. +3. Review the generated PR, probably updating `RLEASES.md` as well. * Note that if historical branches may need updates to source code or CI to pass itself since the CI likely hasn't been run in a month or so. When in doubt don't be afraid to pin the Rust version in use to the rustc version that was stable at the time of the branch's release. +4. Merge the generated PR, and that's the whole patch release. From this point automated processes should take care of the rest of the steps, basically resuming from step 3 above for major releases where `push-tag.yml` will recognize the commit message and push an appropriate tag. This new tag will then trigger full CI and building of release artifacts. + +[bump-version]: https://github.com/bytecodealliance/wasmtime/actions/workflows/bump-version.yml