Open jilladams opened 2 weeks ago
I've been thinking about this and it might make more sense to create a migration for test data instead. If we were migrating a CSV, non-engineers could help develop/maintain the CSV. I'm not 100% sure if it's better. It might clearer/easier to see what we're creating.
Could we make it possible to auto publish auto content in lower envs? If not: we have to run script and then content release on Tugboat to get the content live.
If we go CSV route:
Guesstimate 5ish for now
User Story or Problem Statement
As a product owner, I want confidence that our QA has reviewed an example Regional Office that represents all the available flavors of options with Drupal.
Description or Additional Context
When using Tugboat, the database gets blown away everytime we rebuild the environment. Having a method to easily generate test content saves time with generating data examples after every rebuild, and can help guarantee we are remembering to review all data cases when we do things like design reviews (#17966 ).
The one tradeoff here might be effort. Not only initial effort, but if the Drupal data model continues to evolve, the script needs to stay in step. To discuss when refining.
Eng notes
We can make content generation scripts that can be run on the Tugboat terminal, to generate content.
We could also do this via migration. Would need to build the migration (Drupal), and then create a CSV that can be migrated in when we need it (more notes in comments).
Acceptance Criteria