The state of the galaxy release

[AFriemann]

So, i've been struggling with both this and the ssh-hardening playbook for the past two days.

Most of my issues came from the fact that readme contents have diverged from the releases that are available in galaxy.

I know that it is entirely possible to run both playbooks easily from git directly, but keeping the releases available in galaxy combined with the fact that the readme on galaxy is apparently pulled from master is almost malicious.
The last release on galaxy was a year ago and current master is 33 commits ahead; the ssh-hardening repo looks very similar.

Is there any plan to fix this situation in the future? What is the intention towards galaxy?

Why are releases apparently not kept up-to-date?

Do you need support in automating anywhere?

[rndmh3ro]

Thanks for bringing up your concerns!

the fact that the readme on galaxy is apparently pulled from master is almost malicious.

I wasn't aware of that. This sure sounds like a bug on galaxy side.

Is there any plan to fix this situation in the future?

What situation do you mean? That galaxy shows the wrong readme?

What is the intention towards galaxy?

Galaxy is the main distribution of roles and will probably stay that way, unless RedHat does something else.

Why are releases apparently not kept up-to-date?

If you mean why there is no newer release than 5.2.1: I haven't found the time, sadly.

Do you need support in automating anywhere?

Yes, absolutely. Right now doing releases is a manual process. For this I use the github_changelog_generator to automatically create a nice looking and complete changelog, then manually tag and release on Github (see for example https://github.com/dev-sec/ansible-os-hardening/releases/tag/5.2.1). Galaxy automatically pulls the latest releases afterwards.

If you want to help automate this, let's talk! :)
I'm open for using travis, or github actions or whatever makes this easier.

[chicks-net]

I'm happy to help with this also. I've done a lot of CI work in jenkins and buildkite. I'd love for a reason to play with github actions.

[rndmh3ro]

Sounds great.

Just writing down my ideas what is needed/how this should work.

• There is a CHANGELOG: https://github.com/dev-sec/ansible-os-hardening/blob/master/CHANGELOG.md
  • Right now I create the changelog with https://github.com/github-changelog-generator/github-changelog-generator
    • This peace of software queries the github-api for closed issues and PRs and creates a changelog-file
  • I want to continue this whole changelog in its current form, as well as put the individual changelog into the releases-page (https://github.com/dev-sec/ansible-os-hardening/releases/tag/5.2.1)
  • This somehow has to be populated, probably in a PR. Right now I commit and push to master manually
• With the click of a button, a new release should be created. I should have to insert the changes (from the CHANGELOG, or somehow automatically?) and specify a version.
• Bonus: Send an email to our mailinglist.

[micheelengronne]

Do you know semantic-release ? It can create a release by simply creating a commit with the angular convention. We use that internally, works like a charm.

[AFriemann]

What we're using right now on our internal projects is release-drafter. There is github action (https://github.com/marketplace/actions/release-drafter) for it that should be a good fit.

I don't think it offers a way to update the CHANGELOG.md, but it neatly keeps releases up-to-date with PRs and reduces a release to a single click.

What is the process to push the release to galaxy, or is that picked up automatically? @rndmh3ro

[AFriemann]

Additionally I found this

https://github.com/marketplace/actions/release-notifier-action

that might be a good fit for the mailinglist message

[rndmh3ro]

Do you know semantic-release ? It can create a release by simply creating a commit with the angular convention. We use that internally, works like a charm.

I know this. Since these roles rely on external contributors, I don't know if its a good idea to force specific commit-styles on them.

What is the process to push the release to galaxy, or is that picked up automatically? @rndmh3ro

That's automatic. As soon as there is a new tag/release in Github, Galaxy pulls it.

What we're using right now on our internal projects is release-drafter. There is github action (https://github.com/marketplace/actions/release-drafter) for it that should be a good fit.

This looks pretty great! I'd definetly use this, once this PR release-drafter/release-drafter#259 is merged.

[wkhayrattee]

Hey guys, just curious if this has been fixed as I see the latest commits being reported by Galaxy now:

[ivanovv]

@7php I think Galaxy uses releases/tags, and there were no changes there:

rndmh3ro released this on 9 Jun 2019 · 33 commits to master since this release

[rndmh3ro]

@ivanovv is right.

[rndmh3ro]

I uploaded a new version!

I'm still looking for ways to automate this so if anyone wants to do this, tell me!

[rndmh3ro]

Okay,

I started experimenting. I can automatically update the changelog after closed PRs/issues.

Here's the github action: https://github.com/dev-sec/ansible-os-hardening/runs/647446423
And here's the generated changelog: https://github.com/dev-sec/ansible-os-hardening/blob/changelog/CHANGELOG.md

Now this is still missing:

• With the click of a button, a new release should be created. I should have to insert the changes (from the CHANGELOG, or somehow automatically?) and specify a version.

For this maybe this works: https://github.com/marketplace/actions/ensure-release.
Combine with the output of the github-changelog-generator and create a draft release. Then I manually check this draft, give it a tag and we're good.

• Bonus: Send an email to our mailinglist.

[rndmh3ro]

Next step:

I have a workflow that runs on every merged PR and then does the following:

• get the previous tag (to generate the changelog from this tag)
• get the next tag with the help of labels on PRs (major, minor, patch)
• generate a changelog
• create a release draft with the generated changelog and the release- and tag-name of the next tag
• (if I am confident with the created release draft, I can publish it automatically, too)

This works good so far in my personal repo. I'm going to put it into the hardening-roles next and do a little write-up.

You can find the workflow here: https://github.com/rndmh3ro/ansible-os-hardening/blob/7.0.0/.github/workflows/release.yml: