Automatic deployment of multiple repositories to Azure

The scenario is the following: a first repository contains the application code, and a second repository contains data files for the application contents. Azure, like some of the other best hosters, has the capability to automatically deploy new versions of your site when a new changeset is pushed onto a repository. When you have only one repository to deploy, the process is deliciously easy: when creating your web site, you can give it the URL of the repository on Github, and Azure will take care of everything, including of creating a web hook on Github so that new pushes can trigger the deployment scripts on Azure. If, like in the scenario above, your site is composed of multiple repositories, things are not that simple.

After googling it, stackoverflowing it, and getting pretty much convinced that nobody had succeeded in making it work, I contacted David Ebbo, who asked me to file a bug so it can be publicly discussed. David and Ahmed ElSayed were very helpful in sorting out what I was trying to do, and David found a perfect solution.

Let’s say your site is at, and you’ve already configured its root to be deployed from (not a real repo, I’m making that up of course). The directory for the second repository is the ‘content’ directory under the site’s root, cloned from (also not a real repo).

In order to set-up automatic deployments from the second repository, start by creating a new /site/wwwroot/App_Data/jobs/triggered/DeployContentRepo/run.cmd file (directly on Azure, don’t put that into your main repo) with the following contents:

cd /d %HOME%\site\wwwroot\content
git pull

Now all we have to do is manually configure a web hook on the second repository that will trigger our new custom deployment script. On Github, go to the first repository’s settings, then choose “webhooks and services” ( Click the “Edit” button next to your web hook, and copy the URL, which should look something like this:


Now go to the hook settings for the second repository, and create a new hook there. For the URL, modify the end of the URL you copied from the first repository, leaving the rest intact, to become:


Set the content type to be application/x-www-form-urlencoded. Save.

And that’s it, you’re done. Pushing a new changeset to the foocontent repository should now trigger a pull from Azure, and your site should get updated. You won’t see a trace in the Azure console, but you will see a new file appear under LogFiles/kudu/trace. Pushing to the first repository still works as it used to, of course.

No Comments