Supporting other GitHub Orgs and accounts

[genebean]

Opening based on a conversation on Twitter here

I would like to be able to use this awesome tool for modules spread across multiple GitHub organizations and personal accounts. What I’m envisioning is being able to pull module repos into this app in much the same was as you add them to the GitHub Slack app: via subscribing to either an entire organization, an entire personal account, or an individual repository.

My two use cases are:

• My team at Puppet is response for all modules in two GitHub organizations and a couple in the “puppetlabs” organization.
• Personally, my friend @thespain and I each have modules in our personal accounts that we co-maintain

I’d like to be able to use this tool to keep up with team and personal things and would also like to be able to filter by account/organization.

_{Sent with GitHawk}

[Flipez]

I like the idea und want to support this, but there are a few things we need to take care of.

First all stuff we do can be divided into tasks which poll information and tasks where information is pushed to.

First part is easy, the polling:

• metadata about the module like supported os, puppet version
• we want to clean up labels
• any other "we want our repo to be like x, does it match?" stuff

Second part is tricky:

• changes due to actions like pushing, merging or closing
  -> is the PR still mergeable?
  -> does this affect other PRs?

Normally the first part can be done with polling only. So we could implement some sort of log-in and allow you to select some of your repos which we take care of.

But:
a) combining polling and pushing does speed up reaction times
-> due to api limitations we could to large jobs only once per day or so
- if you change a label or something it would take forever to revert this
b) what if multiple users monitor the same repo?
- especially for stuff like adding or deleting labels and comments this could be tricky

We currently have the application installed in the voxpupuli organization and imho github apps are already a bit difficult to understand.

So how could we solve this?

Best way I see would be that everyone can install this app to its repositories/organizations. After that we scan which repos the user has access to and let him select these repositories if they are not yet in our database (to avoid duplicate actions).

I am not suire about the technical details yet (and propably missing something) but this could work.

@bastelfreak any thoughs?

[genebean]

Those points totally make sense to me. I guess, though, that I’d already assumed the GutHub app would be installed in multiple places instead of just in y’all’s organization. Thanks for looking into the feasibility of this!

_{Sent with GitHawk}

[genebean]

Just wanted to follow up on this and see what you and @bastelfreak think next steps are. I’m happy to try and help once a plan is established.

_{Sent with GitHawk}

[Flipez]

Hi @genebean,

unfortunately there aren't any news yet. The last weeks were pretty busy and we had not much time planning or even working on new stuff (but we did talk about it).

Both @bastelfreak and I think this is a feature we need to have at some point (not too far in the future) but first we'd like to get some more basic automation stuff to work to gain traction in the community and get more of an feeling what people out there want to have.

Once we figured this out and added a couple more features we should have a more clear view on how multi-orgs could look like.

[genebean]

Just thought I’d circle back and see if some of the work mentioned in a recent twitter post helps this along any.

[bastelfreak]

Hi @genebean, a short update on this one:

• there is currently one known bug: Some updates to be able to create multiple mirror services with specific configurations puppet-kafka#258 We have/had a race condition where one action, commenting on a PR, triggered the same action again. this happened for comments on broken CI and merge conflicts.

this was caused by multiple things:

• Enhance validation logic #196 logic for commenting based on broken CI wasn't perfect
• https://github.com/voxpupuli/vox-pupuli-tasks/pull/199/files a missing uniq contraint in our DB lead to multiple pull request records in the database
• we don't know yet why we have multiple records in the DB, but since we now have the constraint, we should find the code
• github api rate limit is rough. we hit that if we want to reindex all PRs but we don't honour the limit, we just requeue the job

we made great progress this week to track those issues down. I hope that we can finally fix this next week. afterwards we can try to setup the app for another namespace.

[genebean]

Thanks a ton for the update! I really appreciate it!

[genebean]

Heeeey @bastelfreak - any update on this? Just curious