Skip to main content

Azure Static Web Apps - Failed to find a default file in the app artifacts folder. Valid default files: index.html,Index.html.

For a pet project I'm working on, I created a new Angular application using Angular 19. I used the same Github Actions setup I was using for my other projects. However, this time, the build failed with the following error message:

Failed to find a default file in the app artifacts folder (dist/treasurehunt). Valid default files: index.html,Index.html.

If your application contains purely static content, please verify that the variable 'app_location' in your workflow file points to the root of your application.

If your application requires build steps, please validate that a default file exists in the build output directory.


Here is the GitHub Actions file that was used:

Important to notice here are the following settings:

  • app_location: This is the location where the Azure Static Web App build task looks for the source code
  • output_location: This is the location where the Azure Static Web App looks for the final application. This should match with your configuration in the Angular.json file (check the outputPath setting):

As I mentioned in the intro, this is the default setup I've been using for a while and that always worked before. Until now...

What has changed?

The question now becomes: 'What has changed?' There should be something different that explains this issue…

After comparing different projects, I noticed that this was the first project that was using Angular 19 whereas previous applications were using Angular 17 or before.  Aha!

Turns out that starting from Angular 18, the Angular team has updated the Angular CLI design to always output publicly accessible files in browser directory and the ssr files in server directory and other files such as statistics and licenses information in the root output path.

This means that the final application code (including the missing index.html) file could be found in the dist\treasurehunt\browser folder instead of the dist\treasurehunt\ folder as before.

Fixing this issue was simple, I updated the output_location in the GitHub Actions file to take this change into account:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...