Revert "Make the release workflow more resilient (#4728)"

This reverts commit b4bd5a5acb.
This commit is contained in:
Charlie Marsh 2023-06-20 15:29:22 -04:00
parent fde5dbc9aa
commit 1fa0a6f31a
3 changed files with 26 additions and 74 deletions

View File

@ -220,10 +220,11 @@ jobs:
- name: "Build wheels"
uses: PyO3/maturin-action@v1
with:
manylinux: auto
args: --out dist
- name: "Test wheel"
run: |
pip install --force-reinstall --find-links dist ${{ env.PACKAGE_NAME }}
pip install dist/${{ env.PACKAGE_NAME }}-*.whl --force-reinstall
ruff --help
python -m ruff --help
- name: "Remove wheels from cache"

View File

@ -2,17 +2,8 @@ name: "[ruff] Release"
on:
workflow_dispatch:
inputs:
tag:
description: "The version to tag, without the leading 'v'. If omitted, will initiate a dry run skipping uploading artifact."
type: string
sha:
description: "Optionally, the full sha of the commit to be released"
type: string
push:
paths:
# When we change pyproject.toml, we want to ensure that the maturin builds still work
- pyproject.toml
release:
types: [ published ]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
@ -31,6 +22,8 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -57,6 +50,8 @@ jobs:
runs-on: macos-latest
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -95,6 +90,8 @@ jobs:
runs-on: macos-latest
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -141,6 +138,8 @@ jobs:
arch: x64
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -187,6 +186,8 @@ jobs:
- i686-unknown-linux-gnu
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -244,6 +245,8 @@ jobs:
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -297,6 +300,8 @@ jobs:
- i686-unknown-linux-musl
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -351,6 +356,8 @@ jobs:
steps:
- uses: actions/checkout@v3
with:
ref: "v0.0.273"
- uses: actions/setup-python@v4
with:
python-version: ${{ env.PYTHON_VERSION }}
@ -403,8 +410,7 @@ jobs:
- linux-cross
- musllinux
- musllinux-cross
# If you don't set an input it's a dry run skipping uploading artifact
if: ${{ inputs.tag }}
# if: "startsWith(github.ref, 'refs/tags/')"
environment:
name: release
permissions:
@ -413,34 +419,11 @@ jobs:
# For GitHub release publishing
contents: write
steps:
- name: Consistency check tag
run: |
version=$(grep "version = " pyproject.toml | sed -e 's/version = "\(.*\)"/\1/g')
if [ "${{ inputs.tag }}" != "${version}" ]; then
echo "The input tag does not match the version from pyproject.toml:" >&2
echo "${{ inputs.tag }}" >&2
echo "${version}" >&2
exit 1
else
echo "Releasing ${version}"
fi
- name: Consistency check sha
if: ${{ inputs.sha }}
run: |
git_sha=$(git rev-parse HEAD)
if [ "${{ inputs.sha }}" != "${git_sha}" ]; then
echo "The specified sha does not match the git checkout" >&2
echo "${{ inputs.sha }}" >&2
echo "${git_sha}" >&2
exit 1
else
echo "Releasing ${git_sha}"
fi
- uses: actions/download-artifact@v3
with:
name: wheels
path: wheels
- name: Publish to PyPi
- name: "Publish to PyPi"
uses: pypa/gh-action-pypi-publish@release/v1
with:
skip-existing: true
@ -450,20 +433,10 @@ jobs:
with:
name: binaries
path: binaries
- name: git tag
run: |
git config user.email "hey@astral.sh"
git config user.name "Ruff Release CI"
git tag -m "v${{ inputs.tag }}" "v${{ inputs.tag }}"
# If there is duplicate tag, this will fail. The publish to pypi action will have been a noop (due to skip
# existing), so we make a non-destructive exit here
git push --tags
- name: "Publish to GitHub"
uses: softprops/action-gh-release@v1
with:
draft: true
files: binaries/*
tag_name: v${{ inputs.tag }}
# - name: "Publish to GitHub"
# uses: softprops/action-gh-release@v1
# with:
# files: binaries/*
# After the release has been published, we update downstream repositories
# This is separate because if this fails the release is still fine, we just need to do some manual workflow triggers

View File

@ -271,28 +271,6 @@ them to [PyPI](https://pypi.org/project/ruff/).
Ruff follows the [semver](https://semver.org/) versioning standard. However, as pre-1.0 software,
even patch releases may contain [non-backwards-compatible changes](https://semver.org/#spec-item-4).
### Creating a new release
1. Update the version with `rg 0.0.269 --files-with-matches | xargs sed -i 's/0.0.269/0.0.270/g'`
1. Update `BREAKING_CHANGES.md`
1. Create a PR with the version and `BREAKING_CHANGES.md` updated
1. Merge the PR
1. Run the release workflow with the version number (without starting `v`) as input. Make sure
main has your merged PR as last commit
1. The release workflow will do the following:
1. Build all the assets. If this fails (even though we tested in step 4), we havent tagged or
uploaded anything, you can restart after pushing a fix
1. Upload to pypi
1. Create and push the git tag (from pyproject.toml). We create the git tag only here
because we can't change it ([#4468](https://github.com/charliermarsh/ruff/issues/4468)), so
we want to make sure everything up to and including publishing to pypi worked.
1. Attach artifacts to draft GitHub release
1. Trigger downstream repositories. This can fail without causing fallout, it is possible (if
inconvenient) to trigger the downstream jobs manually
1. Create release notes in GitHub UI and promote from draft to proper release(<https://github.com/charliermarsh/ruff/releases/new>)
1. If needed, [update the schemastore](https://github.com/charliermarsh/ruff/blob/main/scripts/update_schemastore.py)
1. If needed, update ruff-lsp and ruff-vscode
## Ecosystem CI
GitHub Actions will run your changes against a number of real-world projects from GitHub and