#migration in ci - going from push:true to push:false

10 messages · Page 1 of 1 (latest)

brittle marsh
#

Hi

I am trying to integrate migrations in my CI.

As I have previously connected to my db with "push: true", I get following message, when trying to migrate a new change:

? It looks like you've run Payload in dev mode, meaning you've dynamically pushed changes to your database.
If you'd like to run migrations, data loss will occur. Would you like to proceed? › (y/N)

I already run it locally once (connecting to that same db) and accepted. push is also set to false now. I then added a new field, and this message keeps coming up. How is Payload tracking this? Is there a way to tell it to use migrations from now on? The only solution I found yet, is deleting and recreating my database and ensure to never use push:true. But that doesn't seem sustainable.

Does anyone have a better solution?

crisp prairieBOT
plush oasis
#

it's being tracked here

CleanShot_2025-02-25_at_18.06.20.png
dense coral
#

Hello @brittle marsh I think you need to remove the dev entry in the table

DELETE FROM payload_migrations WHERE name='dev'

hard field
#

You do not migrate your dev database, it is managed by push true.

Once you are happy with your changes create a migration for another database.
Use a localdb to test with simple changes. Check the files in migrations, you will understand a lot more.

fallow epoch
#

Hi guys,

See here: https://github.com/akhrarovsaid/payload-v3-faqs/blob/main/README.md#help-ive-connected-to-my-prod--staging--test-db-while-running-a-dev-environment-now-im-getting-it-looks-like-youve-run-payload-in-dev-mode-meaning-youve-dynamically-pushed-changes-to-your-databaseif-youd-like-to-run-migrations-data-loss-will-occur-would-you-like-to-proceed-how-can-i-revert-this

Please do not connect to your Prod DB while in dev mode. This is core software dev 101 - you are playing with fire. If you care about the data in those dbs, then you should be making distinct environments for them.

hard field
#

⭐️ your repo. Thanks a lot.

brittle marsh
#

@plush oasis @dense coral thanks, that's exactly what I was looking for! 🙂

@hard field @fallow epoch thanks for your comments. I'm aware you shouldn't do it, but I'm at the start of a project and experimenting and shit happens 🙂 . I didn't want to drop my database just because of this.

hard field
#

@brittle marsh
Another approach is to not have individual data on dev. Loosing it is part of the flow.

I have apps that have proper seeding of minimal data; loosing data is part of the flow.
A pnpm run dev:seed gives any developer the same clean start. It is an extra step and extra time with your updated schema. But, it enables the "same" experience for all devs and since loosing data, is the plan, you can use pnpm run payload migrate:create on the same dev database and create migrations.

!!! Creating seeding data is a annoying step. But you get joy, when it's done. Keep it minimal, it should only be for critical data. In best cases, you have tests for the seeding data / use case that need it.
Keep it clean from load test data, client data, test data separately. This seeding is only for you.

... only go here, once you have the standard flow (our discussion) under control.

brittle marsh
#

Yes thanks. I'll try to improve my setup to get this flow.

But yeah, creating seeding data is indeed an annoying step. I already have some in place, but I need to relate words from my rich text field to glossary items, which makes the seeding even worse 😅