This article explains how to fix an issue where a BlazorStatic build job running on GitHub Actions never finishes. It’s a puzzling case, but can’t really blame GitHub for this one. Can’t actually blame anyone but myself, now that I think about it.
But enough about that. What’s the issue look like?
Background
Now that the biggest craze on static websites is long gone, I’m jumping on the bandwagon.
After evaluating other options, I ended up going with BlazorStatic – a library built on Blazor.
BlazorStatic uses Static Server-Side Rendering (SSR) to render a – you guessed it – static website without server-side interactivity.
Everything was working nicely locally. But when I tried to set up a build on GitHub Actions, stuff started to go wrong.
Problem
When running a build for a project that builds a StaticBlazor website, it fails.
The error? Well…
Error: The operation was canceled.
Yeah, not super informative right there.
But when enabling the timestamps in the log (see below), slightly clearer image appears.
(“Explain error” button was not helpful – I tried)
Namely – it took a couple of minutes to build the site. And 20 minutes later the build finally stopped.
And it stopped even then only because that was my maximum runtime for the build.
I decided to ask Copilot how to fix it. You know – as one does.
And while in the IDE, Copilot was just vehemently trying to convert me from using dotnet run to dotnet publish, on GitHub Actions, it had a lot of other ideas.
And all of these ideas were – more or less – wrong. But I’m listing them here for completeness’s sake!
Wrong Solutions
1. Adjust dotnet run to Output Detailed Errors
Add explicit logging to capture which files cause errors and why:
name: Run webapp and generate static files
run: |
dotnet run --project ${{ env.WEBAPP_PATH }}${{env.WEBAPP_CSPROJ}} --configuration Release --verbosity detailedThis will provide more granular error details to debug specific issues.
2. Increase Timeout
If file processing consistently exceeds the current timeout, increase it in the workflow:
jobs:
build:
runs-on: ubuntu-latest
timeout-minutes: 60 # Extend timeout to 60 minutes3. Parallelize File Processing
Instead of processing all files sequentially, modify the application to enable parallel processing for static file generation. This requires changes in the source code of the BlazorStaticService.
4. Handle Large File Names
Some blog file paths in the logs appear excessively long. If these exceed filesystem limits, trim or hash file names during generation.
5. Prevent Specific Errors
Review problematic blog content directly in your repository. For instance, errors in blog generation might stem from invalid HTML or character encoding issues. Testing these blogs locally with:
dotnet run --project ./web/koskilanet.web.csproj --configuration Release6. Ensure Deployment Completes
The deployment step uses the JamesIves/github-pages-deploy-action. Ensure the PAT_GITHUB secret has the correct permissions to manage the gh-pages branch.
Accidental Solution
The closest it got was this, which did fix the issue – seemingly by adding a 300-second long timeout – which didn’t make sense.
I mean – it should just fail the execution after 5 minutes, instead of waiting for the task to fail naturally.
But despite the solution itself being misguided (and basically misinformation), it actually helped me figure out the real solution. So kudos to Copilot, I guess?
But why does it work?
I wanted to figure out WHY it worked. So I took a look at the change history.
And what did I find?
run: |
dotnet run --project ${{ env.WEBAPP_PATH }}${{env.WEBAPP_CSPROJ}} --configuration ReleaseThat’s right – there were 2 spaces in the command.
And while that’s exactly the kind of issues that Copilot is perfect for finding – the stupid little bot refused to get over its very own hubris to actually help me out.
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
