Using a Dev Container Image in CI/CD Workflows with GitHub Actions

Streamlining pipelines by reusing your local development environment in CI/CD

Welcome back!

In our last post, we walked through building and publishing a Dev Container to GitHub Container Registry (GHCR) using GitHub Actions. That container included everything we needed for development and infrastructure automation: .NET, Terraform, Azure CLI… And then we wrapped it up in a reproducible Docker image.

Today, we’re taking that one step further by using the same container image inside our GitHub Actions workflows.

This is a practical way to eliminate discrepancies between your local dev setup and your CI/CD pipelines. If you've ever experienced “but it works on my machine” issues due to mismatched versions of tools… Well, this approach is for you!

---

✅ Why Use the Dev Container in CI/CD?

Consistency. By reusing the Dev Container you built earlier, your pipeline runs in exactly the same environment as your local machine. That means:

• No surprise errors due to different tool versions

• Quicker debugging

• A single source of truth for your dev stack

---

🛠️The Workflow: Terraform Validation with a Container

To get started, I’ve built a simple GitHub Actions workflow that:

• Triggers on every push to main

• Runs inside the Dev Container we previously published

• Validates a Terraform project using terraform init and terraform validate

• Checks installed versions of az and .NET

Here’s a snippet of the core setup:

name: Build

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    container:
      image: ghcr.io/${{ github.repository_owner }}/ci-cd-kv-sample:latest
      
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Run Terraform Init
        run: terraform init

      - name: Run Terraform Validate
        run: terraform validate

      - name: Run Az Version
        run: az --version

      - name: Run dotnet version
        run: dotnet --version

---

🔍 What's Happening Here?

Let’s break it down:

1. Trigger on Push
   Every time you push to main, this workflow kicks off automatically. That’s perfect for continuous validation.

2. Runs Inside the Container
   This is the big one. Instead of just running on a plain ubuntu-latest runner with manually installed tools, the workflow spins up inside the exact container image you created earlier. That means all your tool versions are already set up.

3. Validates Infrastructure Code
   We’re starting simple with a terraform init and terraform validate, but this pattern can scale to full-blown application builds and deployments.

4. Verifies Tooling
   We run az --version and dotnet --version to confirm the container has the correct versions baked in. This is a good sanity check early in pipeline development.

---

📦 What This Enables

By containerising your dev environment and reusing it in CI/CD, you unlock:

• Reproducibility across teams

• Faster onboarding

• Easier debugging when things go wrong

• No more “install this before you can run the pipeline”

And the best part? You can build on this by adding more steps like dotnet build, running tests, deploying infrastructure… Whatever your pipeline needs.

---

What's Next?

In the next post, we'll expand on this by setting up our .NET project and creating a build step to the workflow, showing how to evolve this pattern into a full application deployment pipeline.

If you’ve enjoyed this series so far, consider subscribing or dropping a comment, I'd love to hear how you're using Dev Containers in your workflows.

Until next time… Happy shipping!