Reload configuration without restarting process

[jimsheldon]

Is it possible for the shields server to reload configuration from its yaml file without restarting?

[chris48s]

Is this for local dev or when deployed?

[chris48s]

Actually, I will just answer for both cases.

For production usage, docker image, etc we just run node server.js which doesn't do any kind of monitoring or reloading. For stability and predictability of service, this is a good thing and I don't think we should change it.

For local dev, we do hot reloads with nodemon. https://www.npmjs.com/package/nodemon By default it doesn't look at yaml files so that's probably why it doesn't reload the dev server when settings are changed. I've not tested, but I reckon we could probably tell nodemon to also monitor yaml files and that would also give us hot reload on settings in local dev. If you have a go at that and it works, feel free to PR it.

[jNullj]

i tested and it did not work, but i added this changes in PR #10924

[jimsheldon]

Thanks for the reply!

I am interested in self-hosting shields with a private github organization. I am hoping to avoid generating a PAT, and instead generate installation tokens from a GitHub app. I realize that shields does not support this natively, but I was hoping I could generate/update the token with a separate process, but that would require shields to support reloading its config file.

My other thought is to run postgres, and use the native token pool capability of shields. Then my external process could add/remove tokens to/from the pool. So far I haven't figured out how to run shields locally with postgres to prove this can work...

I will close this discussion.

[jNullj]

@jimsheldon after reading the updates im not sure if it still helps but but after merging 10924 if you run with nodemon (see debug:server for refrence at package.json) our config will now reload on yml config changes.
If you run inside a docker container you might also need to add a watch

[chris48s]

A few thoughts..

Reloading on changes

If you wanted to run a version of shields that does reload on changes to files, you could make your own Dockerfile that does something different here

shields/Dockerfile

Line 34 in be9cdc2

CMD ["node", "server"]

and build your own image. I'm still of the opinion that monitoring the filesystem for changes and hot reloading is not what we would want to do in production on shields.io or what we should give self-hosting users by default. In that respect, it is not something we would merge, but it is something you could do if you're willing to accept there is some downtime/instability associated with that.

Token pool

I suspect the token pool probably wouldn't do what you need for several reasons.

1. Shields doesn't talk to postgres "live". What we actually do is read all the tokens into memory on instance boot. We only interact with postgres once on boot and then when new tokens are added and removed. This is a bit non-standard, but it allows us to run a teeny tiny postgres instance for the one table of persistent state that we need. This is a good setup for us in production, but means you've got the same issue that you need to trigger reloading the server process to pick up changes.
2. You can add tokens into the pool "live" but the token pool code is tightly coupled to the idea that the way you get tokens into it is by authorising an OAuth app, and that means means you're authorising PATs.

In theory there is nothing that stops self-hosting users from using the token pool, but in reality is something that is quite tailored to our specific production needs for shields.io itself.

App tokens

Finally, if you want to run shields without a PAT, I think the next thing I would look at is whether app tokens will work for the badges that use the GraphQL API and/or badges that are not specifically tied to a repo/org. I've never tried running shields with app tokens, but I suspect you might run into something like this problem #8792 so probably best check that first locally to prove the concept before wasting a lot of time on it.

[jimsheldon]

I appreciate all of the inforomation! It sounds like we should not pursue using the token pool.

I understand that some API calls may not work, that's fine.

I have some ideas of things to try, if I make progress, I will respond here.