Hugo on Azure Readiness starts here...

How I used GitHub Copilot to migrate my Hugo website to GitHub Pages

Sat, 13 Jun 2026 00:00:00 +0000

If you’ve followed this blog for a while, you know it runs on Hugo, a fantastic static site generator that turns a folder of Markdown files into a fast, fully static website. For the past couple of years that site has been hosted on Azure Static Web Apps, with an Azure DevOps pipeline doing the heavy lifting of compiling Hugo and publishing the output.

That setup served me well. After migration my old site templates and structure to a new one last February (see:https://www.pdtit.be/post/how-i-used-github-copilot-to-modernize-my-8-year-old-hugo-website/), I now wanted to consolidate everything into a single ecosystem and move the site to GitHub Pages, built and deployed by GitHub Actions. And because I wanted to see how far the tooling has come, I did the entire migration side-by-side with GitHub Copilot in agent mode inside VS Code.

Apart from moving the site, I also made the decision to decommission the 007FFFLearning.com brand, and go back to the “good-old” pdtit.be" one I had since the early days of the internet in 1996 already.

This post walks through why I made the move, what my old setup looked like, the plan I followed, and how the migration actually went, including the DNS part that always makes people nervous. I’m deliberately keeping it conceptual rather than copy-paste exact, so you can map it to your own site.

Here’s the prompt I used:

1
2
3


/plan a migration from this repo from azure static webapps with Hugo to a GitHub Pages environment. The goal is to migrate away from Azure hosting, Azure DevOps pipeline for the blog post updates and run everything in GitHub. The new domain name should be www.pdtit.be instead of www.007FFFLearning.com, as a redirection from pdtit.github.io default Pages name. Prepare a migration plan, identify the successes, potential risks and evaluation criteria to move the site.

If a migration is technically possible without losing functionality, highlight the actual steps to migrate, knowing we want a smooth migration with minimal downtime

// change draft: true to false

1. Why GitHub Pages for a static site?

A Hugo blog is, by definition, just a pile of static HTML, CSS, JavaScript and images once it’s built. You don’t need servers, containers, or databases to host it, you only need somewhere that can serve files over HTTPS. That’s exactly what GitHub Pages does, for free, directly from a repository.

A few reasons it’s a great fit:

One place for everything. Your content, your build pipeline, and your hosting all live in the same GitHub repo. No jumping between portals.
Build on push. With GitHub Actions, every push to your main branch rebuilds the site and publishes it automatically. Write a post, commit, done.
Free TLS and custom domains. GitHub Pages provisions a certificate for your own domain at no cost and can enforce HTTPS.
No build output in source control. The generated site is produced fresh in CI on every push, so you never have to commit the compiled HTML again.

For a personal blog, this removes a surprising amount of moving parts.

2. Where I was coming from (the old setup)

Before the migration, the moving pieces looked like this:

Hugo as the site generator, with content written in Markdown.
Azure Static Web Apps as the host, serving the compiled site and handling TLS for my custom domain.
An Azure DevOps pipeline that triggered on every commit, installed the right Hugo version, built the site, ran a couple of validation checks (more on that later), and deployed it.
The compiled output and even a copy of the Hugo binary were committed into the repository, a habit from earlier days that I wanted to leave behind.

Nothing here was broken. But it meant my publishing flow spanned two platforms (Azure DevOps for builds, Azure for hosting), and the repo carried a lot of generated weight it didn’t need.

3. The migration plan

Rather than diving straight into edits, I asked Copilot Plan mode to help me draft a phased plan first. Having a clear plan up front is what keeps a migration like this calm instead of chaotic. At a high level it broke down into:

Phase 1 - Prepare the repository. Stop committing build output. Add a .gitignore for the generated site, the Hugo cache, and any local binaries. Pin the exact Hugo version so local builds and CI builds always match.

Phase 2 - Recreate the build in GitHub Actions. Replace the Azure DevOps pipeline with a GitHub Actions workflow that installs Hugo, builds the site, and deploys it to Pages. Importantly, I carried over the validation checks my old pipeline did, things like confirming the search index was generated and that newly added posts actually appear in the output, so I didn’t lose that safety net.

Phase 3 - Publish to GitHub. Create the GitHub repository, point the local repo at it, rename the default branch to main, and push. Then flip the repo’s Pages setting to build from GitHub Actions.

Phase 4 - Custom domain. Tell GitHub which domain to serve, update the site’s base URL, configure DNS, and enforce HTTPS once the certificate is issued.

Phase 5 - Redirect the old domain. Keep the previous domain alive for a while and forward it to the new one so existing links and search engine results don’t break.

Phase 6 - Decommission the old platform. Once the new site is confirmed healthy, retire the Azure DevOps pipeline and the Azure Static Web App.

Writing the plan down also surfaced the risks early, the trickiest being deep links from the old domain and making sure the search feature kept working. Knowing those in advance meant I could check for them deliberately instead of discovering them after go-live.

4. How the migration actually went

With the plan agreed, the execution was honestly the easy part, this is where working alongside Copilot in agent mode really paid off. Instead of me hand-editing dozens of files, I described the outcome I wanted and reviewed the changes it proposed.

A few highlights of the actual approach:

Cleaning up the repo. The first win was getting the compiled site and the committed Hugo binaries out of version control. Going forward, the build output is regenerated by CI on every push, so the repository only contains what it should: content and configuration.

A single build-and-deploy workflow. The GitHub Actions workflow became the new “engine” of the site, the direct replacement for the old pipeline. On every push to main it installs the pinned Hugo version, builds the site, runs the validation checks, and deploys the result to Pages. The very first run going green was the moment I knew the new platform was viable.

Check out the actual GitHub Actions YAML if you want:

https://github.com/pdtit/pdtit.github.io/actions/runs/27473418917/workflow

Fixing up internal links. Because the domain was changing, I had Copilot sweep the content for hard-coded absolute links pointing at the old address and make them relative instead. Relative links survive a domain change without any further edits, which is exactly what you want.

Validating before trusting. Before pushing anything live, I rebuilt the site locally from a clean slate and verified the important things: the homepage and posts pointed at the new address, the client-side search index was present and valid, and no stale references lingered in the output. Only then did I publish.

The DNS part (kept high-level on purpose). This is the step people worry about most, but the pattern is well-trodden:

The www subdomain gets a CNAME pointing at the GitHub Pages host.
The root (apex) domain gets a set of A records (and IPv6 AAAA records) pointing at GitHub’s Pages addresses. GitHub publishes the exact values, you just enter them at your registrar.
GitHub then automatically redirects the apex to your www canonical address.

One gotcha worth calling out: if your registrar had any leftover parking or forwarding records on the apex, remove them, otherwise the certificate can struggle to provision. Once DNS resolved cleanly, GitHub issued the TLS certificate within minutes, and I switched on Enforce HTTPS.

Don’t strand the old domain. Finally, the previous domain stays alive and forwards to the new one. The key detail is to use a path-preserving redirect, so an old deep link to a specific article lands on that same article on the new domain, not just the homepage. That protects your existing readers and your search rankings while everything propagates.

Wrapping up

The migration itself, prepare, rebuild in Actions, publish, wire up the domain, redirect the old one, was conceptually simple, but having GitHub Copilot do the repetitive editing, validation, and verification turned what could have been a tense weekend into a calm afternoon. The site you’re reading this on right now is the result: a Hugo blog, built by GitHub Actions, served from GitHub Pages, on my own domain.

If you’re sitting on a static site hosted somewhere heavier than it needs to be, this is a very approachable move, and a great little project to try out agent-mode tooling on a real, low-risk task.

// should always be the last section of the blog

Cheers!!

/Peter

How I used GitHub Copilot to modernize my 8 year old Hugo website

Sat, 28 Feb 2026 00:00:00 +0000

I recently decided to give my 8 year old Hugo website a serious refresh. The trigger was simple: I still used the first Hugo theme I picked up 8 years ago, some content menu options didn’t actually do anything or were no longer relevant. Then I also had screenshots and other image files all over the place (5 different folder locations, duplicate image file names and alike).

Instead of doing this modernization and cleanup manually over a few weekends, I used GitHub Copilot as an active engineering partner to accelerate the full modernization journey.

Where it started: search was broken in production

The first issue looked small, but it exposed deeper reliability problems:

The search JSON endpoint existed
The /search/ page in production was effectively empty
The pipeline still reported success

So this wasnâ€™t a single typo. It was a classic â€œgreen pipeline, broken runtime behaviorâ€ scenario.

With Copilot, I moved from guessing to structured troubleshooting:

Validate generated Hugo output
Compare source routing/content metadata with deployed artifacts
Harden the pipeline to fail fast when critical pages are missing

That immediately changed the workflow from reactive debugging to proactive validation.

Copilot helped me modernize beyond just the bug

Once search was fixed, I used the same momentum to clean up years of accumulated content and asset drift.

1) Build and deployment reliability

I updated the Azure Static Web Apps pipeline to be more explicit and defensive:

Build validation checks for critical output files
Safer prebuilt artifact deployment behavior
Better guardrails so partial site generation doesnâ€™t silently pass

Result: deployment confidence went up significantly.

1) Build and deployment reliability

I updated the Azure Static Web Apps pipeline to be more explicit and defensive:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57


trigger:
 - main

pool:
 vmImage: 'ubuntu-latest'

steps:
 - task: UseHugoExtended@1
 inputs:
 version: 'latest'
 
 - script: hugo --minify
 displayName: 'Build Hugo site'
 
 # ðŸ›¡ï¸ GUARDRAIL: Validate critical output files exist
 - script: |
 if [ ! -f "public/search/index.json" ]; then
 echo "ERROR: Search JSON endpoint missing!"
 exit 1
 fi
 if [ ! -f "public/index.html" ]; then
 echo "ERROR: Homepage not generated!"
 exit 1
 fi
 displayName: 'Validate critical pages exist'
 
 # ðŸ›¡ï¸ GUARDRAIL: Check for empty or malformed search index
 - script: |
 SIZE=$(wc -c < public/search/index.json)
 if [ $SIZE -lt 100 ]; then
 echo "ERROR: Search index is suspiciously small ($SIZE bytes)!"
 exit 1
 fi
 displayName: 'Validate search index integrity'
 
 # ðŸ›¡ï¸ GUARDRAIL: Verify content pages were generated
 - script: |
 COUNT=$(find public -name "index.html" -type f | wc -l)
 if [ $COUNT -lt 10 ]; then
 echo "WARNING: Only $COUNT pages generated (expected more)"
 exit 1
 fi
 displayName: 'Verify minimum content threshold'
 
 - task: PublishBuildArtifacts@1
 inputs:
 pathToPublish: 'public'
 artifactName: 'hugo-site'
 displayName: 'Publish build artifacts'
 
 - task: AzureStaticWebApp@0
 inputs:
 azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_TOKEN)
 repo_token: $(GITHUB_TOKEN)
 action: 'upload'
 app_location: 'public'
 displayName: 'Deploy to Azure Static Web Apps'

Key safety improvements:

âœ… Explicit validation that search index exists and has realistic content
âœ… Minimum page count check to catch silent generation failures
âœ… Pipeline fails fast instead of deploying broken output
âœ… Clear error messages for debugging

Result: deployment confidence went up significantly.

2) Content architecture cleanup

Over time, I had duplicate and legacy routes (especially around books and videos). Copilot helped audit what was truly used versus what was just historical baggage.

I then:

Redesigned the Books page into a cleaner 2-column layout (cover + title/description)
Removed duplicate publications pages where canonical pages already existed
Reviewed and cleaned aliases to keep routing intentional

Result: fewer moving parts and clearer content ownership.

3) Image and asset governance

This was the biggest hidden technical debt.

I had images spread across multiple legacy folders with overlapping filenames. That made reference checks noisy and risky. Copilot helped me run source-scoped audits, identify true usage, and avoid false positives from generated output.

I used that to:

Move post-related images into content/post/images
Rewrite Markdown links in affected posts
Handle filename collisions safely
Remove unused files/folders only after reference validation

Result: cleaner repository, fewer dead assets, and lower risk of accidental content breakage.

What I liked most about using Copilot on an older codebase

The biggest value wasnâ€™t â€œAI wrote code for me.â€ It was this:

Faster root-cause analysis
Safer bulk refactoring with validation checkpoints
Less context switching for repetitive search/update tasks
Better confidence to remove legacy clutter without fear

For old websites, this matters a lot. Most of the work is not feature development â€” itâ€™s careful archaeology.

Practical lessons if you want to modernize your own Hugo site

If your site is aging and you donâ€™t know where to start, this sequence worked very well for me:

Fix one visible production issue first (high leverage)
Add pipeline checks for critical pages/artifacts
Identify canonical routes and remove duplicates
Consolidate assets by usage domain (e.g., post images)
Delete only after source-level reference validation

Small, verified steps beat one giant risky migration every time.

Final thoughts

This modernization started as a broken search page after switching to a new Hugo theme and ended as a full site health upgrade and removal of technical debt.

GitHub Copilot didnâ€™t replace engineering judgment â€” it amplified it. For me, that was the real win: I could move faster and be more careful at the same time.

If you have an older Hugo site (or any long-running static site), this is absolutely worth doing.

By the way, this whole process took less than 2 hours, and about 20 prompts in a continuous conversational approach. Are you a fan of GitHub Copilot? Let me know what your coolest use case has been so far!

Cheers!!

/Peter

How I migrated my Hugo site from Azure Storage Site to Azure Static Web Apps

Sun, 30 Oct 2022 00:00:00 +0000

For about 3 years now, I’ve been running this personal blog site using Hugo, running on Azure Static Storage Sites and Azure Front Door as load balancer/TLS protection service.

About 18 months back, Microsoft released Azure Static Web Apps, a platform built for exactly that, hosting Static Web sites, such as Vue, React, Angular, Svelte, .NET Blazor, and also… Hugo :).

As I had to migrate my resources to a new Azure subscription and tenant, I thought this was a perfect moment to migrate to SWA. While the process was surprisingly smooth, I wanted to blog about it, to help and convince others who are in the same situation as myself, giving confidence how easy it actually is.

In short, the process involves the following:

have a backup (copy) of the Site files in Azure Storage Account. If you don’t have them in a GitHub or Azure DevOps repository already, look into the free Azure Storage Explorer tool to copy the data aside to your local machine.
Depending on your DevOps platform of choice (both GitHub and Azure DevOps are supported), you need to have a repository available already to be used for Azure Static Web Apps.
Deploy a new Azure Static Web Apps resource from the Azure Portal, as follows:

a) Create new Resource / Static Web Apps

b) Complete the necessary project details:

Subscription
Azure Resource Group
Unique name for the Static Site App
Hosting Plan - Free which gives all you need for running Hugo with a public SSL/TLS certificate and hostname

c) Next, provide the necessary deployment details. Notice SWA relies on a DevOps pipeline process, which can be GitHub or Azure DevOps. The pipeline basically gets triggered to compile the Hugo Markdown files (your blog article) into HTML-files, and gets triggered every time something is changed in the repository (like when you write a new blog post, delete a post or update a post…)

In my setup, I chose Azure DevOps, but the flow is the same in GitHub.

d) Confirm the creation of the resource, and give it a few minutes. Once created, navigate to the new Static Web App resource blade:

e) From here, notice the edit workflow section, which points to a CI/CD Pipeline Yml file. This is the actual “engine” doing all the work. Open this link.

this is what it looks like in my scenario:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


name: Azure Static Web Apps CI/CD

pr:
 branches:
 include:
 - main
trigger:
 branches:
 include:
 - main

jobs:
- job: build_and_deploy_job
 displayName: Build and Deploy Job
 condition: or(eq(variables['Build.Reason'], 'Manual'),or(eq(variables['Build.Reason'], 'PullRequest'),eq(variables['Build.Reason'], 'IndividualCI')))
 pool:
 vmImage: ubuntu-latest
 variables:
 - group: Azure-Static-Web-Apps-gentle-desert-046399d10-variable-group
 steps:
 - checkout: self
 submodules: true
 - task: AzureStaticWebApp@0
 inputs:
 azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_API_TOKEN_GENTLE_DESERT_046399D10)
###### Repository/Build Configurations - These values can be configured to match your app requirements. ######

Normally, you shouldn’t have to change anything on this Yml pipeline file, unless your Hugo theme tells you to make alterations. In short, whenever there is a change (“a trigger”) in the content (“include main”), it runs the job and relate task (“AzureStaticWebApp@0”). This is run on an Azure DevOps build agent, an Azure-running Ubuntu Virtual Machine, with all necessary software and tools needed to compile the website updates.

Wait for your pipeline to complete, and run successful.

When it’s the first time, it will most probably fail, since there is no data to compile yet. Let’s fix this!!

From the DevOps environment, go to Repos (Github or Azure DevOps), and clone this repo to your local machine. I’m using Visual Studio Code, as it’s a brilliant MarkDown editor with Git integration out-of-the-box.

Once the repo got cloned, copy all the folders and files from your backup, into this new repo folder. This will be recognized as a “folder change” by the Git source control process, and asking you to commit the changes and synchronize back to your repository. Perform both steps in sequence.

followed by the Sync Changes process - which uploads all changed files from your local machine to the DevOps repo.

From the DevOps environment, validate the Hugo folders and files are present in the repository.

Given the automatic trigger, the Pipeline will be picking up the change and executing a new run. Wait for this to complete successfully.

Connect to the Azure Web App resource URL (something like https://gentle-desert-123456789.2.azurestaticapps.net/) as in my case, and behold your blog website is live!!

While this completes the successful migration of the Hugo blog site, we are not 100% done yet. As for now, it is only listening on the internal SWA web address, which we should update to a public domain name like www.007FFFLearning.com

Luckily, this is a nifty feature from Static Web Apps, where it allows you to add a custom domain, together with a public SSL/TLS certificate for encryption - all included in the FREE plan! Sweetly done Microsoft!

From the Static Web Apps blade, navigate to custom domains.

Click ‘Add Domain’, and select the options that’s relevant to you. I have my public domain in GoDaddy, but other options, including Azure DNS itself, is also available.

Add the custom domain name, and copy the CName record details over into your actual DNS hosting solution management portal. Once this is done, head back over to this Azure Custom Domain blade and confirm the domain validation. Note - depending on the DNS provider of use, this might take up to several hours. Mostly, this will only be a few minutes though.

That’s it! from now on, your Static Web Site will listen to both the internal SWA domain, as well as the public domain you have configured here.

This is all it took to migrate my Hugo blog site from Azure Storage Account Static Site to the newer, Azure Static Web Apps. I’m now going to delete my old Resource Group, since I don’t need that Azure Storage Account nor the Azure Front Door anymore. saving me about $45 /month.

In the next post, I’ll describe how to add Azure Application Insights to it, to continue getting visitor statistics.

Holler me on Twitter if you should have any questions.

Cheers!!

/Peter

Integrating Azure App Insights for Hugo on Static Web Apps

Sun, 30 Oct 2022 00:00:00 +0000

Hey folks,

Earlier this week, I wrote about how I migrated my Hugo blog site from Azure Storage Account-based site to the newer Azure Static Web Apps with Hugo.

While this was a smooth process, both migrating the actual site content, as well as transferring the public domain name, the piece missing was the statistics. I always used Azure Application Insights for this, but specifically for Azure Static Web Apps, App Insights is only supported when using Functions (as per this article on the Microsoft docs). Which I don’t have with Hugo.

However, App Insights also supports a JavaScript-based approach, and this works fine with Hugo static website.

Let’s get this going…

The first step involves deploying an Azure Application Insights resource from the portal.

Enter the necessary details to get your App Insights resource deployed:

Subscription
Resource Group
App Insights Instance Name
Region
Resource-Mode Workspace-based
Log Analytics WorkSpace: accept the suggested one (or select an existing one if you already have one and want to consolidate the logging information)

After a few minutes, the resource got created successfully. Navigate to the blade

From the blade, notice the Instrumentation Key in the top right corner. Copy this key aside, as you need to add it into the Hugo config file.

With App Insights up-and-running, let’s head over to our Hugo site source files. Look for a file “config.toml” in the root of your Hugo folder structure. Open the file in an editor, and add the following snippet into the “[param]” section of the config file:

1

azureAppInsightsKey = "4ecca3df-ab58-4882-aaaa-123456789"

replacing the sample key with the Instrumentation Key of your Azure Application Insights resource you copied earlier.

Next, to make sure your App Insights statistics get captured for every visit of every page of the site, add a little snippet of code for appinsights to the top section of the baseof.html file, which should be in the \themes<theme>\layouts_default\ folder of the Hugo Theme you are using.

1
2
3
4
5
6
7
8


<!DOCTYPE html>
<html lang="{{ .Site.LanguageCode }}">
{{ partial "appinsights.html" . }} <========= add this line
{{ partial "head.html" . }}
{{ partial "nav.html" . }}
<!-- Page Header -->
{{ block "header" .}}
...

Next, create a new file called appinsights.html in the \themes<theme>\layouts\partials\ folder of the Hugo Theme you are using, having the following code in it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{{ if .Site.Params.azureAppInsightsKey }}
 <script type="text/javascript">
 !function(T,l,y){var S=T.location,u="script",k="instrumentationKey",D="ingestionendpoint",C="disableExceptionTracking",E="ai.device.",I="toLowerCase",b="crossOrigin",w="POST",e="appInsightsSDK",t=y.name||"appInsights";(y.name||T[e])&&(T[e]=t);var n=T[t]||function(d){var g=!1,f=!1,m={initialize:!0,queue:[],sv:"4",version:2,config:d};function v(e,t){var n={},a="Browser";return n[E+"id"]=a[I](),n[E+"type"]=a,n["ai.operation.name"]=S&&S.pathname||"_unknown_",n["ai.internal.sdkVersion"]="javascript:snippet_"+(m.sv||m.version),{time:function(){var e=new Date;function t(e){var t=""+e;return 1===t.length&&(t="0"+t),t}return e.getUTCFullYear()+"-"+t(1+e.getUTCMonth())+"-"+t(e.getUTCDate())+"T"+t(e.getUTCHours())+":"+t(e.getUTCMinutes())+":"+t(e.getUTCSeconds())+"."+((e.getUTCMilliseconds()/1e3).toFixed(3)+"").slice(2,5)+"Z"}(),iKey:e,name:"Microsoft.ApplicationInsights."+e.replace(/-/g,"")+"."+t,sampleRate:100,tags:n,data:{baseData:{ver:2}}}}var h=d.url||y.src;if(h){function a(e){var t,n,a,i,r,o,s,c,p,l,u;g=!0,m.queue=[],f||(f=!0,t=h,s=function(){var e={},t=d.connectionString;if(t)for(var n=t.split(";"),a=0;a<n.length;a++){var i=n[a].split("=");2===i.length&&(e[i[0][I]()]=i[1])}if(!e[D]){var r=e.endpointsuffix,o=r?e.location:null;e[D]="https://"+(o?o+".":"")+"dc."+(r||"services.visualstudio.com")}return e}(),c=s[k]||d[k]||"",p=s[D],l=p?p+"/v2/track":config.endpointUrl,(u=[]).push((n="SDK LOAD Failure: Failed to load Application Insights SDK script (See stack for details)",a=t,i=l,(o=(r=v(c,"Exception")).data).baseType="ExceptionData",o.baseData.exceptions=[{typeName:"SDKLoadFailed",message:n.replace(/\./g,"-"),hasFullStack:!1,stack:n+"\nSnippet failed to load ["+a+"] -- Telemetry is disabled\nHelp Link: https://go.microsoft.com/fwlink/?linkid=2128109\nHost: "+(S&&S.pathname||"_unknown_")+"\nEndpoint: "+i,parsedStack:[]}],r)),u.push(function(e,t,n,a){var i=v(c,"Message"),r=i.data;r.baseType="MessageData";var o=r.baseData;return o.message='AI (Internal): 99 message:"'+("SDK LOAD Failure: Failed to load Application Insights SDK script (See stack for details) ("+n+")").replace(/\"/g,"")+'"',o.properties={endpoint:a},i}(0,0,t,l)),function(e,t){if(JSON){var n=T.fetch;if(n&&!y.useXhr)n(t,{method:w,body:JSON.stringify(e),mode:"cors"});else if(XMLHttpRequest){var a=new XMLHttpRequest;a.open(w,t),a.setRequestHeader("Content-type","application/json"),a.send(JSON.stringify(e))}}}(u,l))}function i(e,t){f||setTimeout(function(){!t&&m.core||a()},500)}var e=function(){var n=l.createElement(u);n.src=h;var e=y[b];return!e&&""!==e||"undefined"==n[b]||(n[b]=e),n.onload=i,n.onerror=a,n.onreadystatechange=function(e,t){"loaded"!==n.readyState&&"complete"!==n.readyState||i(0,t)},n}();y.ld<0?l.getElementsByTagName("head")[0].appendChild(e):setTimeout(function(){l.getElementsByTagName(u)[0].parentNode.appendChild(e)},y.ld||0)}try{m.cookie=l.cookie}catch(p){}function t(e){for(;e.length;)!function(t){m[t]=function(){var e=arguments;g||m.queue.push(function(){m[t].apply(m,e)})}}(e.pop())}var n="track",r="TrackPage",o="TrackEvent";t([n+"Event",n+"PageView",n+"Exception",n+"Trace",n+"DependencyData",n+"Metric",n+"PageViewPerformance","start"+r,"stop"+r,"start"+o,"stop"+o,"addTelemetryInitializer","setAuthenticatedUserContext","clearAuthenticatedUserContext","flush"]),m.SeverityLevel={Verbose:0,Information:1,Warning:2,Error:3,Critical:4};var s=(d.extensionConfig||{}).ApplicationInsightsAnalytics||{};if(!0!==d[C]&&!0!==s[C]){method="onerror",t(["_"+method]);var c=T[method];T[method]=function(e,t,n,a,i){var r=c&&c(e,t,n,a,i);return!0!==r&&m["_"+method]({message:e,url:t,lineNumber:n,columnNumber:a,error:i}),r},d.autoExceptionInstrumented=!0}return m}(y.cfg);(T[t]=n).queue&&0===n.queue.length&&n.trackPageView({})}(window,document,{
 src: "https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js", // The SDK URL Source
 //name: "appInsights", // Global SDK Instance name defaults to "appInsights" when not supplied
 //ld: 0, // Defines the load delay (in ms) before attempting to load the sdk. -1 = block page load and add to head. (default) = 0ms load after timeout,
 //useXhr: 1, // Use XHR instead of fetch to report failures (if available),
 //crossOrigin: "anonymous", // When supplied this will add the provided value as the cross origin attribute on the script tag 
 cfg: { // Application Insights Configuration
 instrumentationKey: "{{- .Site.Params.azureAppInsightsKey -}}"
 /* ...Other Configuration Options... */
 }});
 </script>
 {{ end }}

Save the files and wait for the Static Web Apps pipeline to complete the update successfully.
Navigate to your blog website, and open a few different articles, shortlinks to other parts in the web site or navigate back-and-forth to the home page. This to generate some statistics information.
After only a few minutes, your App Insights data will get loaded, which can be retrieved from App Insights / Usage / section, using different views:

For example, select Users, which shows the number of unique visitors over the last 24 hours (note you can drill down to the last 30min, up to any custom period in time).

Click on the View More Insights button below the chart, which will expose even more granular information regarding the visits. For example the location, time frame, client, browser version, etc… all the way to the full sequence of blog articles visited.

In this article, I explained how to integrate Azure App Insights into a Hugo-based Azure Static Web Apps, using some JavaScript and HTML code.

If you are running Hugo on Azure SWA as well, let me know!

Cheers!!

/Peter

Running your Hugo site on Azure Static WebApps (Preview)

Thu, 21 May 2020 00:00:00 +0000

Only about a month ago, I decided to move my former website (running on Wix) to the Open Source Hugo platform, running it as a static website with MarkDown, using Azure Storage Static Website. For more details on how to do this, have a look at my blog post here

I have to say, it runs fine, is cheap, fast, reliable,…

But then I discovered the new Azure Static Web App capability, as announced during //Build conference earlier this week, so I wanted to give it a try.

And instead of starting from scratch, why not reusing the Hugo content I already have?

**Azure Static Web Site allows you to run JavaScript-based static web apps; Technically, Hugo does the same thing; by creating your blog post in MarkDown, and running “Hugo”, it somehow compiles your new blog post, images,… into a static HTML page. It’s this page and corresponding images (if any) that get uploaded to a “/public” folder. (Same thing happens on Azure Storage Static Site btw). So this was the mechanism I wanted to try.

One major difference between Azure Storage Static Site and the new Azure Static Web Site, is its dependency on GitHub. Yes, publishing your static site content is possible from a GitHub Actions CI Pipeline. While this also worked for the Azure Storage approach, you could actually just copy the compiled HTML files using AzCopy or Azure Storage Explorer.

Create a GitHub Repo

The starting point is having a GitHub Repo available, which contains our content. Again, since I already had all this, this process was quickly done. Make sure you remember your GitHub credentials giving access to the repo you want to use, as this will be asked for during the Static Web Site deployment.

Deploy Azure Static Web Site

From the Azure Portal, select New Resource and search for Static Web Site (Preview); Click Create

Complete the different parameters, required for the resource deployment:

Subscription = Your Azure Subscription
Resource Group = New or existing Resource Group where you want to create the resource
Name = Provide a name for the static web site (Note this doesn’t need to be a unique name like with a regular Azure App Service)
Region = Close-by region where you want to host the site (note only a handful of Azure Regions are supported for now, but will probably grow)
SKU = Free is the only option for now

Next, you are asked for your GitHub Credentials

Provide your GitHub credentials, and accept the application authorization; this will allow for the integration with GitHub Actions CI Pipeline later.

Once the GitHub authorization is confirmed, you can complete the Source Control parameters:

Organization = your GitHub account organization
Repository = select the GitHub Repo containing the sample Hugo website (in my example, this is github.com/pdtit/hugotest1 - feel free to Fork)
Branch = the Repo branch (typically master, but could be different)

Click the “Next:Build” button, to move on to the next step in the resource creation process; here, you point to the actual site folder containing the site content. In case of Hugo, this is typically the "/public" folder from your local Hugo development location

Note you only have to complete the App Location parameter, and leave the other 2 empty

Complete the process by clicking the “Review & Create” button. When all looks OK, confirm by pressing the “Create” button. Wait for the Azure resource to get created; this shouldn’t take that long.

Once the resource is created, select “Go to Resource” from the notification popup appearing; this will redirect you to the actual Static Site resource that just got created. Notice the unique URL that got created for this specific site.

Notice the blue ribbon informing you about not having any content of the site yet, and pointing to GitHub Actions. Click on the blue ribbon to get redirected to the GitHub Actions. Notice an “Azure Static Web Apps CI/CD” Action is automatically created, and running (orange color); Give it a few minutes to complete (green color).

If you want to see more details about the CI/CD pipeline itself, select the pipeline; this will show the Build and Deploy Job status, exposing details for each and every step in the build process

Verify the Static Site is running

Only thing left to do is validating if the website is actually running. TO do this, go back to the Azure Portal, and click on the URL of the Static Site

This brings up your browser and nicely shows the Hugo website. Notice this is an Azure Namespace URL for now, but feel free to continue the configuration by checking on the Custom Domains option.

While this is still in preview, I’m pretty convinced this will soon become a very popular service. I know I’ll keep using it already!

As always, reach out when having any questions, or feel free to share feedback using my social media links.

Found this article useful? Consider supporting my blog

/Peter

Collecting Hugo static site statistics using Azure Application Insights

Sun, 26 Apr 2020 00:00:00 +0000

Welcome back!

About a month ago, I decided to move my former 007FFFLearning website from Wix.com to something “easier” to use for blog writing. While Wix is an excellent platform, offering an easy way to build a graphical website, besides a ton of plug-ins, it also comes with a cost. And since I didn’t have a need for a lot of the built-in features I was using out of my own business before I joined Microsoft, I wanted to try something new.

That “something new” eventually was Hugo, an Open Source web platform, supporting HTML and MarkDown. After a quick test, I found it also worked fine on Azure Storage Static Site, which to me was the motivation to give it a try.

(FYI, have a look here about how to get your own Hugo website started, and hosting it on Azure including Azure CDN or Azure Front Door services…)

Having a platform for blog posts is one thing, getting your hands on statistics around popular posts and overall web site visits is maybe even more crucial if you want to take blogging serious. Since the core backend of my Hugo site is running on Azure, I wanted to integrate Azure Application Insights, since I knew how powerful it was for monitoring web application workloads, running in Azure or elsewhere.

1. Deploying Application Insights

The first step is straight forward if you already have Azure experience. From the Azure Portal, create a new resource, and search for “Application Insights”.

Complete the necessary parameters to get this resource created:
- Subscription
- Resource Group
- Name
- Azure Region
Wait for the resource to get created. Once created, open the Application Insight blade:

2. Integrating Instrumentation Key script into the Hugo website

From the top right corner, it will show you the “Instrumentation Key”, which is the unique identifier for this Application Insights instance. This must be linked to each and every web page we publish on our website, to transfer telemetry information back to the App Insights back-end. The way to do this is adding a little JavaScript script into the header of the index.html, and is described more in detail at the following Azure docs link:

While this sounds like a tremendous job, Hugo actually makes this rather easy. Although you create each standalone post (or other item) as a single MarkDown file, during the “rendering process”, Hugo compiles this into a static index.html for each post (or other item). This is based on gluing different snippets of the layout together.

In my Hugo theme, I found out that using the “head.html” file in the root of my layout folder “(<Hugo_source_folder\themes<themename>\layouts\partials)” would to the trick.

Open this file in a text editor like VS Code, and browse all the way to the end of the section. Paste in the following lines (as shown on the Azure Docs page), replacing the INSTRUMENTATION_KEY with the one you find in the Application Insights Overview section:

1
2
3
4
5
6
7


<script type="text/javascript">
 var sdkInstance="appInsightsSDK";window[sdkInstance]="appInsights";var aiName=window[sdkInstance],aisdk=window[aiName]||function(e){function n(e){t[e]=function(){var n=arguments;t.queue.push(function(){t[e].apply(t,n)})}}var t={config:e};t.initialize=!0;var i=document,a=window;setTimeout(function(){var n=i.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",i.getElementsByTagName("script")[0].parentNode.appendChild(n)});try{t.cookie=i.cookie}catch(e){}t.queue=[],t.version=2;for(var r=["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n("track"+r.pop());n("startTrackPage"),n("stopTrackPage");var s="Track"+r[0];if(n("start"+s),n("stop"+s),n("setAuthenticatedUserContext"),n("clearAuthenticatedUserContext"),n("flush"),!(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&&!0===e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+(r="onerror"));var o=a[r];a[r]=function(e,n,i,a,s){var c=o&&o(e,n,i,a,s);return!0!==c&&t["_"+r]({message:e,url:n,lineNumber:i,columnNumber:a,error:s}),c},e.autoExceptionInstrumented=!0}return t}(
 {
 instrumentationKey:"INSTRUMENTATION_KEY"
 }
 );window[aiName]=aisdk,aisdk.queue&&0===aisdk.queue.length&&aisdk.trackPageView({});
</script>

The code within the head.html file should look similar to this now:

3. Render/Compile your Hugo Website

From the root folder of the Hugo Website, run hugo to recompile all your content pages (posts and other) into their final index.html files.
Publish the source code of the website to your Azure Static Site
Browse to a few posts on your website, to generate traffic; we will validate this in the next step from within Application Insights

4. Get statistics from within Application Insights

Back in Application Insights in the Azure Portal, browse to Usage

and select Users; this will show you a diagram of the user visits for the last 24 hours. You can change the time window if needed by selecting other filters.

For example, changing the time window to 7 days, changes the view to this in my example:

If you click the “View More Insights” button, you can see additional statistical details about the site visitors, this time nicely structured by country:

Scrolling more down shows yet another summary view, summarized by (active) session:

Click on any of the active session details; this opens a sidebar view, exposing more granular information about that session:

Back from the Usage menu of Application Insights, select Events

This will again show you detailed views on the actual past events for the last 24 hours, 7 days or any other time window you select. You can again click the “View More Insights” button, to find specific event statistics, which refer to page views of each and every blog post on our website.

Click on any of the event statistics items; this redirects you to another section in Application Insights, the “End-to-end transaction details”

From this view, select All available telemetry information for this session, under the Related items section:

Which in turn exposes additional details about each and every item viewed during that specific session

4. Summary

Application Insights is a powerful (web) application monitoring and troubleshooting tool within Azure, coming with impressive dashboards. This allows for very detailed analytics of web sessions, users, telemetry information and more. While App Insights has a lot more features than what I covered here, it helps in getting a clear view on your Hugo website view statistics.

And that was the core objective of this post.

I’m learning more about Hugo in combination with Azure services, and love it more each and every day. Expect more posts around these subjects in the near future.

For now, stay safe and healthy! as always, reach out to share your feedback or ask questions.

/Peter

Running an Azure Storage Static Site, protected by Azure Front Door

Sat, 25 Apr 2020 00:00:00 +0000

Earlier this week, I had the honor to present a session for the Belgian MC2MC Microsoft community, as part of a broader online event week with other Belgian community User Groups (https://www.mc2mc.be/events/be-community-week-mc2mc-evening).

My session topic was based on a little real-life project I worked on myself only a few weeks ago, deploying a â€œHugoâ€ based static website on Azure Storage Account Static Site (Yes, this site you are reading right now…).

As there were quite some steps to go through, I decided to write a full blog post about it. And thatâ€™s exactly what brings you here…

If you are new to Hugo, have a look at the official website for more information: http://gohugo.io

Although Hugo supports both HTML and MarkDown, I decided to go for MarkDown; if this is unknown to you, think of it is a web page markup language, with a specific syntax. While it might feel difficult in the beginning, it is actually rather straight forward to use once you get the hang of it. I could also recommend MarkDown Monster as an editor, if you are not into using Visual Studio Code.

-—————-

1. Getting started

Install Hugo on your local machine, from http://gohugo.io (I’m running this on Windows 10, but it also supports Linux and MacOS)
Next, grab a copy of VS Code (http://code.visualstudio.com); this is my favorite for both terminal and MarkDown editing
From within VS Code, Choose “Open Folder”
Run Terminal
Run “Hugo version”

2. Create new site

Run “Hugo new site <sitename>”
Hugo default folder structure is created automatically
Download (or Clone GitHub) a theme from http://themes.gohugo.io, and extract the folders in the \themes folder + copy the config.toml from the \themes folder into the root of the site directory that got created in the previous step.
(Minimal is what Iâ€™m using for this blog site
Open browser http://localhost:1313
This opens the sample Theme-based website.
Base site is working fine;
Stop the running â€œHugo Serverâ€ Process by pressing Ctrl-C in the terminal window.
to update or add new content, open the Content\post subfolder
Create a new MarkDown document, or copy an existing one as a starting point; I personally use MarkdownMonster or Visual Studio Code as my MarkDown Editor, but any advanced text editor should work out fine.
For a cheat sheet of MarkDown code syntax, have a look here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
edit some content in the page
Once your new post has been created, open your terminal again, and run â€œHugo Serverâ€. This will start a new web session. Validate from the browser on http://localhost:1313 if the new page is visible
Works!!

However, this is â€œonly localâ€ on our dev station; to prepare the site to get published to Azure, compile it by running â€œhugoâ€ from the command prompt (instead of hugo server)

![](../images/screenshot-2020-04-25-755a8a74.png)

This compile process creates the actual â€œweb contentâ€ in a /public/ subfolder in the same directory as the hugo site itself.

3. Publish to Azure Storage Account

Deploy an Azure Storage Account v2 as a starter
From Settings, select Static website
Enter information for the default page and error page
Save the settings; Your static website URL gets generated and presented

As we now have the storage account static site service up-and-running, we can deploy our content. I am using (and recommending!) Visual Studio Code to do this, but you could also copy the content in a manual way by using FTP or Azure Storage Explorer to do this.

From VSCode, add Storage Account Extension
From Command Palette : Azure Storage / Deploy to Static Website
Complete the prompts with answers from your Azure subscription and setup, and select your Hugo folder as a source. This will copy all files from the /public/ subfolder into the Storage Account $web folder
Wait for the process to complete successfully
Browse to the URL of the storage account
DONT PANIC!! THIS IS EXPECTED
The reason this FAILS is because Hugo is using the /public/ subfolder to publish all content; If you are just using flat HTML files in the Static Site, it will work right away.
try connecting to the URL path where our blog posts are stored, e.g. ../public/post/
The site page itself loads, but itâ€™s not 100% OK ; we need to find a solution for that /public/ URL update. Good news is, Azure has such a solution built-in, which is called Azure Content Delivery Network â€“ CDN.

Letâ€™s deploy one.

4. Deploy & Publish with Azure CDN

New Resource / CDN /
- Provide a Name + Resource Group and Subscription details
- Pricing = Standard Microsoft
- Select Create a CDN endpoint now
  - Provide a unique name for the URL
  - Origin type = Custom
  - Origin hostname = paste in the URL address of the Static Website without the https:// and without the trailing /
Once created, open the CDN Profile resource

Select the Endpoint you defined under the Endpoints section
Under Settings / select Rules engine
In the Rules engine / select Add Action / Choose URL Rewrite
Create the following rule settings:
- Source Pattern: /
- Destionation: /public/
- Preserve unmatched path: Yes
Save the changes, and wait for the prompt the configuration has been updated successfully. NOTE: it could take up to 10min before the changes are actually applied and working. So be patient
Once received, test the Azure CDN URL from the browser, and click through to a site subsection like Posts or Publications (if you have content in there…)
THIS WORKS!!
From here, you could add a custom domain option, together with integrating HTTPS using CDN Profile settings itself. Iâ€™m sure you will find out now by yourself how to do that.
However, allow me to continue on the scenario, and extending our setup with Azure Front Door, a Global Azure load balancing service, which also performs SSL offloading, Session Affinity, URL rewrite/redirection and probably the most important feature Web Application Firewall.
NOTE: from here, we wonâ€™t be able to stay within the <$5 /month consumption fee, as the required Azure Front Door rules will add an additional cost of +/- $20 /month, or +/-$50 /month if you enable the WAF option.

5. Deploying Azure Front Door

Technically, for this web site scenario, Azure Front Door offers all capabilities we used before from Azure CDN. Meaning, if you decide to go for Azure Front Door, you do not need Azure CDN.

New Resource / Front Door / Create
Complete the basic settings around Subscription, Resource Group and location
Move on to the Configuration step next
Click the + sign to add the Front Door Frontends/domains settings, and provide a unique name for the Front Door URL you want to use
Continue with Step 2 where you define the backend pool settings. This is basically pointing Front Door to the Static Site Storage Account URL
Click â€œ**Add BackEnd Poolâ€, and complete the requested parameters:
- BackEnd Host Type: custom
- Backend Host Name: the Static Web Site URL, without the https:// and trailing /
Accept / leave all other values as default
Confirm the Backend Pool settings ,which brings you back to the BackendPool settings tab. Here, leave the default values for Health Probes and Load Balancing for now
Confirm the BackendPool settings, and move on with Step 3, where you will define the necessary routing rule.
In the Add Rule parameter section, provide a name for the rule you are about to create. Accept the default values for Accepted Protocol, FrontEnd/domains and Patterns to Match.
In the Route details section, scroll down and change the setting for Custom forwarding path, adding the â€œ/public/ path that is used by Hugo (Note: this path could be different, depending on the Hugo Theme; this path technically refers to the directory that Hugo uses to store the compiled site pages.
Wait for the Azure Front Door resource to get created; once this is complete, open your browser to the URL address of Front Door. This should open your web site in a nice looking way

6. Configure Public Custom Domain Name to Azure Front Door

In this last section, we will update our Azure Front Door configuration for
a public custom domain name. This is built-in, and integrates a Letâ€™s
Encrypt (FREE) SSL/TLS certificate to your web service. How cool is that!

**Note: you need to have a public DNS domain name already available, in
which you need to create a C-name alias record for the Azure Front Door
frontend/domain name you configured. E.g. my 007FFFLearning domain has a
â€œwwwâ€ C-Name alias pointing to â€œhugofd.azurefd.netâ€**

From the Azure Front Door blade, select Front Door Designer; next, select Frontends/domains, and add a new custom domain
If you also want to add the Domain HTTPS option to the configuration, select this setting a bit more down in the blade. If you donâ€™t have a PFX certificate file already for the public domain name space, have one generated by Front Door, by choosing Front Door managed.
Confirm the settings by clicking Add
Wait about 10 minutes to complete the SSL request status, resulting in the below view:
Once the custom domain is configured, we need to make one last change in our routing rules, adding the custom domain to the configuration. Therefore, select the routing rule you created earlier, and update its settings:
Save the changes, and wait for the update to get applied.
After only a few minutes, everything should be running smooth, allowing you to connect to your website custom domain url:
Selecting any of the subsections from the header menu, e.g. Posts will be nicely redirected to all posts, and allowing your readers to easily go from one blog article to the other.

Congrats!! You made it all the way to the end!

I hope you enjoyed this exercise, and are ready for fully working on your blog website now. Get back into your Visual Studio Code, and start hammering some MarkDown posts!

As always, Iâ€™m here for you if you are stuck somewhere, or want to let me know once your site is up-and-running.

Happy Hugo-ing!

Take care, Peter