How to use dwylbot in any dwyl project (including client projects in different Orgs)

[nelsonic]

we use the dwyl GitHub Workflow in various dwyl and client projects.
It would be useful to be able to use dwylbot for any project.
what is required to make this work?

[nelsonic]

Do we want dwylbot to be able to add/remove labels from issues/PRs ? see: #6

[iteles]

@nelsonic Definitely! That's a big part of what we want to automate. More in #5

[nelsonic]

@iteles thought so, just want to confirm it, because it means we need to ask people for permissions when they are Authenticating to use dwylbot for their org/app. 👍

[SimonLab]

Now that Github Auth has been added to the application (see #29 and #27 ) I think the next step is to create a UI where the users can select/unselect the Github repositories where they want dwylbot attached to them.

[SimonLab]

These are the cases where we need dwylbot app to use a user Github oauth token:

• list organisations/repositories of the user where dwylbot can be applied to
• create/delete webhook on repos to notify dwylbot about new issues and PRs created
• create new comments on issues/PR on private repositories
• create new comments on issues/PR on public repositories - anyone can add a comment on public repos the oauth user token is not necessary, the access_token of the dwylbot application can also be used but to have a higher limit requests rate on Github API using the user token might be a good idea

[SimonLab]

I think this issue is the main step of the project and needs to be tackle first to allow dwylbot to be used widely.
To recap and to add a bit more details we need:

• Users to signin with their Github account. On the first signing the users will be asked if they agree to give some restricted permissions to dwylbot. This will allow dwylbot to create webhooks, comments, adding and removing labels. see review Github OAuth flow #31 (review Github OAuth flow)
• Users can choose which of their public repositories they want dwylbot to monitor on. This solution will use Github API and Postgres. Calling the Github API each time a user want to add/remove a webhook on a repo can be slow. Moreover it is not possible to know (without creating a bunch of API requests) which repositories have already the dwylbot webhook activated so we need to save this state in Postgres each time the user active or desactivate dwylbot
  • Get list of repositories with the Github API
  • save the list of repositories in Postgres
  • create a "sync" button which update the list of repositories.

This Travis UI is one way to resume this issue:

[nelsonic]

@SimonLab agree. 👍

[SimonLab]

I've had a better look at how Travis communicate with Github:

• enable Travis on a repo create a Service (or integration) on the repos. See settings/services & integrations
• the "sync account" only get the list of repositories of the user. It doesn't update the status of Travis on the repositories (active inactive).
• Deleting manually on the service on Github will not update the status in Travis

This give a better understanding on how dwylbot should/can work with Github and Services/Integration

[SimonLab]

Some updates on how to deploy dwylbot to multiple repos and organisation. I've played the last days with Github App, see #51 and think it might be a good use case for dwylbot. If we decide to use Github Apps the flow of the application will change a bit as the API is not the same for Github APP:

1. Welcome page and login page: This is the main page of the website, the user can read more about the features of dwylbot and can login using her Github account and the OAuth credentials from the Github App
2. List organisations and profiles where dwylbot is active (https://developer.github.com/v3/apps/#list-installations-for-user). This page show all the organisations where dwylbot is installed on. The user will have the possibility to install dwylbot to other organisation where she is an admin or to unistall dwylbot. Both of the last features will be done via Github (button which will redirect to Github settings of the app)
3. List repos of an organisation where dwylbot is active. From the previous step the user can click on an organisation to get more information about which specific repositories are using dwylbot. The user will also have the possibility to uninstall dwylbot from a repo (redirect to the Github app settings) see https://developer.github.com/v3/apps/installations/#list-repositories-accessible-to-the-user-for-an-installation

So this version using Github App used fully the functionalities and UI given by Github to manage the installation of dwylbot on organisations and repositories. The application display a simple UI to let know where dwylbot is active on. This make it easier to for us to develop as we delegate all the installation process to Github instead of using OAuth. Also at this stage Github doesn't provide an API to install an application, you have to use their UI.

This new flow also allow us to focus our time on the rule engine of dwylbot which is the other main part of dwylbot!

@nelsonic @iteles @markwilliamfirth does this make sense? any thoughts on this flow? More details needed? I'd like to start using Github App but let me know if this is not the best way to implement at the moment.

[ghost]

@iteles @nelsonic do you have an opinion on this? Simon and myself are leaning towards going with GitHub apps and eventually releasing dwylbot on the marketplace. Seems like a good idea due to the infrastructure that will be built around the marketplace and also to generate publicity for dwyl - what do you think?

[ghost]

This now works 👍