Request: add semantic versioning tags and releases to project

[arrrgi]

Hi @stefangweichinger

Just an idea that will probably help folks using your great role. I think it would be useful learning experience to setup semantic versioning and releases with tags and a Github action for your repo.

@geerlingguy (who I note uses your role too) has an existing config you might consider re-using to do the same.

This helps us folks who import and lock specific versions of roles that are known to work in our own projects from Galaxy, ie.

# requirements.yml
# Install dependency roles from Galaxy
- src: geerlingguy.docker
  version: 6.0.4
- src: geerlingguy.pip
  version: 2.2.0
- src: stefangweichinger.ansible_rclone
#  version: x.x.x

[stefangweichinger]

@arrrgi Thanks for the suggestion. Could you link to the mentioned config? I will look into it and see what I can do.
And thanks for calling this small project a "great role"; I appreciate it.

[arrrgi]

This CI action for release updates to Galaxy is the one I see Jeff is using across quite a few of his repos:

https://github.com/geerlingguy/ansible-role-rabbitmq/blob/master/.github/workflows/release.yml

I use commitizen and pre-commit as part of my local dev toolchain to keep me honest as it's not quite a muscle memory yet for me to format my commit messages. I think both tools are well worth checking out if you think they'd be valuable to help you stick to using semantic versioning.

[arrrgi]

And thanks for calling this small project a "great role"; I appreciate it.

I love a bit of well thought out code that uses the tool the way the developers intended. Great job!

[stefangweichinger]

@arrrgi as far as I understand you suggest using commitizen in a github action to bump the version of the release each time something relevant gets committed to the main branch, correct?

The release-part (after having created a new release with a tag) could still be done with robertdebock/galaxy-action, maybe ... I don't know yet.

[arrrgi]

In my workflow, I'm bumping versions whenever I think is most appropriate rather than having that automated in an action.

Eg. I might start work on a new feature branch, committing and pushing regularly, I will do a few tests and might need to add a few fix commits as I'm debugging, and when I'm happy with the feature or my changes, I'll run cz bump on the feature branch and merge those down into main. I can then kill that feature branch if I wish, or keep iterating on the feature and repeat those steps again later.

Your own git workflow will be what you are most comfortable with and the velocity you work at.

[stefangweichinger]

Started playing with cz and found some interesting ways of releasing etc ... maybe I come up with a more refined workflow soon. Currently trying to decide on how to handle various details.

[stefangweichinger]

@arrrgi Do you have an example of using commitizen with an ansible role? What do you use for "version_files:" for example? The examples show more python-related files like pyproject.toml, that doesn't look right for an ansible project.

I still am researching and learning, didn't yet find much time do come up with something useful.

The project is rather static ... not many devs, not many changes and PRs, so I wonder how much complexity to add and if it's worth the effort. Sure, it makes sense to standardize things etc. But I admit that I still don't fully understand if it helps to use pre-commit.ci in this context.

I consider adding a CHANGELOG.md, and to somehow tag a first release like "0.1.0". That might happen manually for a start. Still looking up examples how tags and releases are handled best along a well written ansible role.

Thanks for the suggestions anyway: this is also kind of a learning project.

[stefangweichinger]

@arrrgi have a look at this branch: it uses an action in .github/workflows/commitizen.yml to bump the version and commit back to the originating branch.

It created a tag and an entry in CHANGELOG.md ... I assume if I put this into the main branch, it should release it to galaxy and there a version should be created based on the tag.

Looks promising to me. Suggestions welcome.

[arrrgi]

Do you have an example of using commitizen with an ansible role? What do you use for "version_files:" for example? The examples show more python-related files like pyproject.toml, that doesn't look right for an ansible project.

I don't have anything of my own published to Galaxy, but for my Ansible projects, I'm managing my projects as if they were just Python. Have sent you an invite to one of my private repo's so you can see how I'm managing versioning.

tl;dr version - I use a combination of Poetry and Commitizen to manage my Ansible projects.

have a look at this branch: it uses an action in .github/workflows/commitizen.yml to bump the version and commit back to the originating branch.

If I read your action correctly, then it would appear you want to bump versions with every push to main. This kind of makes sense to me but looks like you end up having to do an immediate pull back to your local repo each time to reflect the tip of the main branch. If that's ok to live with, then I think what you have proposed is valid.

[stefangweichinger]

Thanks for sharing.

• poetry does not fit my project, as it's python-specific afaik?
• you run no github actions, but do checks with pre-commit (for example ansible-lint; I might do that as well)
• you run commitizen in pre-commit .. I wonder if that is better than running it in a github action. maybe that would help avoiding that additional pull you mentioned, right?

I currently play with testing stuff locally using act ... interesting, but adds even more complexity right now ;-)

[stefangweichinger]

@arrrgi if you find the time, pls check #130
I think I would merge this for a start. Thanks.

[arrrgi]

poetry does not fit my project, as it's python-specific afaik?

Poetry isn't strictly limited to Python only projects. This works really well for me in conjunction with Renovate bot on my Ansible project repo's to keep my Galaxy imports and prod / dev tool dependencies updated from the upstream releases, which coincidentally, is why I raised this request to begin with 😄

[arrrgi]

• you run no github actions, but do checks with pre-commit (for example ansible-lint; I might do that as well)

That's because I'm not running any molecule tests against my collection/project - I have a lab that I use to test locally with on physical machines. I'll probably add some CI tasks later down the track for mkdocs but my needs are simple.

• you run commitizen in pre-commit .. I wonder if that is better than running it in a github action. maybe that would help avoiding that additional pull you mentioned, right?

pre-commit and cz are great to run locally in your development environment to ensure you are at least meeting the bare minimum standards, they're just linters run by git-hooks which will help you keep obvious things out of your CI process by stopping them before they make it into your Git remote, and if you're limited on free GH Actions hours, then may as well have it doing high value tasks like your tests and leave linting to your local environment

What about collaborators who don't actually install pre-commit, cz and the git hooks?

This is where it's useful then to have commitizen and ansible-lint in your GH Actions, this combined with protected branches can help you enforce some of your standards for collaborators if you feel that way inclined.

[stefangweichinger]

Understood! So basically all this means that I learn about using pre-commit, commitizen and how to use tags ;-)
Great. I think I add the tags and the pre-commit stuff first, as in #130. If that works well, gh actions for that might follow. I had the workflow in a branch already. So far I am the only one committing to main, no team expected ...

[stefangweichinger]

@arrrgi release with tag triggered.
I was able to install the specific version with:

 ansible-galaxy install stefangweichinger.ansible_rclone,0.1.0

If you agree, we might close this issue then. Thanks.

Optionally we can continue discussing further improvements.

[arrrgi]

Nice, I've closed this issue now as I can see a release with that version on Ansible Galaxy now. Great work!

[stefangweichinger]

Thanks for that, your request and the help along the way. Appreciated it.