add: Apply seeds in cli-migrations #7914

[preetjdp]

Description

This PR adds the ability for the seeds to be auto-applied as part of the cli-migrations docker image (Reference

Changelog

• [x] CHANGELOG.md is updated with user-facing content relevant to this PR. If no changelog is required, then add the no-changelog-required label.

Affected components

• [ ] Server
• [ ] Console
• [ ] CLI
• [x] Docs
• [ ] Community Content
• [ ] Build System
• [ ] Tests
• [ ] Other (list it)
• [x] CLI Migrations

Related Issues

Solution and Design

The PR follows the existing pattern of the Docker Entrypoint file and adds a check to apply the seeds if the directory is loaded/present in the file

Steps to test and verify

The test file has also been updated to show that the seeds have been updated

• Build the cli-migrations image locally
• Run the test.sh script

Limitations, known bugs & workarounds

Server checklist

Catalog upgrade

Does this PR change Hasura Catalog version?

• [x] No
• [ ] Yes
  • [ ] Updated docs with SQL for downgrading the catalog

Metadata

Does this PR add a new Metadata feature?

• [x] No
• [ ] Yes
  • Does run_sql auto manages the new metadata through schema diffing?
    • [ ] Yes
    • [x] Not required
  • Does run_sql auto manages the definitions of metadata on renaming?
    • [ ] Yes
    • [x] Not required
  • Does export_metadata/replace_metadata supports the new metadata added?
    • [ ] Yes
    • [x] Not required

GraphQL

• [x] No new GraphQL schema is generated
• [ ] New GraphQL schema is being generated:
  • [ ] New types and typenames are correlated

Breaking changes

• [x] No Breaking changes

• [ ] There are breaking changes:

  1. Metadata API

     Existing query types:

     • [ ] Modify args payload which is not backward compatible
     • [ ] Behavioural change of the API
     • [ ] Change in response JSON schema
     • [ ] Change in error code

  2. GraphQL API

     Schema Generation:

     • [ ] Change in any NamedType
     • [ ] Change in table field names

     Schema Resolve:-

     • [ ] Change in treatment of null value for any input fields

  3. Logging

     • [ ] Log JSON schema has changed
     • [ ] Log type names have changed

[hasura-bot]

Beep boop! :robot:

Hey @preetjdp, thanks for your PR!

One of my human friends will review this PR and get back to you as soon as possible.

Stay awesome! :sunglasses:

[andrewloux]

Pretty big shift in the expectation for folks that use the image to run migrations, but not to re-seed.

Should be a behaviour that's disabled by default, and enabled on feature flag IMO.

[scriptonist]

Thanks for the PR @preetjdp ❤️

I doubt we can accept this change. More information about the reason is written down here: https://github.com/hasura/graphql-engine/issues/7914#issuecomment-1202320800

Couple of clarifications:

• Seeds are typically meant for dev/staging type envs where some dummy data needs to be added to test things. Typically seeds are applied on all envs other than production
• seeds are not incrementally applied and hence can only be applied on fresh DBs or else data conflicts are likely to happen if the seed apply is run more than once
• if the users have data that need to be applied in all envs, even production, then they should be tracked as migrations instead of seeds. e.g. values in enum tables
• In case, users want to apply seeds in certain envs, they'll need to figure out a way to manually run the seeds apply command.

[hasura-bot]

Beep boop! :robot:

Hey @preetjdp!

Sorry that your PR wasn’t merged.

Do take a look at any of the other open issues to see if you’d like to take something up! We’re around on Discord if you have any questions :smile: