Which Western Digital Red 4TB NAS hard disk should I buy?

Back in April I mentioned purchasing two Western Digital Red NAS 4TB hard disk (Model WD40EFRX).

I’m thinking about buying another one or two similar drives, but on closer inspection I noticed that there’s a few different WD Red 4TB drives to choose from.

Western Digital Red 4TB SATA Drives

Notes:

• Prices were at 15th July 2021, and were captured in Australian Dollars (your currency may differ). Click through to the links to get the latest price. Most Amazon links above are affiliate links.
• Dates are from the oldest specification sheets I’ve found for that model.
• Recording technology: SMR - Shingled Magnetic Recording, CMR - Conventional Magnetic Recording. More info

I also found a useful overview of the Red, Red Plus and Red Pro lines.

Looking at that data it does look like for the ‘Pro’ line the WD40EFZX represents better value, but for the home enthusiast the WD40EFAX seems reasonable.

GitHub Actions default environment variable gotcha

I was trying to use a GitHub Action default environment variable in a workflow today, and was surprised to find that it didn’t work as expected. The workflow contained a step similar to this:

jobs:
  build:
    steps:
        - name: Output job info
          run: echo "Job '${{ env.GITHUB_JOB }}'"

According to the documentation, GITHUB_JOB should contain the job_id of the current job. In this workflow, the job_id should be “build” (as that’s the name of the current job).

But when I ran the workflow all I got was Job ''. I found a couple of posts that seem to hint at the answer.

GitHub sets default environment variables that are available to every step in a workflow run.

In short, the documentation seems to be a little misleading here. The ${{ env.xxxx }} notation works find for env: context variables that you’ve defined yourself, but not for the default environment variables. Either refer to the variable in the way appropriate for the script language (if you’re using run), or if you’re setting a property for an action you can use a different approach. eg.

jobs:
  build:
    steps:
        - name: Output job info
          run: echo "Job '$'"

Azure DevOps PowerShell Scripts - List all release definitions and dependant builds

It’s easy to open a specific release definition in the Azure DevOps web UI to find out what builds it references, but you can’t do the opposite - open a build to see which release definitions rely on it.

Last time we got a list of Azure Pipelines Release Definitions. Let’s go the next step and match up the builds that are being consumed by each release definition. With this list, we can now filter down to a build and find which releases use it.

See Personal access tokens for instructions on how to create the personal access token.

param (
    [string] $organisation,
    [string] $personalAccessToken
)

$base64AuthInfo= [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($personalAccessToken)"))
$headers = @{Authorization=("Basic {0}" -f $base64AuthInfo)}

$result = Invoke-RestMethod -Uri "https://dev.azure.com/$organisation/_apis/projects?api-version=6.0" -Method Get -Headers $headers

$projectNames = $result.value.name

$projectNames | ForEach-Object {
    $project = $_

    $result = Invoke-RestMethod -Uri "https://vsrm.dev.azure.com/$organisation/$project/_apis/release/definitions?api-version=6.1-preview.4&`$expand=artifacts" -Method Get -Headers $headers

    $result.value | Select-Object name, 
        @{ Name = "Url"; Expression = { $_._links.web.href }},
        @{ Name="Artifacts"; Expression= { $_.artifacts.alias }}, 
        @{ Name="artifactSourceDefinitionUrl"; Expression= { $_.artifacts.definitionReference.artifactSourceDefinitionUrl.id }}
}

This script also makes use of the Definitions - List REST API. This time we’re requesting the artifacts property to be included in the results. It is this property that contains information about builds and their artifacts that are being consumed by the release definition.