[1/2] OLM workflow: add automatic OLM bundle submission.

[fmuyassarov]

GitHub bot account: https://github.com/nri-plugins-bot

[klihub]

The other remaining thing is what we discussed offline today: adding a secondary trigger (maybe a push to a branch or a new tag matching a pattern) which would trigger the workload but with an eventual PR filed against a test repository (which probably should be the clone of the real community operators repo under the bot's account).

[fmuyassarov]

The other remaining thing is what we discussed offline today: adding a secondary trigger (maybe a push to a branch or a new tag matching a pattern) which would trigger the workload but with an eventual PR filed against a test repository (which probably should be the clone of the real community operators repo under the bot's account).

It won't be that easy to test even with extra conditional trigger. Because, I don't have permissions to push anything that could result in the workflow to start. However, I have tested the same workflow file with only one difference being the source repo set as fmuyassarov/nri-plugins (my fork) instead of containers/nri-plugins. And the result you can see here: k8s-operatorhub/community-operators#5518.

[kad]

Generally looks ok, just need a cleanup of all debugging bits, and hardcoded versions to make it mergable.
Second thing to invistigate: don't use primary gpg private key, it should be enough to store in secrets just a signing sub-key.

[fmuyassarov]

Generally looks ok, just need a cleanup of all debugging bits, and hardcoded versions to make it mergable.

Those are added intentionally for the testing purpose. The idea is that we merge it as it is now and create an issue to test the workflow and if it behaves as it should there will be a follow up PR to clean up testing bits.

[fmuyassarov]

Generally looks ok, just need a cleanup of all debugging bits, and hardcoded versions to make it mergable.

Those are added intentionally for the testing purpose. The idea is that we merge it as it is now and create an issue to test the workflow and if it behaves as it should there will be a follow up PR to clean up testing bits.

@kad that's what we discussed with @klihub offline.

[askervin]

I think this is great work. Thank you @fmuyassarov for automating these pull requests!

I don't want to request big changes before merging the first version. Having it tested without hardcoded versions would be enough for me.

Two questions, mainly on future steps:

Testability: Would it be convenient to enable testing this workflow so that it would recognize when it is running on a nri-plugins repo fork (instead of owned by containers), and in that case it would create the pull request to the community-operators repo fork of the same owner instead of upstream? And perhaps this workflow could be triggered by a pull_request_comment like "/test-operator-release" or something (that would obviously never create pull request to the upstream repo).

Re-releasing: do we ever want to create a pull request that changes an existing release? If not, maybe we should then explicitly fail on the "Copy the bundle..." step if the version directory already exists.

[klihub]

@fmuyassarov @askervin My suggestion would be to merge this and test-drive it, so Feruz can get rid of it.

Then we can beat it into final shape with one or more new PRs as necessary. WDYT ?

[askervin]

Tried to play with this a bit, and it's quite broken.

@klihub, this looks necessary: afd0c37

Maybe we should coordinate merging so that it'll get in very soon after this one.

[klihub]

Tried to play with this a bit, and it's quite broken.

@klihub, this looks necessary: afd0c37

Maybe we should coordinate merging so that it'll get in very soon after this one.

@askervin I have updated that slightly, klihub@5b80b67, and have it on this devel/olm-bundle-submission branch. If a test trigger is used, it now files the PR against the fork of the user who opened (or reopened) the test trigger issue. Also, if filing the PR succeeded, it closes the test trigger issue in the end.

If we decide to merge this, I can open immediately a new PR with those additional commits. An alternative would be to replace this with a new PR with the additional commits included and merge that one in a single go.

[askervin]

This can be merged when we are ready to merge #464 right after it.