search

quantorconsulting / mkdocs_build_plantuml

MkDocs plugin to help generate your plantuml images locally or remotely as files (NOT inline)
MIT License
57 stars 15 forks source link

Automate git tagging with GitHub Action #33

Closed aarons20 closed 7 months ago

aarons20 commented 7 months ago

Might have to add tagging in git as well, as it does now not reflect the same state in repo and PyPi

_Originally posted by @christo-ph in https://github.com/quantorconsulting/mkdocs_build_plantuml/issues/32#issuecomment-1806320107_

aarons20 commented 7 months ago

Considerations about versioning and GitHub action

The current GitHub action triggers on each push to the master/main branch. However, a challenge arises as not every commit equals a new release version for the PlantUML plugin. If the version number remains unchanged, the GitHub action fails since PyPi does not allow packages with identical versions. Commits, such as pipeline improvements or typo fixes, do not result in a new version number.

I propose three potential solutions:

  1. Develop Branch Approach:

    • Create a "develop" branch for general updates.
    • Increase the version number when a new release is necessary.
    • Merge to master/main to trigger the action.

  2. Ignore GitHub Action Failure:

    • Allow the GitHub action to fail with same version number als currently released package.
    • This won't impact the system negatively, as the package won't be re-released to PyPi with an existing version. However, checking the error message becomes crucial to check if the pipeline error is really because of the version number.

  3. Dynamic Version Checking:

    • Find a way to check the current version number against the version on PyPi at the pipeline's start.
    • Determine whether the pipeline should proceed based on version changes.
    • Challenge: One has to remember that a release is only triggered when the version is changed correctly.

I believe any of these approaches could be a valid solution. However, having a dedicated "develop" branch for general development seems like the cleanest solution. A failed pipeline would accurately indicate that the version number wasn't increased when merging from develop to master/main. The PR process would involve merging or committing to develop, consider whether a release is needed and if it is merge with a new version number to master/main.

Feel free to give feedback on these solutions or any alternative suggestions.

aarons20 commented 7 months ago

I have the change ready to open a PR. Depends on you whether the target will be a "develop" branch or master :)

christo-ph commented 7 months ago

I suppose git tagging is not that crucial to introduce some gitflow and a develop branch. So it would be fine for me to go with version 2.

aarons20 commented 7 months ago

That't true. I will open the PR. I've tested it on my fork. Since I do not increase the version number in the PR the action should fail with a version number related PyPi error.