Dubious Ownership With Static Web Apps

Just when you thought you were safe from the warning, it returns in a new form. You read about how to avoid the dubious ownership warning, but suddenly I was seeing it appear while building your Azure Static Web Apps (ASWA). Hugo has an ability to pull certain details from Git, meaning it interacts with the Git command line. Unfortunately, I suddenly started seeing that going sideways in my Actions workflow:

1start building sites … 
2hugo v0.111.3-5d4eb5154e1fed125ca8e9b5a0315c4180dab192+extended linux/amd64 BuildDate=2023-03-12T11:40:50Z VendorInfo=gohugoio
3ERROR 2023/05/08 00:00:29 Failed to read Git log: fatal: detected dubious ownership in repository at '/github/workspace'
4To add an exception for this directory, call:
5	git config --global --add safe.directory /github/workspace
6Error: Error building site: logged 1 error(s)

And there it was in my logs: detected dubious ownership. I had to fix it.

It’s briefly mentioned in the FAQ that ASWA relies on Oryx. Microsoft Oryx is a build system that compiles source code for Azure App Services and Azure Static Web Apps. It has logic to automate that process, but that automation can be customized by a handful of environment variables. And it’s open source.

By comparison, the ASWA Action is implemented as a Docker container, with the source code hidden behind a private Microsoft repository. That means there are three layers: the Actions workflow (where runners are on VMs), the ASWA Action (which runs in a container), and the Oryx runtime. That is actually part of the problem – the source code is getting mapped into the Action’s container. When it does, it gets associated with a different user, triggering the warning. That also means that the normal call to git config won’t work. It isn’t the runner that is reporting the problem. It’s the container, which is referencing the source code using a bind-mount. That means it can only be fixed from within the container.

Just because it’s in a container doesn’t mean we’re completely out of luck. We could always crack open the image to examine what the code is doing. Thankfully, we don’t have to go to that extreme. While not explicitly documented, the Action happens to support the Oryx environment variables. I can just add a single line to the Azure/static-web-apps-deploy Action:

1env:
2  PRE_BUILD_COMMAND: git config --global --add safe.directory /github/workspace

The environment variable PRE_BUILD_COMMAND instructs Oryx to run a command before it starts trying to build a web application. This lets me configure the mounted folder – /github/workspace – as a safe directory from within the container. Problem solved. The container will now run my pre-build step inside the container as part of the build process.

Alternatively, I could also use the Actions parameters skip_app_build (to prevent Hugo from building in the container) and app_location (to specify the built content). I would then manually build the Hugo site, putting the output into the folder I specify in app_location. Bypassing the need to run a build process in the container avoids the interaction between Hugo and Git. It just deploys the application code as-is.