Create a dev:populate task to add fake data to your dev environment

[gravitystorm]

This is an alternative approach to #3030 with the same overall goal. It's based on the approach that I outlined there, namely being idempotent, and using Faker and FactoryBot to cut down on the code required, and being a separate task so that there's no overlap between (expected) seed data and (optional) dev data.

@tordans what do you think? If you have the chance to try this out, and see if it would work as the basis for what you were trying to do, that would be great.

At the moment it only creates one user and one diary entry, since it was piecing together the FactoryBot strategy along with the steps to achieve idempotency that was the bulk of the work in this PR. I'm hoping that it's straightforward to expand to more data.

[gravitystorm]

Does anyone have any feedback on this PR, or #3030? Useful, not useful, good approach, etc?

[harry-wood]

I was just giving this rake dev:populate a try. It works!

I was pondering whether the naming development.rake and namespace dev is the best way to group rake tasks. If so, then I guess the existing contents of auto_annotate_models.rake should be merged into this file? but otherwise maybe it's better to call this something more specific. populate.rake perhaps.

But anyway... looks good to me

[gravitystorm]

I was just giving this rake dev:populate a try. It works!

Great, thanks for testing it out! Glad to hear that it worked.

If so, then I guess the existing contents of auto_annotate_models.rake should be merged into this file? but otherwise maybe it's better to call this something more specific. populate.rake perhaps.

The auto_annotate_models.rake was generated by the gem, so I'd like to leave it as-is to smooth any future upgrades.

I'm happy to rename development.rake to populate.rake - I didn't put much thought into the name, only that we have an existing testing.rake with test-related stuff in it.

[harry-wood]

Ah. That all make sense yes. I have some recent experience of having many rake tasks in a bit of a mess, but we're long way off that here anyway.

[gravitystorm]

Rebased to resolve merge conflicts.

[Robbendebiene]

I'm currently also in need of a dummy user account, because I cannot easily create it via the web interface since the server is running in a docker instance on Github actions.

I first tried the following approach which is a modified version from this issue: #3136

bundle exec rails runner 'pw_hash = PasswordHash.create("test.user@osm.org")
          admin = User.find_or_create_by(
            :email => "test.user@osm.org",
            :email_valid => true,
            :display_name => "My New User Name",
            :status => "confirmed",
            :terms_seen => true,
            :terms_agreed => Time.now.getutc,
            :data_public => true,
            :pass_crypt => pw_hash
          )
          admin.save!'

But when trying this on my local server I cannot login via the website (server log.txt)
I'm pretty sure I'm using the PasswordHash.create() function the wrong way, because in the official code it is only used for pass_salt.

In your approach the user name (and password?) seems to be generated and thus (kind of) unknown. For my use case it would be nice to have a fixed user account, with known name and password.

Thanks in advance.

---

My use case:
Set up automated testing for an OSM API implementation. I decided against using the dev server (https://master.apis.dev.openstreetmap.org/) because the credentials will be publicly available on Github. I also don't want to endlessly pollute the server.

[Robbendebiene]

All right, took me a while, but now I've got a basic idea of how the PasswordHash.create() function works. (I'm new to ruby and its syntax)

The code below is now working for me.

bundle exec rails runner '
          pass_crypt, pass_salt = PasswordHash.create("test")
          admin = User.find_or_create_by(
            :email => "testuser10@osm.org",
            :email_valid => true,
            :display_name => "testuser10",
            :status => "confirmed",
            :terms_seen => true,
            :terms_agreed => Time.now.getutc,
            :data_public => true,
            :pass_crypt => pass_crypt,
            :pass_salt => pass_salt
          )
          admin.save!'

[pablobm]

I think this can be closed after the merge of #6432

[gravitystorm]

It certainly covers similar enough ground that I'm happy to close this!

I'll look at introducing faker, using factorybot for creating objects, etc, in a fresh PR.