proof of concept for GitHub action that opens an issue for a PR

[trz42]

Making it a draft for now. Just a first attempt to automatically create an issue for a PR that is opened. We might want to add some convention that a PR that needs involvement of the build bot contains some specific keywords in the description or in the title and add some logic to the action such that it not always creates an issue.

Example of its use via https://github.com/trz42/software-layer/pull/81

[eessi-bot[bot]]

Instance eessi-bot-mc-aws is configured to build for:

• architectures: x86_64/generic, x86_64/intel/haswell, x86_64/intel/sapphirerapids, x86_64/intel/skylake_avx512, x86_64/amd/zen2, x86_64/amd/zen3, aarch64/generic, aarch64/neoverse_n1, aarch64/neoverse_v1
• repositories: eessi.io-2023.06-compat, eessi.io-2023.06-software

[eessi-bot[bot]]

Instance eessi-bot-mc-azure is configured to build for:

• architectures: x86_64/amd/zen4
• repositories: eessi.io-2023.06-software, eessi.io-2023.06-compat

[eessi-bot-surf[bot]]

Instance eessi-bot-surf is configured to build for:

• architectures: x86_64/amd/zen4, x86_64/amd/zen2
• repositories: eessi.io-2023.06-compat, eessi.io-2023.06-software, eessi-hpc.org-2023.06-software, eessi-hpc.org-2023.06-compat

[eessi-bot-toprichard[bot]]

Instance rt-Grace-jr is configured to build for:

• architectures: aarch64/nvidia/grace
• repositories: eessi.io-2023.06-software

[ocaisa]

I think this will work but I am not sure it is necessary. If the bot has permission to write a comment in an issue, it also has permission to create the issue in the first place.

It may save you from a race between bots to create an issue, but it also adds another step to configuring the bot.

[trz42]

I think this will work but I am not sure it is necessary. If the bot has permission to write a comment in an issue, it also has permission to create the issue in the first place.

It may save you from a race between bots to create an issue, but it also adds another step to configuring the bot.

Hmm, don't really see the additional configuration step. What happens now is the following:

1. PR opened $\rightarrow$ all running bot instances receive an event and each creates a comment ala I'm alive. I can build for ...
2. Maintainer adds a comment to the PR with build commands $\rightarrow$ all running bot instances receive an event, report back that they received the event (create a new comment in the PR), check if they need to launch build jobs and for each submission they create another comment. The latter comments are updated as the job progresses and the tarballs may eventually be uploaded. (Also if an instance encounters a problem in checking out the PR, it reports it with a separate comment to the PR.)
3. Finally, when the PR is closed/merged each bot checks if there is any data to be cleaned up and reports about that in another PR comment.

What has to be changed on the bot side is "only" figuring out which issue corresponds to the PR if any exists. If such an issue is identified it would use that to create comments. If commands are sent from the issue, this is easy. If they are sent from PR commands we need to implement some means to find it, e.g., searching for or accessing issues that reference the PR. There we would have to avoid that other issues referencing the PR might be found ... To avoid such complications, I'd change the bot code such that it doesn't act if the command is sent from a comment to the PR. This needs to be investigated a little more. Ideally one can link the PR and the Issue in a simple easily verifiable way.

[laraPPr]

@trz42 Can you retarget this pr?