ADO Pipeline built WebApp not reflecting changes made

Question

ADO Pipeline built WebApp not reflecting changes made

Nicholas Ferguson 20

First, I just need to say that I'm new to deploying in Azure. I imagine I'm making a simple mistake, but for the life of me, I can't figure out what it is.

The Setup--

I'm deploying an app via the App Service. I previously had it set up so that when I committed something to my main branch, it would automatically build my express + react app and it'd be up and running. However, I found over the many publications, Azure would sometimes just fail for no reason. My assumption is some sort of internal timeout. The only thing in the deployment logs would be a broken up line about a broken pipeline. Because of this, I found some articles that mentioned that for bigger apps, it's better to build in an ADO pipeline and deploy the resulting files directly. I've since built my pipeline and it mostly works. The app launches, but many of the requests for the react app chunks were failing. I modified the code to make sure that my express server was correctly serving things, but nothing was changing. I then decided to test and change the chunk names to use hashes (instead of number indicators). After pushing this update, I can still see the requests failing for the old filenames. I added some pipeline debugging and can confirm that the zip file I'm uploading has the correct content. I can also confirm that the WEBSITE_RUN_FROM_PACKAGE variable is set.

I'm at a loss for what might be causing this or where to look. It seems that when WEBSITE_RUN_FROM_PACKAGE is set to 1, /site/wwwroot folder isn't updated, so I can't really rely on that to confirm.

I'm not sure what logging might be helpful here. Happy to edit this with updated information if anyone has any advice on what might clue me/us in on what's happening.

Siva Nair 835 Reputation points Microsoft External Staff Moderator

2025-08-13T19:49:17.5+00:00
Hi Nicholas Ferguson,

Since you're using WEBSITE_RUN_FROM_PACKAGE, your files might not be updating as you expect. Consider clearing the cache in your web app to ensure that no old files are being served. You may also want to try refreshing the browser cache or even using an incognito window to rule out caching issues.

You mentioned that the zip file has the correct content. You can use the Kudu console (accessible via https://<your-app-name>.scm.azurewebsites.net) to navigate to the site/wwwroot directory and confirm that the filenames and content reflect what you expect.

Sometimes, builds can inadvertently create nested folder structures. Double-check that your deployment isn't creating a wwwroot folder inside another wwwroot. This can mess up paths and lead to issues like the one you're facing.

You can enable detailed logging on your Azure App Service to help diagnose what might be going wrong during the deployment process. Use Application Insights or enable diagnostic logging on the Azure portal to gather more insights.

If you're making configuration changes or edits, restarting your web app can often help in applying the updates correctly.

Ensure that your ADO pipeline's build and deploy steps are correctly configured to reflect your latest changes. Look for any misconfigurations that might be causing deployments to pick up old code.

OR download your live ZIP from Azure so you can confirm it’s actually updated. That would prove whether this is a cache problem or a deploy problem.

Open your browser and go to:

https://<yourapp>.scm.azurewebsites.net/api/vfs/site/wwwroot/

This lets you see the live mounted files.

Or, to download the full ZIP from Azure Kudu, open:

https://<yourapp>.scm.azurewebsites.net/api/zip/site/wwwroot/

It will download the currently deployed package as a ZIP.

Extract it locally and compare with your pipeline build output — the chunk names and index.html should match.

If the files match, then it’s definitely caching (browser/CDN). If they don’t, the issue is with your Azure DevOps deploy step.
Nicholas Ferguson 20 Reputation points

2025-08-13T21:57:40.94+00:00
Hi @Siva Nair ! Thanks for replying! So, I've actually already tried several things listed. Let me break it down line by line:

I have tried clearing my browser cache and reloading the page, to the same effect. I'm not sure exactly how to clear "the cache in your web app", but I did set the following environment variables to effect that.

WEBSITE_DYNAMIC_CACHE=0
WEBSITE_LOCAL_CACHE_OPTION=Never

In an attempt to insure Azure wasn't pulling from old files, I also wrote logic in to the pipeline that DELETES wwwroot subfolders prior to deploying. This has no effect.

I have indeed done so and the files that I expect to be there are indeed there. The compiled js file that calls the chunks has the correct file names as well.

Folder structure is confirmed.

Beyond watching the log stream, I'm not sure what other tools are going to impart additional knowledge. Do you have any specifics you would recommend?

In an effort to troubleshoot this, I also set up my pipeline to stop the app, deploy, then re-start the app. This has had no impact.

I can confirm this as I added a step in the pipeline that unzips the folder to inspect some files and spit them out in the log for review.

I also decided to test something and manually delete the files in wwwroot. Even with nothing in there, it still loads the app. There must be another caching mechanism that I am unaware of.
Nicholas Ferguson 20 Reputation points

2025-08-14T19:15:11.38+00:00

The Front Door caching was the culprit. I turned it off yesterday (not remembering that it was there before) but it changed nothing. I didn't realize I needed to purge the cache. I logged in this morning and it's all working. Thank you!

EDIT: If you convert your comment to the answer, I'll confirm it!

Answer accepted by question author

0 additional answers

Your answer

Nicholas Ferguson 20 Reputation points

2025-08-13T21:57:40.94+00:00

Hi @Siva Nair ! Thanks for replying! So, I've actually already tried several things listed. Let me break it down line by line:

I have tried clearing my browser cache and reloading the page, to the same effect. I'm not sure exactly how to clear "the cache in your web app", but I did set the following environment variables to effect that.

WEBSITE_DYNAMIC_CACHE=0
WEBSITE_LOCAL_CACHE_OPTION=Never

In an attempt to insure Azure wasn't pulling from old files, I also wrote logic in to the pipeline that DELETES wwwroot subfolders prior to deploying. This has no effect.

I have indeed done so and the files that I expect to be there are indeed there. The compiled js file that calls the chunks has the correct file names as well.

Folder structure is confirmed.

Beyond watching the log stream, I'm not sure what other tools are going to impart additional knowledge. Do you have any specifics you would recommend?

In an effort to troubleshoot this, I also set up my pipeline to stop the app, deploy, then re-start the app. This has had no impact.

I can confirm this as I added a step in the pipeline that unzips the folder to inspect some files and spit them out in the log for review.

I also decided to test something and manually delete the files in wwwroot. Even with nothing in there, it still loads the app. There must be another caching mechanism that I am unaware of.
Nicholas Ferguson 20 Reputation points

2025-08-14T19:15:11.38+00:00

The Front Door caching was the culprit. I turned it off yesterday (not remembering that it was there before) but it changed nothing. I didn't realize I needed to purge the cache. I logged in this morning and it's all working. Thank you!

EDIT: If you convert your comment to the answer, I'll confirm it!

Answer 1

Hi Nicholas Ferguson

That means your app isn’t actually being served from /site/wwwroot at all — which is exactly what happens when WEBSITE_RUN_FROM_PACKAGE is set.

Where your stale chunks could still come from

Given you’ve confirmed the correct build is in the package:

Front Door / Azure CDN
- These will happily serve an old index.html or JS chunks even if Azure App Service has the new ones.
- Purge it after deploy.
App Service static file caching
- Even with WEBSITE_DYNAMIC_CACHE=0, App Service can still serve cached static files from its own layer or from an Application Gateway in front.
Service Worker (React PWA)
- If your app was created with CRA and service workers were once enabled, an old worker can serve stale chunks from the user’s local cache regardless of Azure settings.

Next steps to actually clear it

Purge any upstream CDN cache

If you have Azure Front Door/CDN:

     az afd endpoint purge \
       --resource-group <RG> \
       --profile-name <FDProfile> \
       --endpoint-name <Endpoint> \
       --content-paths "/*"

Force index.html to always refresh

In Express:

     if (path.endsWith('index.html')) {
       res.setHeader('Cache-Control', 'no-store');
     }

Kill any service worker

Temporarily add this to your React index.js:

     if ('serviceWorker' in navigator) {
       navigator.serviceWorker.getRegistrations().then(regs => {
         regs.forEach(reg => reg.unregister());
       });
     }

Optional: Turn off RUN_FROM_PACKAGE If you want full manual control over /site/wwwroot during troubleshooting:

     Remove `WEBSITE_RUN_FROM_PACKAGE`

           Redeploy normally

                 Now you can truly delete & confirm files in Kudu.

Your files are updating — they’re just being served from the mounted ZIP, and an upstream cache or service worker is handing out old chunks. The only way to fully prove this is to download the live package and purge all layers of caching above it.

some reference-

app-service/reference-app-settings

how-to-cache-purge

how-to-cache-purge-cli

how-to-cache-purge-powershell

serving-static-assets-with-an-efficient-cache-poli

Siva Nair 835 Reputation points Microsoft External Staff Moderator

2025-08-15T03:50:20.06+00:00

Hi Nicholas Ferguson

Glad that you got your issue resolved, thanks for sharing, please click accept answer for those who has similar issue will get help with this.

Thanks!

Share via

ADO Pipeline built WebApp not reflecting changes made

0 additional answers

Your answer