Feature/#53 trusted publishing

[spoltier]

will close #53
includes a test workflow to be triggered manually for testing changes to publication logic. It seems safer and more flexible to use a different workflow entirely, avoiding publishing to the wrong pypi instance.

[Copilot]

Pull Request Overview

This PR adds a manual TestPyPI publishing workflow, updates the existing publish workflow to split build and publish steps, and bumps the project version.

• Bump version from 0.1.dev1 to 0.1.dev2
• Add test-publish.yml for manual TestPyPI uploads
• Refactor publish.yml into separate build and publish jobs

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
pyproject.toml	Bumped version to 0.1.dev2
.github/workflows/test-publish.yml	New workflow for manual TestPyPI package uploads
.github/workflows/publish.yml	Split build/publish into two jobs and upload artifacts

Comments suppressed due to low confidence (2)

.github/workflows/publish.yml:40

• [nitpick] This comment about TestPyPI publish appears outdated in the main publish workflow. It might be confusing; consider removing or updating it to reflect the new dedicated test-publish workflow.

# for testing publication: use `uv publish --publish-url https://test.pypi.org/legacy`. Ask for the test token. (user mirai-solutions-gmbh on test.pypi.org)

.github/workflows/test-publish.yml:1

• [nitpick] There is duplicated build and publish logic between this test workflow and the main publish workflow. You could extract common steps into a reusable workflow or composite action to reduce duplication.

name: TEST Upload Python Package to PyPI

[spoltier]

Note that the codecov project check is comparing with an old result which wasn't updated as the codecov check didn't work for subsequent changes.

[RolandASc]

Note that the codecov project check is comparing with an old result which wasn't updated as the codecov check didn't work for subsequent changes.

the basis against which it is comparing is actually fine and not that old, i.e. it is the last commit with relevant changes I believe

looking into the results I noticed however that previously some adjacent empty lines and comments had been counted and factored into the statistics as well, which is why we are losing several percentages now as we have fewer total lines in scope whereas the uncovered ones remain almost identical (one empty line there as well)

[RolandASc]

thanks Simon, looks good, the coverage is fine to me (though we could discuss excluding cli from the report or writing some test(s) for it)

one thing you could still do here is to systematically fix the missing permissions on those jobs / workflows where we don't have them set explicitly yet - I think it didn't flag the old existing issues of this sort in this PR, but you're anyways modifying those files