Update self hosting docs #6877
Update self hosting docs #6877
Conversation
| ## Persistence | ||
|
|
||
| To enable Redis-backed GitHub token persistence, point `REDIS_URL` to your | ||
| Redis installation. |
There was a problem hiding this comment.
Refs #6854
I think we can probably just remove this note. As I understand it, in order to need/use this, a user would have to set up their own GitHub OAuth app to collect tokens for their pool. I think this situation is so specialised to our instance that we can just remove this note rather than documenting the process for running a token pool. Does this seem reasonable?
All we say about GH_CLIENT_ID and GH_CLIENT_SECRET in the server-secrets docs is "These settings are used by shields.io for GitHub OAuth app authorization but will not be necessary for most self-hosted installations"
There was a problem hiding this comment.
As I understand it, in order to need/use this, a user would have to set up their own GitHub OAuth app to collect tokens for their pool
Isn't the OAuth just a means for soliciting tokens and then filling the pool though? On the off chance a self-hoster did find themselves hitting Hub's 5k hourly limit, I think they'd be able to resolve by getting one or two users (presumably another member of their team) to provide a token which they could stash in Redis
There was a problem hiding this comment.
It is, but I don't think we provide any alternative way to populate the pool, do we?
There was a problem hiding this comment.
Let me know if my understanding is off, or if I'm just missing something, but I'm trying to make a distinction between the Shields server loading the tokens from the configured Redis instance, separately from how the tokens get into Redis in the first place.
I know our server also provides the means to accept donated tokens and add those into Redis, but my understanding is that the piece that initializes/loads the tokens is actually agnostic of the mechanism used to insert the tokens to the Redis store. I.e., if I were to manually create a new token and use a script/admin console/whatever to add my token to our Redis instance on Compose, that'd be just like all the other tokens and pulled into the Shields runtime where the server wouldn't care how that token originally got into Redis, wouldn't it?
There was a problem hiding this comment.
Yes. If you wrote your own script to insert tokens into a redis instance, that would work (I've not actually tested it), but we don't provide one. The pooling code doesn't care how the tokens got there.
Do you think that is a scenario we want to explicitly document for self-hosting users?
There was a problem hiding this comment.
Do you think that is a scenario we want to explicitly document for self-hosting users?
I think I'm okay with the proposed changes as-is since it's highly unlikely anyone would need it and the current text can obviously be a source of confusion for users. I just wanted to get clarity on whether the token pool was tightly coupled to the OAuth app approach
|
No description provided.