Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update self hosting docs #6877

Merged
merged 3 commits into from
Aug 8, 2021
Merged

Update self hosting docs #6877

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a997fe0
update node version
chris48s Aug 8, 2021
49bc6c5
remove notes on redis
chris48s Aug 8, 2021
d17aa52
Merge branch 'master' into self-host-docs20210808
chris48s Aug 8, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 1 addition & 6 deletions doc/self-hosting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ You will need Node 14 or later, which you can install using a
On Ubuntu / Debian:

```sh
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -; sudo apt-get install -y nodejs
curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -; sudo apt-get install -y nodejs
```

```sh
Expand Down Expand Up @@ -140,11 +140,6 @@ preconfigured raster server.
[raster server]: https://github.com/badges/svg-to-image-proxy
[micro]: https://github.com/zeit/micro

## Persistence

To enable Redis-backed GitHub token persistence, point `REDIS_URL` to your
Redis installation.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, but I don't think we provide any alternative way to populate the pool, do we?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


## Server secrets

You can add your own server secrets in environment variables or `config/local.yml`.
Expand Down