Usual process to change payload config / database schema in production

sssspraylast year

9

• 

  denolfe

  last year

  You will need to explicitly run your migrations against the database. ie.

  payload migrate

  before running serve. This is not done automatically.

• 

  sssspraylast year

  @967118574445547650

  Yes, I tried that, but what I get is "No migration to run". Is it because I miss I step when changing the payload config ? Do I have to explicitly start a migration before doing a change in the payload config ?

  
  
  

  This part is unclear. I read the documentation carefully, but it doesn't provide much help 😦

  
  
  

  So to recap, the workflow I tried after

  @967118574445547650

  's hint is the following:

  
  

  1. Make changes to my Payload CMS configuration (e.g., add a field in a collection in

  payload.config.ts

  ).

  
  

  2. Commit and push these changes to my backend repository / Pull the changes on my live server.

  
  

  3. Run

  npm run build

  on my server.

  
  

  4. Run

  npm run payload migrate

  on my server to apply the changes to my database schema.

  -> But I get a "No migration to run" message
  

  5. Finally, run

  npm run serve

  on my server

  
  
  

  Is there something missing in this general workflow ? I even tried to empty the db to see if build/migrate would create the schema, but it didnt.

  
  
  

  I'm obviously missing something... At what point in the process is the schema supposed to be built in the db ?
• 

  denolfe

  last year

  You are missing one part between 1 and 2. You need to run

  payload migrate:create

  to write the migration to a file.

  
  
  

  Check that file in. This will then be detected when you run migrate.

• 

  sssspraylast year

  @967118574445547650

  Great, thanks !

• 

  skaddicted4 months ago

  Hey

  @466682933327953920

  would you mind to share your completed setup?

  
  
  

  Because I am having a hard time understanding it.

  
  
  

  So our setup for the dev environment is the following:

  
  
  

  - I create the migrations locally before pushing with payload:migrate

  
  

  - I push everthing to Gitlab

  
  

  - I have the Dockerfile with the migrations

  
  
  # Install pnpm globally for Payload operations RUN npm install -g pnpm --unsafe-perm # Run database migrations RUN pnpm payload migrate:status || echo "No pending migrations found." RUN pnpm payload migrate || echo "No migrations to apply." # Build the application RUN \ if [ -f yarn.lock ]; then yarn run build; \ elif [ -f package-lock.json ]; then npm run build; \ elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build; \ else echo "Lockfile not found." && exit 1; \ fi
  
  

  - The build should be deployed with Azure App Service

  
  
  

  Maybe I am overthinking this but would you mind helping me there?

• 

  old_monkey212 months ago

  Thank you for the discussion, that is exactly what I was looking for, but I have a question, do I need to run the migration every time I'm building the app? I believe that it is the best approach to run it before the build as the documentation says but I'm getting the error, when I try to run the migration:create a second time:

  
  "type \"enum_users_role\" already exists"
  
  

  Do I need to run something else instead? Maybe a migrate:update?

• 

  skaddicted2 months ago

  Before pushing to your Prod/Dev environment you have to run the migrations locally with migrate:create. Then in your Docker File you only have to run the migrations via migrate (no create).

• 

  old_monkey212 months ago

  Got it, so it makes sense to add the migration commands in the build process (only migrate) and run the migrate:create when necessary, thank you!

  
  
  @240925952551550976

  For the migration, is it necessary to save all files to the migration folder? If I add the files from /migrations/* to git ignore, will it not work correctly trying to migrate something already migrated?

• 

  skaddicted2 months ago

  You run migrate:create locally and migrate in the build process, yes.

  
  
  

  Yes. You dont put the migrations folder in the .git-ignore