User tests: Successful: Unsuccessful:
We have areas in the code that will always require a bot account to ensure we have the permissions to do something. Using the DI container, we're unable to load a bot account without repeating the provider's code and manually building a Github object with a bot account.
To get around this, I've created a GithubFactory which has the logic that was once in the provider and added a flag that will force the returned Github object to be that of a bot account instead of potentially receiving an instance with a logged in user.
I found one place in the code where we had something commented out as needing a bot account, so I've updated that code to use this as a proof of concept.
There's a part of me that doesn't think we'd generate enough traffic to need multiple bots, but who knows what would happen if we turned off that other tracker thing today or if we added more projects to this app, so scalability is definitely a good idea.
Let's merge these two pulls together, that definitely puts us on the right path for addressing a lot of the issues we've been looking at.
Let's merge these two pulls together
How to do it?
Make a third branch merging the branches of these 2 PRs together and go from there.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-07-24 18:53:27 |
I think the bot accounts should be project specific. Not sure if we need multiple accounts or a dedicated bot for edit and admin tasks would be enough.
I think we should also think about mixing public and private projects so maybe we should also think about a "checkout bot" for private projects.
The Factory however is pretty good, maybe we can combine this with #337