Create an artifacts job

[jjeffers]

This adds a workflow where the last 3 Katello versions changelogs and cherry-picks are generated and uploaded as an artifact.

[jjeffers]

The actions did not complete successfully here, but they did on my fork... I'll try and see why it is different.

See: https://github.com/jjeffers/tool_belt/actions/runs/730725390

[jjeffers]

I think the failures are due to not having the repository secret for GH_ACCESS_TOKEN, which is exported in the workflows as ENV variable GITHUB_ACCESS_TOKEN.

[ehelms]

What is the intended workflow, as a maintainer, to trigger the run of this and creation of the artifacts?

[jjeffers]

What is the intended workflow, as a maintainer, to trigger the run of this and creation of the artifacts?

Ideally, every configuration change would generate an updated set of CHANGELOG.md and cherry-pick summaries.

[jturel]

There is not always a config update that coincides with the need to generate a new changelog or set of cherry-picks. And not every config update means that a new changelog or cherry-pick report should be generated.

[jjeffers]

There is not always a config update that coincides with the need to generate a new changelog or set of cherry-picks. And not every config update means that a new changelog or cherry-pick report should be generated.

I agree that most changes don't need a newly generated set of reports, etc. I am more concerned with eliminating as many manual steps as possible in the release process. So for the relatively few instances where we are concerned or interested in these artifacts, we have a consistent, automatic generation. Hopefully, this helps to eliminate errors when folks have to do these steps by hand.

[jturel]

There is not always a config update that coincides with the need to generate a new changelog or set of cherry-picks. And not every config update means that a new changelog or cherry-pick report should be generated.

I agree that most changes don't need a newly generated set of reports, etc. I am more concerned with eliminating as many manual steps as possible in the release process. So for the relatively few instances where we are concerned or interested in these artifacts, we have a consistent, automatic generation. Hopefully, this helps to eliminate errors when folks have to do these steps by hand.

Definitely useful to automate this. I think it represents a starting point for something that we'll have to see how it plays out. Then see if there's anything we can do to get more mileage from it. For example it'd be nice to have the changelog regenerated when merging cherry picks in to one of the release branches or something like that (separate thing from this PR obviously)

[ekohl]

Suggested change

	run: bundle exec ./tools.rb cherry-picks configs/katello/${{ matrix.version }}
	run: bundle exec ./tools.rb cherry-picks configs/katello/${{ matrix.version }}.yaml

[ekohl]

Closing for inactivity. This does have potential, but I'd suggest to take it a step further and do it in the repository itself and create the PR(s). In https://github.com/theforeman/foreman-packaging/blob/master/.github/workflows/bump_packages.yml we do that.