ci: simplify uv-based CI and release workflows

[jakob1379]

just a cleanup and tightening of the CI.

Things done:

• Use setup-uv + uv sync/build/publish
• tighten release flow around tag-based trusted publishing,
• pin workflow actions to latest major versions

[Maxteabag]

Thanks for the cleanup! The YAML anchors, action version bumps, and permissions tightening all look great.

The checksum computation in the release workflow switched from checksumming the local build artifact to downloading from PyPI first via curl. We previously had it that way and moved away from it because it made releases slow (waiting for PyPI to be ready). The current approach of checksumming the local dist/ artifact is instant and equivalent since PyPI serves exactly what we upload.

Was there any particular reason you changed it to downloading via curl?

[jakob1379]

Mainly to ensure it exists on pypi as I have often found myself ending up making releases on GH successfully, but then some failing CI did not push to PyPi, so I have preferred the other way around. So either a release exists everywhere or nowhere.

I'll gladly accommodate changes if you prefer something else.

If you have setup this repo as trusted on pypi this can further be slimmed down 😁

[jakob1379]

would still consider merging this? @Maxteabag

[Maxteabag]

Yes, I've delayed it because I saw some things that concerned me. But I am going to have to have a closer look.

[jakob1379]

Yes, I've delayed it because I saw some things that concerned me. But I am going to have to have a closer look.

Feel free to throw any concerns or questions at me :)

[jakob1379]

      contents: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ env.RELEASE_TAG }}

      - name: Extract version from tag
        id: version
        run: |
          echo "TAG=${RELEASE_TAG}" >> $GITHUB_OUTPUT
          echo "VERSION=${RELEASE_TAG#v}" >> $GITHUB_OUTPUT

      - name: Create GitHub Release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: ${{ steps.version.outputs.TAG }}
          name: ${{ steps.version.outputs.TAG }}
          generate_release_notes: true
          draft: false
          prerelease: false

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ env.RELEASE_TAG }}

would it not be better if we used the pyproject.toml as the source of truth for the version number instead of the tag number?

uv is pretty great for managing this too

❯ uv version --help
Read or update the project's version

Usage: uv version [OPTIONS] [VALUE]

Arguments:
  [VALUE]  Set the project version to this value

Options:
      --bump <BUMP[=VALUE]>            Update the project version using the given semantics [possible values: major, minor, patch, stable, alpha, beta, rc, post, dev]
      --dry-run                        Don't write a new version to the `pyproject.toml`
      --short                          Only show the version
      --output-format <OUTPUT_FORMAT>  The format of the output [default: text] [possible values: text, json]
      --no-sync                        Avoid syncing the virtual environment after re-locking the project [env: UV_NO_SYNC=]
      --active                         Prefer the active virtual environment over the project's virtual environment
      --locked                         Assert that the `uv.lock` will remain unchanged [env: UV_LOCKED=]
      --frozen                         Update the version without re-locking the project [env: UV_FROZEN=]
      --package <PACKAGE>              Update the version of a specific package in the workspace

[jakob1379]

@Maxteabag is this still relevant, should I rebase or close?

[Maxteabag]

Sorry for the slow response, I took a closer look. The CI cleanup is still useful, so I’d prefer a rebase rather than closing this, but I don’t think the current version is safe to merge as-is.

I fetched the PR head and traced the release jobs and their outputs, then checked the external URLs/action refs directly. A few concrete problems came up:

• The AUR job reads the version from steps.version, but the step in that job is called info. It also reads the checksum from steps.info, although the checksum is produced by the pypi step. That leaves both values empty.
• A manual workflow_dispatch skips the tag-only publish job, but the AUR job still runs and tries to download the artifact that the skipped job would have created.
• I tested the constructed PyPI source URL against the existing 1.6.0 release and got a 404. Since the later curl does not use --fail, it could hash an error response and use that as the AUR checksum.
• KSXGitHub/github-actions-deploy-aur@v4 is not an available tag. Fully versioned tags such as v4.2.0 do exist.

[Maxteabag]

Thanks again for putting this together. After looking at how much the release workflow and main have changed since this was opened, I think the best option is to close this rather than ask you to spend time rebasing the whole thing.

There are several separate ideas bundled together here: CI deduplication, action upgrades, permissions changes, publishing changes, and AUR handling. I’d prefer that we take those on as smaller, focused changes one at a time. That will make each change easier to verify and reduce the risk around the release process.

I appreciate the work and the ideas behind the cleanup!

[jakob1379]

i'll gladly rebase/remake, not really an issue :) I might have a look at how everything looks now and reconsider :)