Update module github-release action

[bastelfreak]

@rwaffen implemented a nice action that creates github releases: https://github.com/voxpupuli/modulesync_config/blob/master/moduleroot/.github/workflows/release.yml.erb#L35-L40

As you can see here: https://github.com/voxpupuli/puppet-quadlets/releases/tag/v1.0.0

I observed two things:

• The GitHub release will be created even if publishing the forge release did not work. Should those steps depend on each other?
• The release artifact for a puppet module is a .tar.gz file. Should we add that to the GitHub release?

[wyardley]

It would also be great if the release getting cut could run directly in CI vs. the current process of cloning the main repo and running the release task locally.

[wyardley]

The release artifact for a puppet module is a .tar.gz file. Should we add that to the GitHub release?

That seems like a good idea to me: 👍

[rwaffen]

It would also be great if the release getting cut could run directly in CI vs. the current process of cloning the main repo and running the release task locally.

I don’t understand what you want to say with this. What’s wrong with this in your opinion? Can you please go more into detail? I’m happy to change this, but I simply don’t understand it 😅🤔

[wyardley]

What’s wrong with this in your opinion?

You mean wrong with this proposal, or wrong with the current process? As I understand it, the intent here is to create a release PR, correct? Didn't mean to take this in an OT direction.

What I'm saying (just commenting via a thread in IRC) is that it would also be nice at some point if it were possible to somehow have a workflow in GitHub Actions could run the rake release task vs. checking out the repo locally and running it. It's not that difficult, of course, just always nice when things can be automated.

Probably some technical details that may make it hard to do safely / securely, so appreciate it may not be possible, just kind of a "it would be nice" type of aside.

[bastelfreak]

I think our 'release process' are three steps right now:

1. prepare the release; update REFERENCE.md, metadata.json, CHANGELOG.md
2. the release rake task that creates a git tag, bumps version in metadata.json, pushes the tag + commit
3. build the .tar.gz, upload it to the forge, create github release

It's possible to enhance all of those steps. Why I created this issue: To improve step 3 and attach the .tar.gz to the github release.

Step 1 and 2 currently run locallly. And I would like to have an option to run them locally or in CI. And I think @wyardley had the same idea.

[rwaffen]

ah okay, got you totally wrong.... my intend and the thing initially mentioned in the first post here in the issue was only to generate the gh release page, nothing else.... but doing more and having a more complete and also streamlined release process is totally understandable. sry for the confusion :D

[wyardley]

Yeah, sorry, I made an aside about it on IRC, and Tim just mentioned maybe commenting on it here; sorry for the lacking context in my earlier comment.

Side note: there is some prior art for tools that automate release creation (tools like release-please, but most of them use commit messages vs. labels as the source of changelog information. I personally have had good experiences with semantic-release and its ilk, but also understand Vox's reasons for doing things the way we do with labels.

Also, if it's at all helpful for any of this, also played around recently with using a GitHub app and, e.g., actions/create-github-app-token@v1 for things that need to commit to git. You still need a private key as an org or repo level secret, but it's a bit easier than managing a bot account for things that need to comment / push / etc. as a "user", or need to be exempted from branch protection requirements or the new rulesets. So throwing that out there (I can provide some concrete example snippets if needed) if that's at all helpful vs. having a real "user" do things like PR creation, etc.

[bastelfreak]

A quick update here:
For each pushed tag, we run two jobs, one to create the module artifact and upload it to the forge. And thanks to the great work from @rwaffen , we've a second job: https://github.com/voxpupuli/modulesync_config/blob/master/moduleroot/.github/workflows/release.yml.erb#L36-L41

The source is at: https://github.com/voxpupuli/gha-create-a-github-release/blob/v1/action.yml

This creates github releases, like this: https://github.com/voxpupuli/puppet-bolt/releases/tag/v1.6.0

it probably makes sense to run those two actions in a single job. That enables the second action to access the module artifact from the first action. That can be attached to the github release.

voxpupuli/gha-puppet#66 is the first step to automatically generate release PRs.