DB seed script

[pablobm]

Another extraction from #6424

In order:

1. Extract the code of the oauth:register_apps task into a method, to allow reuse.
2. Use this to create an initial user admin.
3. Run yarn install in bin/setup, or it may not work.
   • Related enough to this work. I was trying to get a user created by running bin/setup, which includes db:prepare and in turn runs db:seed.

This takes inspiration from @mmd's https://gist.github.com/mmd-osm/a3a0b5a8799a333e7fae578038aa7a93, but is much simpler. We can think about adding more in the future.

Also related to @gravitystorm's #3101 (I should have a look at that).

[tomhughes]

If we're going to use db:seed to set things up then do we still need oauth:register_apps as well?

[tomhughes]

The rails template actually has this if node support is enabled:

  # Install JavaScript dependencies
  system("yarn install --check-files")

Not sure if the difference is meaningful though...

[pablobm]

Good call. I suspect that it's a bit faster as it won't traverse the dependency graph twice. In any case, when in doubt I prefer to do exactly as provided by Rails. Changed now.

[pablobm]

I think that oauth:register_apps is still useful for people who don't through the bin/setup route, or if something goes wrong and the rake task still needs to be run.

[gravitystorm]

We use bundle exec bin/yarn install in the install notes, Docker file, and vagrant provisioning, and so I would expect this to be consistent with those.

[pablobm]

How about going the other way around?

• From the discussion at Vagrant and Docker installations are unmaintained #2344, I think we agree that we can drop Vagrant, so let's do that: Remove support for development environment with Vagrant #6438.
• Then there's the devcontainer support coming up (Support for Development Containers (devcontainers) #6424) which will lead to dropping the "manual" Docker option and related files.
• The install notes are slightly different: it makes sense to simplify them and therefore we can remove the --check-files option.
• Then there's the bin/update script comes from the update to Rails 5.2.0. Nowadays you do rails app:update, I think that can be removed too (different PR).

All this is in the spirit of trying to stay as similar to stock Rails as possible, which will help in future updates.

Thoughts?

[gravitystorm]

I'm happy to align with upstream. My main concern, by far, is to make sure that what is written in the install notes (including any options) is as close to possible as what is done in CI. We've had so many cases over the years where the install notes don't work, and we haven't noticed because CI was doing something subtly different, and who knows how many people tried and failed before anyone contacted us.

[pablobm]

Makes sense 👍 In that case: happy for me to leave this as is and update the install note in this PR?

Tangentially: I should review the install notes. I think I noticed some inconsistencies there. But that'd be separate work.

[gravitystorm]

We should avoid putting non-essential data into the seeds file. This file should only contain the data that's essential to running the site, in all deployments, since the seeds can be run in all environments (test, development and production). These seeds can end up in production databases, perhaps inadvertently, depending on which commands a sysadmin users to set up the database.

See #3030 (comment) for more details on this.

[pablobm]

Sounds good. I'm thinking of two options:

1. I turn this into a dev:populate task, with guards to avoid running on production.
2. I remove this script (keeping the refactor and the bin/yarn thing), and we focus on getting your dev:populate task (Create a dev:populate task to add fake data to your dev environment #3101) through. This can be augmented with the new Oauth::Util.register_apps utility.