Postmortem: deploying my static website with Azure Static Web Apps (eventually)

Posted on By Mark Wilson

This all started out as a bit of vibe coding* in ChatGPT…

Yesterday, whilst walking the dog, I was listening to the latest episode of WB-40. Something Julia Bellis said gave me an idea for a simple custom GPT to help people (well, mostly me) eat better. ChatGPT helped me to create a custom GPT – which we named The Real Food Coach.

With the GPT created, I asked ChatGPT for something else: help me build a one-page website to link to it. In minutes I had something presentable: HTML, styling, fonts, icons – all generated in a few minutes. Pretty slick.

When it came to hosting, ChatGPT suggested something I hadn’t used previously: Azure Static Web Apps, rather than the Azure Storage Account route I’d used for hosting in the past. It sounded modern and neat – automatic GitHub integration, free SSL, global CDN. So I followed its advice.

ChatGPT was great. Until it wasn’t.

A quick win turns into a slow burn

The proof of concept came together quickly – code committed to GitHub, site created in Azure, workflow generated. All looked good. But the deploys failed. Then failed again. And again.

What should have taken 10 minutes quickly spiralled into a full evening of troubleshooting.

The critical confusion

The issue came down to two settings that look similar – but aren’t:

  • Deployment source – where your code lives (e.g. GitHub)
  • Deployment authorisation policy – how Azure authenticates deployments (either via GitHub OIDC or a manually managed deployment token)

ChatGPT had told me to use GitHub for both. That was the mistake.

Using GitHub as the authorisation method relies on Azure injecting a secret (AZURE_STATIC_WEB_APPS_API_TOKEN) into GitHub, but that never happened. I tried regenerating it, reauthorising GitHub, even manually wiring in deployment tokens – all of which conflicted with the setup Azure had created.

The result? Deploys that failed with:

“No matching Static Web App was found or the API key was invalid”

Eventually, after several rounds of broken builds, missing secrets, and deleting and recreating the app, I questioned the advice ChatGPT had originally given. Sure enough, it confirmed that yes – the authorisation policy should have been set to Deployment Token, not GitHub.

Thanks, ChatGPT. Bit late.

The right setup

Once I created the app with GitHub as the deployment source and Deployment Token as the authorisation policy, everything clicked.

I copied the token from Azure, added it to GitHub secrets, updated the workflow to remove unnecessary build steps, and redeployed.

Success.

Custom domain and tidy-up

Pointing my subdomain to the Static Web App was easy enough. I added the TXT record for domain verification, removed it once verified, and then added the CNAME. SSL was provisioned automatically by Azure.

I now have a clean, simple landing page pointing to my custom GPT – fast to load, easy to maintain, and served via CDN with HTTPS.

Lessons learned

  • ChatGPT can take you far, fast – but it can also give you confidently wrong advice. Check the docs, and question your co-pilot.
  • Azure Static Web Apps is fantastic for a simple website – I’m even using the free tier for this.
  • Authorisation and deployment are not the same thing. Get them wrong, and everything breaks – even if the rest looks correct.
  • Start again sooner – sometimes it’s faster to delete and recreate than to debug a half-working config.
  • DNS setup was smooth, but your DNS provider might need you to delete the TXT record after verification before you can create a CNAME).

Where is this website?

You can check out The Real Food Coach at realfood.markwilson.co.uk – and chat with the GPT at chat.openai.com/g/g-682dea4039b08191ad13050d0df8882f-the-real-food-coach.

*Joe Tomkinson told me that’s what it is. I’d heard of vibe coding but I thought it was something real developers do. Turns out it’s more likely to be numpties like me…

Getting started with Azure Sphere: Part 1 (setup and running a sample app)

Posted on By Mark Wilson
This content is 5 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Late in 2019, I got my hands on an Azure Sphere Starter Kit, which I’ve been intending to use for an IoT project, using some of the on-board sensors for temperature and potentially an external one for humidity…

For those who aren’t familiar with Azure Sphere, it’s Microsoft’s Secure Internet of Things (IoT) solution using certified chips, a custom operating system and a security service. My device is an Avnet Azure Sphere MT3620 Starter Kit and this blog post focuses on getting it up and running with one of the sample applications that Microsoft provides, using Windows 10 (other options include Linux).

Installing Visual Studio Code and the Azure Sphere SDK

Having obtained the kit, the next stop was Microsoft’s Getting Started with Azure Sphere page. I downloaded and installed Visual Studio Code (I don’t really need the whole Visual Studio 2019 application – though I later found that a lot of the advice on the Internet assumes that’s what you’re using…) and then immediately found that there are two versions of the Azure Sphere Software Development Kit (SDK). According to the Microsoft docs, either can be used with Visual Studio Code but I found the setup for the Azure Sphere SDK for Visual Studio failed when it can’t find Visual Studio (not really surprising) and so I used the Azure Sphere SDK for Windows.

Connecting the hardware

I plugged in the Avnet Azure Sphere Starter Kit, using the supplied USB cable, and watched as Windows installed drivers after which a virtual network interface was present and three COM ports appeared in Device Manager.

Setting up my dev environment

Installing Visual Studio Code and the Azure Sphere SDK was only the first part of getting ready to create code for the device. I needed to install the Azure Sphere extension (easily found in the Extensions Marketplace):

The Azure Sphere extension also installs two dependencies:

  • C/C++
  • CMake Tools

I also need to install CMake (in my case it was version 3.17.1). Not really knowing what I was doing, I followed the defaults but on reflection, I probably should have let CMake add its directory to the system %PATH% variable (I later uninstalled and reinstalled CMake to do this, but could just have added C:\Program Files\CMake\bin to the Path in the user environment variables).

The final installation was Ninja. Windows Defender SmartScreen blocked this app, but I was later able to work around that, by unblocking in the properties for ninja.exe:

I missed the point in the Microsoft documentation that said I needed to manually add Ninja to the %PATH% environment variable but I later went back and added the folder that I copied ninja.exe to (which, for me, was C:\Users\%username%\Tools).

(The above steps were my second attempt – the first time I installed MinGW-W64 to work around issues when Visual Studio Code couldn’t find a compiler, together with several changes in settings.json. I later removed all of that and managed to compile and deploy a sample application using just the settings above…)

Configuring the Azure Sphere device for use

There are a few steps required to configure the device for use. These are all completed using the Azure Sphere Developer Command Prompt, which was installed earlier, with the SDK.

Creating an Azure Sphere tenant and claiming the device

Each Azure Sphere device must be “claimed” and associated with a “tenant”. I followed the Microsoft documentation to do this…

azsphere login --newuser user@domain.tld

After completing Multi-Factor Authentication (MFA) and confirming I wanted to allow Azure Sphere to use my account, I was logged in but with a warning that I don’t have access to any Azure Sphere tenants, so I created one:

azsphere tenant create --name "Mark Wilson"

Warning – more research required: I used a Microsoft Account, as per the Microsoft instructions, but am now concerned I should have used an Azure Active Directory (Organisational/Work or School) account (especially as Role Based Access Control is supported from Azure Sphere 19.10 onwards). As a device can only be claimed once and, once claimed, the device is permanently associated with the Azure Sphere tenant, I’m stuck with these settings now…

I then went ahead and claimed the device:

azsphere device claim

Connecting to Wi-Fi and updating the device operating system

I checked the current OS version on the device:

azsphere device show-deployment-status

As can be seen, not only is the OS out of date, but the device is not connected to a network, so I connected to Wi-Fi:

azsphere device wifi show-status
azsphere device wifi add --ssid "SSID" --psk password
azsphere device wifi show-status

Now, with network connectivity in place, the device had a fighting chance of an OS update and according to the Microsoft documentation:

The Azure Sphere device checks for Azure Sphere OS and application updates each time it boots, when it initially connects to the internet, and at 24-hour intervals thereafter. If updates are available, download and installation could take as much as 15-20 minutes and might cause the device to restart.

Configure networking and update the device OS

I tried several restarts using azsphere device restart with no success. In the end, I left the device connected overnight and, by the morning, it had updated to 20.03.

Finally, I enabled application development on the device, ready to download some code and deploy an application:

azure sphere device enable-development

Downloading a sample app

My initial attempts to use the app that I wanted to didn’t work so I decided to test my setup with one of the Microsoft Quick Starts.

I needed to use git to clone the Azure Sphere Samples Repo, so that meant installing git. Then, from the Terminal in Visual Studio Code, I ran git clone https://github.com/Azure/azure-sphere-samples.git.

I then opened the Samples\HelloWorld\HelloWorld_HighLevelApp folder in Visual Studio Code, ready to build and deploy the app.

Building and deploying the app

Having set up my dev environment, set up the device and downloaded some sample code, I followed the instructions in the Visual Studio Code Azure Sphere Extension to run the following in the Command Palette: Azure Sphere: Configure Settings (selecting High-Level Application) and CMake: Build.

I was then able to build and deploy the sample app to my Azure Sphere device, by starting a debug session (F5) .

and was rewarded with a blinking LED on the board!

Azure Sphere Starter Kit with blinking LED

I can also view the application status with azsphere device app show-status.

Next steps

The next step is to get the app I really wanted to use working on the device, making use of some of the on-board sensors and then integrating this with some of the Azure services. I’m having trouble compiling that code at the moment, so that blog post may be a while longer…

Further reading

Posh-git!

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been writing quite a lot of PowerShell recently and I decided that I really should look into using some kind of source control system.  I’ve used Git before, integrating GitHub with VisualStudio and this time I wanted to integrate with the PowerShell ISE (by the way, if you don’t have a Windows 8.1 shortcut for the PowerShell ISE, Carlo/Happy SysAdmin describes how to find it).

It’s actually pretty straightforward using Keith Dahlby’s posh-git scripts (what a great name that is!) and GitHub Desktop. Jeff Yates has a post that describes the process but I found I needed to do a bit more to make it work for me…

My PowerShell ISE didn’t have a profile, so I created one and added the entries Jeff suggests but, even so, I was getting errors in my console:

Resolve-Path : Cannot find path ‘C:\Users\username\AppData\Local\GitHub\PoshGit_869d4c5159797755bc04749db47b166136e59132’ because it does not exist.
At C:\Users\username\AppData\Local\GitHub\shell.ps1:26 char:26
+ $env:github_posh_git = Resolve-Path “$env:LocalAppData\GitHub\PoshGit_869d4c51 …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\Users\username\…47b166136e59132:String) [Resolve-Path], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.ResolvePathCommand

Resolve-Path : Cannot find path ‘C:\profile.example.ps1’ because it does not exist.
At C:\users\username\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1:3 char:4
+ . (Resolve-Path “$env:github_posh_git\profile.example.ps1”)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\profile.example.ps1:String) [Resolve-Path], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.ResolvePathCommand

The expression after ‘.’ in a pipeline element produced an object that was not valid. It must result in a command name, a script block, or a CommandInfo object.
At C:\users\username\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1:3 char:3
+ . (Resolve-Path “$env:github_posh_git\profile.example.ps1”)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : BadExpression

After some hunting around, and an attempt to install posh-git manually, I realised that the shell.ps1 script from Github Desktop was looking for posh-git in a folder at $env:LocalAppData\GitHub called PoshGit_869d4c5159797755bc04749db47b166136e59132 (I’m guessing that’s a GUID in the foldername, so it’s likely to be different for others). After copying a clone of posh-git to that folder and reloading my profile (. $profile), everything was working as it should to commit changes from within PowerShell.

Publishing to GitHub from Visual Studio

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Those who follow me on Twitter (@markwilsonit) may be aware that I’m attempting to learn some C# skills in my spare time (what little of that I have).  It’s not my first foray into coding – I have a Computer Studies degree and, in my youth I wrote code in a variety of languages (BASIC, C, Turbo Pascal, Modula-2, 68000 assembler, COBOL, Visual Basic, C++ and probably some others too) but aside from a little bit of C++ on the Arduino and the odd bit of PowerShell, I haven’t done much in the last 20 years.  As my career moves further towards management I’m increasingly convinced it’s technology I enjoy though – and I’m seriously considering a move from infrastructure to software…

Anyway…

I’ve been following a Pluralsight C# course from Scott Allen (@ode2code) and, part way through, Scott uses System.Speech to demonstrate adding references to assemblies.  I had a play, adapting something I’d written earlier to talk to me as well as output to the console – nothing grand – just a bit of fun.  After showing it to my sons, the eldest (who is 9), described it as “epic” (which I understand is pretty good) and I tweeted, only to be amused by a reply which suggested the same library had caused hilarity in Duncan Smart (@DuncanSmart)’s household:

Small world, eh!

I followed the link to Duncan’s code and thought “Hmm… GitHub… I use that for my Arduino code… I wonder if…” – and yes, Visual Studio can publish to GitHub too.  It took some work to suss it out though, so here’s what I did (following advice on StackOverflow)…

  1. In Visual Studio, select File then Add to Source Control (which creates a local Git repository)
  2. On GitHub, create a new reposotory (but don’t initialise it with a README – Visual Studio wants an empty repository.
  3. Copy the HTTPS URI for the new repo, then go back to Visual Studio, open Team Explorer, select Home then Unsynced Commits and enter the GitHub URL before clicking Publish.
  4. You may find that you have to commit the changes locally first, which in my case required creating a local username and supplying an email address.
  5. After committing, the solution should be visible on GitHub.

For reference, I was using Visual Studio Express 2013 for Windows Desktop.