Fail on mismatched version

[travis-cook-sfdc]

Poetry will publish to pypi using the version present in pyproject.toml.

If someone creates a github action using the following syntax:

on:
  release:
    types: [published]

Then it's possible that they'll create a github release that doesn't match the version present in pyproject.toml.

Github Actions support if conditions prior to running this github action, however if is tricky because poetry_version isn't in scope. Because poetry is installed in a Docker container, the github runner won't have access to run a command like poetry version -s to access the version.

I'd like to propose the addition of the VERIFY_GITHUB_TAG_VERSION bool argument to short-circuit if the github tag and the poetry version don't match.

[JRubics]

I am not sure if you are talking about poetry version or version of the package that will be published?

If talking about package version, I think this is out of scope of the action since it is not handling publishing to poetry directly but checking a version to be published in a file. Instead, I would recommend doing something like this:

    - name: Change version in pyproject.toml
      run: |
        REF=$(echo ${{ github.ref }} | sed "s#\(refs/tags/\)\?v\?##")
        sed -i "s/^version = \".\+\"/version = \"$REF\"/" pyproject.toml
    - name: Build and publish to pypi
      uses: JRubics/poetry-publish@v1.15
      with:
        pypi_token: ${{ secrets.PYPI_TOKEN }}

so you can always be sure you have the latest version in pyproject.toml. :slightly_smiling_face:

[travis-cook-sfdc]

Sorry I wasn't clear. I was talking about the package version.

I think this is out of scope of the action since it is not handling publishing to poetry directly

I'm not sure I would agree with this. This action does directly handle publishing to pypi / private repository.

However, the action doesn't expose setting the version. Instead, it pulls it directly from the pyproject.toml file. Because poetry publish ... does directly leverage the pyproject.toml file, that necessarily means there are two steps:

1. Update pyproject.toml's version
2. Create a release in github

However, if those two steps aren't done with the same release number, things start to break down.

Typing this all out begs the question for me: Is the preferred use of this action to use with:

on:
  push:
    branches:
      - main

And letting publish fail when the version hasn't changed?

EDIT: Adding some additional thoughts.

I see in the README, it lists the following example:

on:
  push:
    tags:
      - "v*.*.*"

In this example, doesn't this require that a developer releasing a new version remembering to tag a commit with the same version in pyproject.toml? If this action exposed a "package_version" arg, you wouldn't have to remember, you could just pass the tag in directly.

[JRubics]

I think this is out of scope of the action since it is not handling publishing to poetry directly

When I said this I meant your idea about adding version handling to the action, sorry if it was not clear. :slightly_smiling_face:

Yes, it requires from the developer to think about the versioning, but I have a few reasons why I think this action should not handle it:

• if you pass package_version to the action, it will need to update pyproject.toml and push to your repo this change. It means your tagged version on github has the old version of pyproject.toml, but poetry released version have a new one. There is also an option not to push new changes at all, like in the example I gave you, but I would like to leave that decision to the users of the action.
• this process can bi automated with 2-3 line script action and gives much more variety to the users. Also, maybe there is already an action handling it
• this action should only publish to poetry, and not bother with release preparation. I think this is the main concept about actions, to be small and granular and do just one thing it is supposed to do.
• also, this would be a breaking change to this project, which can affect other users, what I want to avoid

What I would recommend you to do if you don't like the approach about creating another action to handle the version update, is to create a release script locally, and make it update the pyproject.toml, tag with the same version and push :slightly_smiling_face:

I hope you understand the reasons why I don't want to include this in the action, but still if you need it, feel free to fork this project and use your updated version :slightly_smiling_face:

[tschm]

I think the trick is to keep the version in pyproject.toml always at 0.0.0

In Gitlab I would use something like

.publish package:
    stage: deploy
    services: []
    needs: ["build", "tests"]
    script:
      - echo $CI_COMMIT_TAG
      - poetry version $CI_COMMIT_TAG
      - poetry build
      - poetry config repositories.qromatiq-registry https://qromatiq.codes/api/v4/projects/12/packages/pypi
      - poetry publish --repository qromatiq-registry --username ... --password ...
    rules:
      - if: $CI_COMMIT_TAG

So the pyproject.toml showing up in my registry will indeed have the correct version (given by the COMMIT_TAG). I am too new to Github actions but keen to learn more...

[JRubics]

Great idea @tschm, Thank you for sharing it :raised_hands: