Azure Pipelines useful conditions

Wednesday, 6 May 2020

For my own reference as much as anything, here’s a few Azure Pipelines conditions I’ve found useful:

Azure Pipelines

Only run this task when building master

  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))

Only run this task when building a pull request branch

condition: contains(variables['Build.SourceBranch'], 'refs/pull/')

Only run this task when System.Debug variable has been set

condition: eq(variables['System.Debug'], 'true')

If I come across others, I’ll update this post with them.

Publishing future blog posts with GitHub Pages and GitHub Actions

Monday, 4 May 2020

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..

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/[email protected]
        id: post_build
        with:
          route: POST /repos/flcdrg/flcdrg.github.io/pages/builds
        env:
          GITHUB_TOKEN: $

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

Future post

Friday, 1 May 2020

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.

Errors from PowerShell 7 in Azure Pipelines

Thursday, 30 April 2020

I’m aiming to use PowerShell 7 as much as possible, including in Azure Pipelines tasks. I was getting a bit frustrated recently though where I had a task failing, but the log gave absolutely no clue as to why.

eg.

Starting: MyTask
==============================================================================
Task         : PowerShell
Description  : Run a PowerShell script on Linux, macOS, or Windows
Version      : 2.165.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
==============================================================================
Generating script.
========================== Starting Command Output ===========================
"C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\a\_temp\be69a030-2e55-4cb5-9f80-98968e90f3b2.ps1'"
##[error]PowerShell exited with code '1'.
Finishing: MyTask

What’s going on? Turns out it’s because PowerShell 7 now defaults to the ‘ConciseView’ for errors and so the error ends up being so concise it isn’t actually logged. I’m not the first to experience this. The fact that the concise output is not logged at all does look like a bug though.

The solution

Set $ErrorView to ‘NormalView’ as the first line of your script - then you’ll see useful error details that will help with diagnosing what the problem is.

$ErrorView = 'NormalView'

Hopefully in the future, they’ll fix the problem with no errors being logged, or enhance the pwsh task so you can set the errorview as a task property outside of the script.

Update 15th May

As Justin mentions in the comments, this problem has been fixed, so no need to prepend your scripts with $ErrorView = 'NormalView' now!

Upgrading WSL2 to Ubuntu 20.04 and running Jekyll

Tuesday, 28 April 2020

Ubuntu LTS 20.04 just came out, and you can either install into WSL2 from the Windows Store, or if you already had Ubuntu for WSL then you can upgrade that in place using sudo do-release-upgrade -d.

There’s a few confirmation prompts along the way. Eventually you’ll get to a point where it wants to reboot. The trouble is if you try sudo reboot it will complain that you’re not running systemd and give up.

The solution is to jump back to Windows and run wsl --shutdown, then relaunch Ubuntu and it should be happy.

Jekyll

Having a freshly upgraded install of Ubuntu, I thought it was time I got a local copy of Jekyll so I could preview my blog posts.

To ensure that I’m using the same Gems that GitHub Pages use, I updated my Gemfile to just reference the github-pages gem.

source 'https://rubygems.org'

gem 'github-pages'

And then install Jekyll prerequisites:

sudo apt-get install ruby-full -y
sudo apt-get install build-essential dh-autoreconf -y
sudo apt install zlibc -y
sudo apt install libxml2-dev -y
sudo apt install libxslt-dev -y

Tell Ruby to install Gems locally (so we don’t need sudo)

echo 'export GEM_HOME=~/.ruby/' >> ~/.bashrc
echo 'export PATH="$PATH:~/.ruby/bin"' >> ~/.bashrc
source ~/.bashrc
gem update

gem install pkg-config -v "~> 1.1"
gem install nokogiri -- --use-system-libraries

bundle install