Maintainers bots and actions #15019
Replies: 6 comments
-
This looks like a useful tutorial: https://github-bot-tutorial.readthedocs.io/en/latest/index.html |
Beta Was this translation helpful? Give feedback.
-
These also look interesting: |
Beta Was this translation helpful? Give feedback.
-
I'm pretty positive we need a bot. I've sort of given up on actions doing more than CI -- at the moment you can't do much that is trusted inside a github action, so I think we will end up having to use bots for this stuff. That's fine, I suppose, I just wish it were a bit simpler to run this kind of task in an action. Example: adding a PR reviewer requires that the reviewer has write access to the repo. So we would need to add maintainers to a team and give them write access (note that we would still, as we do now, protect release branches, A bot, on the other hand, can have whatever token we give it. But we need to host it somewhere. We can do that in AWS -- I will just need to set it up. My suggestion for this would be to start working on bot(s) that can run in containers, and make repos for them in the Spack org. Then we can start throwing them into our AWS kube cluster and running them. The containers will need to have a way to inject a token (e.g., through an env var). That should give us what we need. |
Beta Was this translation helpful? Give feedback.
-
Another suggestion:
I also thought of using a github actions workflow, but the limitations with the permissions for forks are really frustrating :( |
Beta Was this translation helpful? Give feedback.
-
That should be pretty doable. I believe we're currently working on getting a Kube cluster setup at LLNL, so once that happens I'll start working on that. |
Beta Was this translation helpful? Give feedback.
-
@adamjstewart @tgamblin great! actually it seems like github has adressed the issue with the actions workflow since your last comment: It sounds like |
Beta Was this translation helpful? Give feedback.
-
I've been trying to think of ways to increase our number of packages with official maintainers. Here's what I came up with.
maintainers
as reviewers of PRs. This was attempted in actions: add maintainers as PR reviewers for their packages #12269, but later removed because we never got it working. I wanted to open a dedicated issue on this so we remember to try again.maintainers
as assignees for issues. This is a little harder, as we can't directly see which package is modified, it needs to be inferred from the issue title. I propose we standardize onpackage:
or[package]
in the issue title.Beta Was this translation helpful? Give feedback.
All reactions