New Collection Types not showing after deployment

Hello, I am working with Strapi v4.19.0 and have this working fine on my localhost. I also have a deployed production version of the CMS on Azure (deployed as per webApp guide), this runs Strapi in ‘prod’ mode.

I have created a number of new Collection Types on the localhost version, added some plugins and made changes to the roles. All works fine locally. I then commit the changes to Github and let the build run.

However, when I deploy to Azure, the build and deploy completes, I can see the new schema and associated files being deployed correctly, for example:
Downloading: /api/article/content-types/article/schema.json

But when the web service starts, the new changes are not there. No new plugins, no new collection types or roles, but the files are there.
Am I missing a step to get this working? Thanks

This topic has been created from a Discord post (1217889745967910975) to give it more visibility.
It will be on Read-Only mode here.
Join the conversation on Discord

same issue

<@538025568495730698> you got any solution?

Hi, we did solve it in the end but I don´t think it was related to Strapi, from what I recall it was related to our Azure build pipeline not overwriting the files properly.

<@832212461893058600> Looking at the commits seems we made a change to the pipeline,
The new deploy was going into a folder $wwwrootinstead of ẁwwroot`.
Our script for deploy.sh (which runs on the azure service during deploy now looks like so:

#! /bin/bash
echo "Removing src, config and wwwroot folders"
rm -rf /home/site/wwwroot
rm -rf /home/site/wwwroot/src
rm -rf /home/site/wwwroot/config
rsync -arv --no-o --no-g --size-only  "./" "/home/site/wwwroot" --exclude ".git"
echo "Source sync done."
``

think we also have a problem with Windows line endings also

thanks for responding. I thought it had something to do with strapi since we aren’t using azure. We have hosted a docker instance which even on restart isn’t getting new collection types which were added locally.

Okay, ours was defo to do with the way it was being deployed, I just checked the commits. But perhaps you have something similar with the new files are landing in a temp folder in your docker container.