Improve local secret setup
The #1973 (closed) Introduced a basic way of skipping the whole secret setup and allowed new contributors to clone the webapp and start it almost straight away. In the next iteration we could do all/some of the following:
Generate meaningful, persistent seed data
- The
npm run create-seed-datais using thefixtureLoaderwhich is primarily intended for testing. That means the test data don't have natural language strings (e.g._testuser_31583152697585instead ofjohn-smith) - Every run of
create-seed-datagenerates a new set of test data, improvement would be to have constant entities andupsertthem in the database - When we discard
rediscontainer, thewebapptries to revalidate user tokens with GitHub, fails and invalidates the tokens. That means the generated seed data won't be reusable indefinitely.
Better secret generation/handling
-
There are automatically generated secrets in the
obtain_secretsscript Those could be generated without too much of user inputWe could make this even more slick by having
npm run configurewhich would runcreate-seed-dataand runobtain-secretfor all of the values we usegenerate_passwordfor. Since those secrets require no human interaction, they can be part of the easy script. -
sourcing the secrets without user having to run
source .env -
we could only switch off specific OAuth providers if their secretes are missing (now it's all or nothing, but user might want to only test GitLab OAuth)
-
Making sure a subset of tests can run locally without the secretes, right now they seem to be failing