Skip to main content
Now that you’ve configured a GitHub Actions environment with protection rules, secrets, and variables, let’s update the dev-deploy job so it automatically picks up the right replica count and enforces your environment policies.

​
Prerequisites

  • A GitHub repository with an development environment that has:
    • One protection rule (e.g., required reviewers or wait timer)
    • One secret
    • Two environment-level variables
  • A working Kubernetes cluster for the development namespace
  • A Docker build job named docker in your workflow
Environment-level variables override repository-level variables. In our example, the repository variable REPLICAS is set to 2, while in the development environment it’s set to 1.
The image shows a GitHub repository settings page focused on configuring environments, with options for protection rules, secrets, and variables.
The image shows a GitHub repository settings page focused on "Secrets and variables," displaying environment and repository variables with options to manage or update them.

​
Verify Current Kubernetes Deployment

Before modifying the workflow, let’s confirm the existing deployment in the development namespace: 
kubectl -n development get deployments.apps
# NAME           READY   UP-TO-DATE   AVAILABLE   AGE
kubectl -n development get pods
# NAME                                  READY   STATUS    RESTARTS   AGE
# solar-system-6db5dfbrf8c-96qcz        1/1     Running   0          26m
# solar-system-6db5dfbrf8c-psbxx        1/1     Running   0          26m
You should see two replicas running (2/2). Now we’ll update the dev-deploy job in .github/workflows/solar-system.yml.

​
Adding the environment Block

Within a GitHub Actions job:
  • env: defines environment variables for all steps.
  • environment: applies GitHub environment protection rules and can display a URL in the Actions UI.

​
Step 1: Basic environment Definition

Replace or augment the env: block with: 
jobs:
  dev-deploy:
    needs: docker
    runs-on: ubuntu-latest

    # Variables for all steps:
    env:
      APP_INGRESS_URL: ${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}

    # Enforce your GitHub environment rules:
    environment:
      name: development
      url: https://
    
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v4
      - name: Install kubectl CLI
        uses: azure/setup-kubectl@v3
        with:
          version: 'v1.26.0'
      - name: Set Kubeconfig file
        uses: azure/k8s-set-context@v3
        with:
          method: kubeconfig

​
Step 2: Populate the url: Field

Use the output of your set-ingress-host-address step so that Actions shows a direct link to the deployed service: 
jobs:
  dev-deploy:
    needs: docker
    runs-on: ubuntu-latest

    environment:
      name: development
      url: https://${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}

    outputs:
      APP_INGRESS_URL: ${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}

    steps:
      - name: Checkout Repo
        uses: actions/checkout@v4
      - name: Install kubectl CLI
        uses: azure/setup-kubectl@v3
        with:
          version: 'v1.26.0'
      - name: Set Kubeconfig file
        uses: azure/k8s-set-context@v3

​
Step 3: Full Workflow Snippet

Below is the relevant section from .github/workflows/solar-system.yml after adding environment: 
.github/workflows/solar-system.yml:
  jobs:
    unit-testing: {}
    code-coverage: {}
    docker: {}
    dev-deploy:
      needs: docker
      runs-on: ubuntu-latest

      environment:
        name: development
        url: https://${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}

      outputs:
        APP_INGRESS_URL: ${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}

      steps:
        - name: Checkout Repo
          uses: actions/checkout@v4
        - name: Install kubectl CLI
          uses: azure/setup-kubectl@v3
          with:
            version: 'v1.26.0'
        - name: Set Kubeconfig file
          uses: azure/k8s-set-context@v3

​
Observing the Protection Rule in Action

When you push these changes, the dev-deploy job will pause at the environment step, waiting out the protection rule’s timer:
The image shows a GitHub Actions workflow interface with a series of jobs including unit testing, code coverage, and containerization, currently in progress. The workflow is triggered by a push to a specific branch.
Clicking on the paused job reveals the wait timer and any bypass options available to admins:
The image shows a GitHub Actions interface with a confirmation dialog for deploying to a development environment, including a comment box for manual override.
Only HTTP/S URLs are supported in the environment.url field.
Once approved, the summary displays the environment URL for easy access.

​
Tracking Deployments Across Environments (Public Beta)

GitHub’s public beta for deployment tracking shows a history of every deployment per environment under Actions → Deployments. You can review commit details, branch names, timestamps, and durations in one interface.
The image shows a GitHub blog post announcing a public beta for a new deployment tracking feature across environments, with a list of capabilities for developers and DevOps managers.
Developers and managers can:
  • Inspect past deployments
  • Compare changes
  • Sign off on releases

​
Quick Reference Table

FieldDescription
nameThe GitHub environment name (e.g., development, staging)
urlThe HTTP/S link displayed in the Actions UI for quick access
protectionRules such as required reviewers, wait timers, or secrets usage

​
Scope and Precedence of Variables

ScopePrecedenceExample REPLICAS Value
EnvironmentHigh1
RepositoryLow2

​
Key Snippet for dev-deploy

dev-deploy:
  needs: docker
  runs-on: ubuntu-latest
  environment:
    name: development
    url: https://${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}
  outputs:
    APP_INGRESS_URL: ${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}

Watch Video