Refactor GitHub workflows

[AkshatRai07]

Fixes #560.
In this PR we:

• Adopted a consistent <category>-<target>.yml convention (unittests-*, release-*, bench-*):
  • unittests.yml $\rightarrow$ unittests-python.yml
  • pypi.yml $\rightarrow$ release-python.yml
  • crates.yml $\rightarrow$ release-crates.yml
  • maturin.yml $\rightarrow$ release-ekors.yml
  • isobench.yml $\rightarrow$ bench-iso.yml
  • lha_bot.yml $\rightarrow$ bench-lha.yml
  • lha_bot_rust.yml $\rightarrow$ bench-lha-rust.yml
• Enhanced release & manual publishing:
  • Restricted release tag triggers to semantic version tags ('v[0-9]+*').
  • Added workflow_dispatch with a tag input across all release workflows to allow completing or retrying partially failed releases.
  • Implemented tag fallback logic (TAG: ${{ github.event.inputs.tag || github.ref_name }}) for version bumping and artifact packaging.
  • Updated job conditionals (if: startsWith(github.ref, 'refs/tags/') || github.event.inputs.tag != '') so manual runs with a tag can publish, while tagless runs perform dry builds.
• Standardized Python environment setup with actions/setup-python@v5 across release version-bumping steps.
• Updated @v2 actions to @v4 (actions/checkout@v4 and codecov/codecov-action@v4) in benchmark workflows.
• Pointed the CI test badge in README.md to unittests-python.yml.

[Copilot]

Pull request overview

Refactors GitHub Actions workflows to standardize naming, tighten release triggers, and add manual release re-run support via workflow_dispatch inputs.

Changes:

• Renames/introduces workflows to follow a consistent <category>-<target>.yml convention and updates the README test badge accordingly.
• Updates release workflows to support workflow_dispatch with a tag input and adds tag-fallback logic for version bumping/packaging.
• Modernizes benchmark workflows by bumping actions/checkout to @v4 and codecov/codecov-action to @v4.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
README.md	Updates the CI badge to point at the renamed Python unit test workflow.
.github/workflows/unittests-python.yml	Adds a dedicated Python unit test workflow that reuses the shared poetry test workflow.
.github/workflows/release-python.yml	Replaces the old PyPI workflow with a renamed release workflow and adds manual dispatch support.
.github/workflows/release-pyapi.yml	Adds semver-ish tag filtering plus manual dispatch/tag fallback for maturin wheel publishing.
.github/workflows/release-ekors.yml	Adds semver-ish tag filtering plus manual dispatch/tag fallback for maturin wheel publishing.
.github/workflows/release-crates.yml	Adds semver-ish tag filtering plus manual dispatch/tag fallback for crates publishing.
.github/workflows/release-capi.yml	Adds semver-ish tag filtering plus manual dispatch/tag fallback and updates macOS runner selection.
.github/workflows/pypi.yml	Removes the old PyPI release workflow (superseded by release-python.yml).
.github/workflows/bench-lha.yml	Updates checkout action version.
.github/workflows/bench-lha-rust.yml	Updates checkout action version.
.github/workflows/bench-iso.yml	Updates checkout and codecov action versions.

Suppressed comments (7)

.github/workflows/release-capi.yml:22

• On workflow_dispatch runs with a tag input, actions/checkout will still check out the branch selected in the UI (not the tag being republished). That can build/upload artifacts from the wrong commit into the existing release tag. Consider checking out the provided tag ref (and fetching tags) in this and the other checkout steps in this workflow (e.g. build job at line 59).

      - uses: actions/checkout@v4

.github/workflows/release-crates.yml:6

• GitHub Actions tag filters use glob patterns (not regex). The current pattern v[0-9]+* requires a literal +, so typical semver tags like v1.2.3 will not trigger this workflow.

This issue also appears on line 21 of the same file.
.github/workflows/release-crates.yml:23

• For manual re-publish runs (workflow_dispatch + tag), this workflow currently checks out the UI-selected branch instead of the tag commit being republished, which can publish crates from the wrong source. Also, actions/setup-python is used without pinning a version, which makes releases less reproducible.
  .github/workflows/release-ekors.yml:6
• GitHub Actions tag filters use glob patterns (not regex). The current pattern v[0-9]+* requires a literal +, so typical semver tags like v1.2.3 will not trigger this workflow.

This issue also appears on line 22 of the same file.
.github/workflows/release-ekors.yml:22

• On workflow_dispatch runs with a tag input, actions/checkout will check out the branch selected in the UI rather than the tag commit. That can produce/publish artifacts from the wrong revision. Consider checking out the provided tag ref in this job and in the other checkout steps later in this file (e.g. lines 55, 95, ...).
  .github/workflows/release-python.yml:24
• workflow_dispatch re-publish runs with a tag will call the reusable python-poetry-pypi-with-data.yml, but that reusable workflow always checks out the UI-selected ref (not the tag commit) and always publishes to PyPI. That means a manual re-publish can publish from the wrong revision, and there is currently no way to do a tagless "dry build" despite the PR description.

  publish:
    if: startsWith(github.ref, 'refs/tags/') || github.event.inputs.tag != ''
    uses: ./.github/workflows/python-poetry-pypi-with-data.yml
    secrets:
      PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }}
    with:
      poetry-extras: "-E mark -E box"
      data-version: "v2"
      data-download: "./tests/data/assets.sh"

.github/workflows/release-pyapi.yml:27

• With the new workflow_dispatch + tag support, this workflow can be run from a branch while trying to (re)publish an existing tag. However actions/checkout@v4 (line 22) will still check out the UI-selected ref, so the bump/build steps can run against the wrong commit for the requested tag. Consider checking out the provided tag ref (and doing the same for the other checkout steps later in this file).

        if: startsWith(github.ref, 'refs/tags/') || github.event.inputs.tag != ''

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[scarlehoff]

Perhaps this is a good time to change to trusted publishing for eko (instead of creating a new token for the new package).

For now I added the trusted publisher pointing to release-python.yml to the eko package https://docs.pypi.org/trusted-publishers/using-a-publisher/

I've also pre-created the ekore-rs package pointing instead to release-ekors.yml so the package should be created automagically when you try to deploy it.

[felixhekhorn]

thanks for doing a more extensive review of the workflow files

[felixhekhorn]

Also, remember to update

eko/extras/architecture.md

Line 370 in f131c1b

- **`crates.yml`**: Runs `poe bump-version` and publishes using `cargo publish --allow-dirty`.

[AkshatRai07]

I've also pre-created the ekore-rs package pointing instead to release-ekors.yml

There's an issue in this.

• release-ekors.yml builds crates/eko/Cargo.toml, which publishes eko-rs.
• release-pyapi.yml builds crates/ekore_py/Cargo.toml, which publishes ekore-rs.

Please update the permissions respectively.

[scarlehoff]

Ah, my bad,

release-pyapi.yml builds crates/ekore_py/Cargo.toml, which publishes ekore-rs.

Now ekore-rs points to release-pyapi.yml