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

This reverts commit b4bd5a5.

.github/workflows/ci.yaml

@@ -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"

.github/workflows/release.yaml

@@ -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 }}
@@ -403,8 +394,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 +403,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 +417,10 @@ jobs:
         with:
           name: binaries
           path: binaries
-      - name: git tag
-        run: |
-          git config user.email "[email protected]"
-          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

CONTRIBUTING.md

@@ -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 haven’t 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