David Gardiner - GitHub

Delete old GitHub Actions artifacts with PowerShell

2026-03-21T16:00:00.000+10:30

I received an email from GitHub overnight saying:

You have used 90% of the Actions storage included for the flcdrg account

Your plan includes 2 GB of Actions storage per month at no extra cost. You have used 90% so far this billing cycle. 1.8 GB used / 2 GB included

Oh dear, that's not good. Time for some Spring (or Autumn as it is in Australia) cleaning!

I found a useful post by Elio Struyf - Clean up old GitHub Actions artifacts with a script, which contains a Bash script to delete old artifacts. PowerShell is my preferred scripting language so I first asked Copilot to convert the Bash script to PowerShell.

I then ran it on some repositories that I new had lots of artifacts, but noticed that the paging was not working quite right, and that it was skipping artifacts if it couldn't parse the date field.

I made two changes:

Read all the data in one go using the --paginate --slurp parameters. This solves the problem that I think was happening when you read a page of results, then deleted them, and then asked the API for the next page, but the counts would now be out due to the deleted items.
Ensure the date string is parsed using US date format (as it was defaulting to Australian format and then getting confused with dates that didn't make sense)

Here's the final script:

param(
    [Parameter(Position = 0)]
    [string]$Repo,

    [Parameter(Position = 1)]
    [int]$DaysOld = 5
)

if (-not (Get-Command gh -ErrorAction SilentlyContinue)) {
    Write-Error "GitHub CLI (gh) is not installed or not available in PATH."
    exit 1
}

$null = gh auth status *> $null
if ($LASTEXITCODE -ne 0) {
    Write-Host "Please authenticate with the GitHub CLI using 'gh auth login'."
    exit 1
}

if ([string]::IsNullOrWhiteSpace($Repo)) {
    Write-Host "Usage: .\delete-github-action-artifacts.ps1 <owner/repo> [days-old]"
    Write-Host "Example: .\delete-github-action-artifacts.ps1 owner/repo 5"
    exit 1
}

Write-Host "Cleaning up artifacts older than $DaysOld days for repository: $Repo"

$pagesResponse = gh api --paginate --slurp -H "Accept: application/vnd.github+json" "/repos/$Repo/actions/artifacts?per_page=100" | ConvertFrom-Json
$allArtifacts = @()

foreach ($pageResponse in @($pagesResponse)) {
    if ($null -ne $pageResponse.artifacts) {
        $allArtifacts += @($pageResponse.artifacts)
    }
}

if (-not $allArtifacts -or $allArtifacts.Count -eq 0) {
    Write-Host "No artifacts found."
}
else {
    foreach ($artifact in $allArtifacts) {
        $id = $artifact.id
        $name = $artifact.name
        $createdAt = $artifact.created_at

        if ($null -eq $id -or [string]::IsNullOrWhiteSpace($name) -or [string]::IsNullOrWhiteSpace($createdAt)) {
            $artifactJson = $artifact | ConvertTo-Json -Compress
            Write-Host "Skipping invalid artifact data: $artifactJson"
            continue
        }

        try {
            $createdAtUtc = [DateTimeOffset]::Parse($createdAt, [System.Globalization.CultureInfo]::InvariantCulture).UtcDateTime

            $ageDays = [int][Math]::Floor(([DateTime]::UtcNow - $createdAtUtc).TotalDays)

            if ($ageDays -gt $DaysOld) {
                Write-Host "Deleting artifact: $name (ID: $id, Age: $ageDays days)"
                $null = gh api -X DELETE "/repos/$Repo/actions/artifacts/$id" 2>$null

                if ($LASTEXITCODE -ne 0) {
                    Write-Host "Failed to delete artifact: $name (ID: $id)"
                }
            }
            else {
                Write-Host "Keeping artifact: $name (ID: $id, Age: $ageDays days, Created At: $createdAt)"
            }

        }
        catch {
            Write-Host "Deleting artifact: $name (ID: $id, Created At: $createdAt)"
            $null = gh api -X DELETE "/repos/$Repo/actions/artifacts/$id" 2>$null

            if ($LASTEXITCODE -ne 0) {
                Write-Host "Failed to delete artifact: $name (ID: $id)"
            }

        }

    }
}

Write-Host "Cleanup completed."

I've also published it as a GitHub Gist at https://gist.github.com/flcdrg/f204fc3f84247fe6247d654c0a673b73

Prevention

The main cause of accumulating artifacts is by using the actions/upload-artifact action in GitHub Actions workflows. I've now updated those actions to include the retention-days property so that artifacts are automatically deleted after a few days.

eg.

      - name: Upload wrangler.jsonc
        uses: actions/upload-artifact@v7
        with:
          name: wrangler.jsonc
          path: wrangler.jsonc
          retention-days: 2

Passed AZ-400

2022-02-23T19:30:00.000+10:30

I'm pleased to report that today I passed Microsoft exam AZ-400: Designing and Implementing Microsoft DevOps Solutions, which combined with AZ-201 that I took last year, now qualifies me for the Microsoft Certified: DevOps Engineer Expert certification.

View my verified achievement from Microsoft

The exam is quite broad in the content it covers:

Develop an instrumentation strategy (5-10%)
Develop a Site Reliability Engineering (SRE) strategy (5-10%)
Develop a security and compliance plan (10-15%)
Manage source control (10-15%)
Facilitate communication and collaboration (10-15%)
Define and implement continuous integration (20-25%)
Define and implement a continuous delivery and release management strategy (10-15%)

Some areas I'd been working with for quite a few years, but others were new to me. To help prepare I used a couple of resources:

Nice to get that one dusted.

Using GitHub Actions to update packages.lock.json for Dependabot PRs

2021-05-27T08:00:00.000+09:30

I like using Dependabot to keep my package dependencies up to date. But it does have one problem if you're using packages.lock.json files with NuGet packages - it doesn't update them. So your csproj will be modified but the packages.lock.json file won't, which can lead to broken failing.

Here's one approach to working around this. Hopefully GitHub will fix this properly in the future.

ChatOps

I'm going to make use of Peter Evans' Slash Command Dispatch GitHub Action to enable triggering by entering /lockfiles as a comment on the pull request. This action is extensible and can be used to create all kinds of 'slash' commands.

First up, I created a new workflow that uses this action:

name: Slash Command Dispatch
on:
  issue_comment:
    types: [created]
jobs:
  slashCommandDispatch:
    runs-on: ubuntu-latest
    steps:

      - uses: xt0rted/pull-request-comment-branch@v1
        id: comment-branch

      - name: Slash Command Dispatch
        uses: peter-evans/slash-command-dispatch@v2
        id: slash-command
        with:
          token: ${{ secrets.PAT_REPO_FULL }}
          commands: |
            lockfiles
          permission: write
          issue-type: pull-request
          dispatch-type: workflow
          static-args: ref=${{ steps.comment-branch.outputs.head_ref }}

Things to note:

We're triggering on a new comment being added to a pull request
We use Pull Request Comment Branch Action to obtain the name of the branch that is linked to the pull request for the triggering comment.
The dispatch-type is set to workflow as we want the secondary workflow to run against the pull request branch (not the default branch)
We set the ref argument to the branch name. This will be picked up by the second workflow.

The second workflow is named lockfiles-command.yml. It needs to follow the convention of commandname-command.yml.

name: Update lockfiles
on:
  workflow_dispatch:

jobs:
  lockfiles:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
          token: ${{ secrets.PAT_REPO_FULL }}

      - name: Setup .NET 5
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: 5.0.x

      - name: Restore dependencies
        run: dotnet restore --force-evaluate

      - uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: Update lockfiles

Things to note:

This workflow uses the workflow_dispatch trigger.
The checkout action notices that the ref value was set in the first workflow and so will checkout the pull request branch.
We use the git-auto-commit Action to commit and push any changes made by the earlier dotnet restore command.

To trigger the workflow, add a new comment to a pull request with /lockfiles. eg.

You can see a complete repo with example pull request over at https://github.com/flcdrg/dependabot-lockfiles/pull/1

Future ideas

It could be possible to have this workflow trigger automatically after Dependabot creates the pull request if you wanted to completely automate this approach, rather than needing to add the comment manually.

Holiday learning

2021-01-07T16:00:00.000+10:30

I'm in the middle of 3 weeks of annual leave. It's great to just put work aside for a bit and take time to unwind. I've been out walking, cycling, drying apricots and making apricot jam, catching up with friends and family, amongst other things.

I thought I'd use some of my time off get more familiar with Azure and GitHub and have been pleasantly surprised by the learning materials available over at docs.microsoft.com.

Learning content is organised in modules - these are self-contained units of work. Modules might be grouped together in a 'Learning Path'. Some content relates to specific Microsoft exams, so if you're interested in gaining a specific certification you can work back from the exam requirements to help ensure you've covered all the areas.

eg. To achieve the Microsoft Certified: DevOps Engineer Expert certification, after you've achieved one of the associate pre-requisites, you then need to pass Exam AZ-400: Designing and Implementing Microsoft DevOps Solutions.

One of the learning paths for this exam is AZ-400: Manage source control.

In that learning path is the module Manage software delivery by using a release based workflow on GitHub.

The GitHub-related content usually has an overview and some introductory content. Then they include a practical exercise which actually uses GitHub. These are cleverly done by automatically cloning a repository into your own GitHub account, and then stepping you through using GitHub issues (and sometimes pull requests) with automated responses updating the issues or moving you to the next step once you've performed the necessary steps. It's really quite clever!

Now the repository has been created, you can click on Start to begin the process. As you complete each step it will be marked as complete (so you can come back to finish the exercise later if you don't finish it in one sitting)

There's some instructions to follow. I found it's easiest to right-click on the link to open it in another tab, follow the instructions..

and then come back to this tab to wait for the next bit (which will be added as a comment to the issue)

Then click on the link to the next issue to follow on with the next step.

At the conclusion of the exercise, you head back to the docs site for a knowledge check with a multiple choice quiz to check that you've understood the main concepts for the module, and then you're done!

Some modules covered concepts I was already familiar with so if I felt the practical exercise didn't contain anything new then I'd just skip directly to knowledge check.

Azure learning modules are similar, except that instead of using GitHub, they often including access to temporary Azure resources. Some modules might embed an Azure cloud shell right in your browser on the same page as the instructions. Others will ask you to log in to the Azure Portal so you can follow through creating or manipulating resources there.

You'll be asked to active the sandbox (and probably will need to review permissions)

Here you can see the "Microsoft Learn Sandbox" subscription, which is used for the learning activities. It is only a temporary subscription and will disappear after a few hours, and more importantly means any resources used there don't cost you anything.

Here's an example of a page using the Azure Cloud Shell. Many modules wil use bash, but this specific example is using PowerShell:

The modules will often check your work to confirm that you've followed the instructions correctly:

Also worth mentioning if you'd like some free instructor-led training then check out the Microsoft Azure Virtual Training Day: Fundamentals that are are being run during January and February. As a bonus, attendees will be eligible to take the Microsoft Azure Fundamentals certification exam for free! (Credit to Bronwen Zande for tweeting about this)

So if you're looking to upskill, or just deepen your knowledge of Azure and GitHub then now is a great time to dive in.

8-Jan-2021 - Added screenshot of Azure cloud shell

Publishing future blog posts with GitHub Pages and GitHub Actions

2020-05-04T08:00:00.000+09:30

I switched to using GitHub Pages and Jekyll for my blog a while ago. There was one deficiency I noticed - the lack of being able to publish future blog posts. Because the site is static, the Jekyll processing is only performed when a new commit is pushed, and it only publishes content 'in the past'. The problem is a future post has already been committed to Git, but there's no subsequent commit to republish the site once the publish date comes around.

There's been various hacks around (usually involving an scheduled commit followed by a revert), but after listening to a recent podcast from Scott Hanselman talking to Edward Thomson about GitHub Actions, I wondered if they might offer a way to automate refreshing the site on a daily schedule.

I started by adding a GitHub Action workflow to the website and took a look at some of the existing actions others had already written, figuring someone might have solved this problem already. I discovered that GitHub Pages treats 'user' sites like mine differently to 'product' sites. The actions I found seemed suited more to the 'product' kind (as they wanted to commit the static content to the master branch).

I then resorted to Twitter..

You can use the api to trigger a rebuild, doesn’t that work?https://t.co/2gaaIIMfWB

— Rob Bos (@RobBos81) May 1, 2020

Rob (who I know through the Global DevOps Bootcamp) gave a good suggestion - using the Request a page build REST API. It took a few goes to get the API call working with octokit/request-action, but a test post later and I confirmed it worked!

Here's the current version:

name: Build GitHub Pages

on:
  schedule:
    - cron:  '0 */12 * * *' # Rebuild twice a day (every twelve hours on the hour).

jobs:
  logLatestRelease:
    runs-on: ubuntu-latest
    steps:
      - uses: octokit/request-action@v2.x
        id: post_build
        with:
          route: POST /repos/flcdrg/flcdrg.github.io/pages/builds
        env:
          GITHUB_TOKEN: ${{ secrets.GH_PAGES_TOKEN }}

Nice, now I can schedule blog posts in the future, and know that they'll be published as intended.

Future post

2020-05-01T21:00:00.000+09:30

If I coded the GitHub Action correctly, this blog post should get published even though I've dated it 40 minutes in the future from when I committed it to the repository.

Migrating from Blogger to Jekyll and GitHub Pages

2019-06-11T08:00:00.000+09:30

I've been in a bit of a blogging slump the last few months. Partly because I've been particularly busy, but also I've been a bit frustrated with Blogger. I used Windows Live Writer (later Open Live Writer), but sadly after all the effort to make it open-source, the project has kind of floundered with no one apparently leading the project now.

So what to do? Well maybe it's time to move to a different platform. I'd see a few people with their blogs on GitHub, and after a bit of research I settled on using Jekyll with GitHub pages.

How I migrated from Blogger

I followed this useful checklist - https://thefriendlytester.co.uk/2017/07/blogger-to-jekyll-migration-timeline. Note that the jekyll-importer does not convert Blogger content to Markdown (that had me confused for a few hours).

I stuck with the same URL format for posts, so that should mean no broken links.

I made use of Windows Subsystem for Linux to run Jekyll locally (as I'd read it wasn't so easy to get running natively on Windows). See below for more details of getting that all running.

Update Cloudflare to point to flcdrg.github.io - https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/

Update FeedBurner settings to point to new source RSS feed.

What I forgot

I use dlvr.it to post to Twitter about new blog posts. I should have disabled that as it got confused by the change and thought I'd posted some new articles.

Still to do

The Blogger migration only copied text. Images are still living in their original locations. It would be good to migrate them over too.

My old blog had a nice Archive/history listing. I've started looking at Jekyll equivalents, but not found one that's similar yet.

Getting Jekyll running on WSL

sudo apt update
sudo apt upgrade
sudo apt install ruby
sudo apt install ruby-dev
sudo apt install make gcc
sudo apt install g++
sudo apt install zlibc
sudo gem install pkg-config -v "~> 1.1"
sudo apt install libxml2-dev
sudo apt install libxslt-dev
sudo gem install nokogiri -- --use-system-libraries
sudo gem install jekyll-import
sudo gem install jekyll

With my locally cloned Git repo at C:\dev\git\flcdrg.github.io in Windows, in WSL I could change to the equivalent path at /mnt/c/dev/git/flcdrg.github.io, and then run jekyll server.

Anything else?

Let me know in the comments if something is broken that used to work!