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 trz42#81

[eessi-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]

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]

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]

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

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

[ocaisa]

We better explicitly define the permissions in the workflow file. This is the full set available:

permissions:
  actions: read|write|none
  attestations: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  id-token: write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

so we would just need:

permissions:
  contents: read  # to fetch code (actions/checkout)
  issues: write  # to create an associated issue (if necessary)

[trz42]

Added in 47e14cf

[ocaisa]

I think @laraPPr has played around with this to only trigger when certain file types are touched (in our case easystack files)

[trz42]

We should limit that, yes. Only easystack files may be too few, though. Should be easy to figure out for which files bot jobs need to run.

[laraPPr]

I was using this action for that https://github.com/dorny/paths-filter. I'm now looking to see if I can strip what we need from in it. So that we don't have to rely on external actions that much.

[laraPPr]

This pr includes the new filter #949

[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?