search

EclipseFdn / eclipsefdn-github-sync

This toolset is responsible for synchronizing committers, contributors and settings across all Eclipse Foundation GitHub repositories and organizations.
Eclipse Public License 2.0
0 stars 7 forks source link

Discuss management of bots in the sync script #137

Open autumnfound opened 3 years ago

autumnfound commented 3 years ago

From an issue created through over-zealous removal of users from teams, a new script to manage bot team membership was created to handle the process rather than doing it manually. There were some discussions on potentially managing bots in the future through the sync script, though there were some concerns raised by @fredg02 about it breaking some workflows.

fredg02 commented 3 years ago

There are different aspects that need to be discussed.

  1. Should bots be actively added by the sync script based on projects-bot-api or should it ignore bot users completely (neither add nor remove bot users)?
  2. If bots are actively added by the sync script, can it be triggered manually to reduce delay?
  3. How are external bots (e.g. openshift-ci-robot and openshift-merge-robot) handled?
  4. Should bots be added to the committers team or to each repo individually?
fredg02 commented 3 years ago
  1. My use-case is to add a GitHub bot for a project. After signing up the bot-user I can instantly add it to the committers team, check on the Jenkins instance that everything works as expected and close the bug. Waiting for the sync-script to run will delay this by a few hours and break the workflow.
  2. Even if the sync script can be kicked off manually, it takes quite a while to finish. Is it feasible to have a separate script/option that only adds bot users?
  3. We don't want to add external bots to projects-bot-api. Hence we would need a separate list/api/etc to store the names of the bots and their permissions.
  4. Current process: If a bot user is added to the committers team it will automatically be added to any new repo that is created which the committers team gets access to. Otherwise it would need to be added to every new repo manually. Future process: If bot users are handled by the sync script, I assume that adding a bot to a team requires less api calls than adding it to e.g. 15 repos.
autumnfound commented 3 years ago
  1. This script wouldn't stop you from adding the bot manually, but would just supplement it and allow us to manage bots that fall off the list for whatever reason. It wouldn't necessarily add anything though in your use-case (other than the assurance that no bot gets left behind).
  2. Currently the script exists in the repo under src/gh/BotFix.js, and can be run locally whenever! Chris ran it last time, but nothing stops it from being scripted into a job somewhere or to be set up on a machine somewhere we can hit with a shell script to kick it off.
  3. I'd be open to that idea! Maybe we can make a call under the current bot API to retrieve a list of external bots that aren't managed by us. We could modify the structure a little since its a different type of bot to include those things so we can essentially set how much we trust that bot.
  4. The idea would be that teams and such are fetched in batch so that costs less overall. Adding users/bots to teams is still 1:1 though, there is no interface for adding users to multiple teams at once that I can find. So that doesn't have any gains sadly.
fredg02 commented 3 years ago
  1. & 2.: If I can either add bots manually (and they don't get removed) and/or kick off a script that quickly adds bots from the bot-api, I'm fine with it.
  2. I'm not sure if external bots should be added to the projects-bot-api, but in any case we have to make sure that external bots can get past the ECA check if necessary.
  3. I meant the difference between adding a bot to one team "foo-bar-committers" and giving the bot individual access to 15 repos. I don't think there is a use-case (yet) for adding a bot to multiple teams.
autumnfound commented 3 years ago

1/2. That's the plan yeah! I'll be pushing the patch to remove users again soon but with bots in mind this time haha! So we still have the script, and you can add manually or use the script. Its up to you!

  1. That'll be a change within EclipseFdn/git-eca-rest-api rather than here, but agreed!
  2. Gotcha, yeah, it's much better then!
autumnfound commented 3 years ago

Looping back to this, we have a basic triggered solution to re-add users. We may need to update this solution to better handle the external/sub-resource (e.g. github.com-openshift-merge) bots though, as they wouldn't be currently handled I don't believe. Once this is done, would you say this is resolved, or would you like the bot fix to be triggered as part of the sync process?

fredg02 commented 3 years ago

It boils down to the following requirements:

I think the bot fix scripted can/should run independently from the sync process, unless there are good reason to do it.

autumnfound commented 3 years ago

It boils down to the following requirements:

  • we consider the projects-bot-api to be the single source of truth for (GitHub and GitLab) bot users
  • the BotFix.js script should add and remove bot users to/from the project's committer teams based on the projects-bot-api

  • the BotFix.js script should be run from a CI (or cluster) job, kicked off on a schedule (e.g. once a day/night) and manually on demand

    • open questions:

    • how long does the bot fix script take to run?

Much shorter than the sync script, likely not more than a few minutes, if that. I've done work to minimize calls and added caching so that we can work easily within the orgs. I can look into how long this takes to run later if you want more than a vague guess haha!

* how are invitations to the organizations handled?

I think the bot fix scripted can/should run independently from the sync process, unless there are good reason to do it.

There's no real reason to add it to the sync script no. I might want to improve on the script to pull out some of the common stuff so when we do this for GL eventually it will be easy to implement and maintain. I don't think the need for scripting is there yet so that's more of a 1.x/low priority feature though.