Enable Updating GitHub Environment Variables via GitHub Actions Workflow

 To update environment  variables defined in GitHub environment, via a GitHub action workflow we cannot use the default GITHUB_TOKEN .

✅ GITHUB_TOKEN can interact with repository contents (depending on permissions), create releases, comment on PRs, update issues, etc.

❌ GITHUB_TOKEN cannot update repository environments, environment secrets, or environment variables via the GitHub REST API.

Environment Deployment Approvals for GitHub Action Workflow

 In GitHub actvaions workflows we can use environments to scope varibles and protection rules. Let's compare Azure DevOps pipeline environments to GitHub Actions workflow environments, differences regarding environment deployment approvals, in this post.

An environment can be configured for approvals as shown below.

Code for Creating a Multi Stage Workflow Structure with GitHub Actions - Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 3

 In the previous post "Create Multi Stage Pipeline Structure with GitHub Actions - The Layout - Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 2" we have dicussed the GitHub action workflow layout mapping to the Azure pipeline structure. The code for workflows can be structured as shown below for the pipeline requirement discussed in "Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 1". Note that we have seperated folder structure for job actions and step actions to organize the code properly in a manageable way. However, both are really composite actions in GitHub. Each action name is setup using a folder name as it must be action.yml or action.yaml for actions.

Create Multi Stage Workflow Structure with GitHub Actions - The Layout - Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 2

 In "Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 1" we have discussed the limitation of GitHub action workflows compared to Azure DevOps pipelines. Further, we have compared the features and possible mappings. In this post, let's try how we can create GitHub workflow structure to make it similar to Azure DevOps pipeline shown in "Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 1".

Lets now look at the a the outcome of GitHub workflow setup, and see how it maps to Azure pipeline structure above creating the below pipeline stages.

GitHub Workflow

Note that unlike below fully functional Azure pipeline here in GitHub workflow is only having the structure created only. No approval gates setup or actual steps of execution implemented. But structure is setup keeping the real working workflow in mind. The intialize stage in Azure pipeline publishes AKS manifest files as artifacts in same pipeline, to be used in pepeline jobs, without full repo checkout. However, this is intentionally skipped in GitHub workflow as it seems checkout in every job is required to get the actions and jobs to be executed in GitHub workflow.

Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 1

 Migrating from Azure DevOps to GitHub Actions is mostly about rethinking stages → jobs, and stage dependencies → job dependencies (needs) while keeping environments and deployment isolation intact. This is a bit challanging task as GitHub actions does not support independant varaible groups and environments as in Azure DevOps. In this post let's look at  how a classic multi-stage deployment flow can be represented cleanly in GitHub Actions.

The Source Azure DevOps pipline can be a single env deployment such as below.

Resolve "GraphQL: Resource not accessible by integration (addLabelsToLabelable)" in GitHub Actions While Updating an Issue Label

 GitHub action workflow can be setup to set a lable to any newly created issue, using below code. If we want to add a lable "triage" to a new issue once opened we can create below workflow.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

HHowever, you may see error "GraphQL: Resource not accessible by integration (addLabelsToLabelable)", when the workflow is executed. Let's see how we can resolve the issue in this post.

Dynamically Control Matrix of Jobs in GitHub Actions Based on Input Parameter Value

 We can use matrix in GitHub Actions to use a single defnition of job to create multiple jobs as described here in the documentation. Let's say we input the list of application names we want to build, as an input parameter to the action workflow, and need to have the ability to remove the items from the app list at the time of triggering it manually (run workflow). For example, we have 4 apps by default. However, when we need we should be able to build only one or two out of them using the same action workflow without having to change, the workflow defintion. In this post let's explore how we can achieve that with GitHub actions workflow, utilizing the matrix strategy, and dynamical setting the matrix value.

Avoid GitHub Action Workflow Code Duplication - Using Composite Actions to Create Reusable Templates

 Azure DevOps yaml files for piplines can be created as templates to avoid duplicating same set of tasks in multiple areas of the pipelines. For GitHub actions workflow, we have seen here in "Build and Unit Tests for .NET Apps with GitHub Actions" the same steps are repeated in both Windows and Linux, build and unit test run. The solution to avoid duplicating same steps in multiple jobs in a GitHub actions workflow is the usage of composite actions. Let's modify our workflow implemented in "Build and Unit Tests for .NET Apps with GitHub Actions" to use composite action to build and unit test, and reuse that in both Windows and Linux job.

Build and Unit Tests for .NET Apps with GitHub Actions

 Executing unit tests and viewing results in unit tests in a build pipeline is essential to keep high quality in an application deployment via any pipeline system. GitHub actions are the way forward to implement pipelines with repositories in GitHub. Let's explore how to run unit tests and view results in GitHub actions workflow.

Executing Azure CLI Commands with GitHub Actions

 Azure CLI is very powerful in deploying or managing Azure resources programmatically. Generally Azure CLI is used in cloud shell or in PowerShell scripts to deploy and manage resources in Azure. We can use Azure CLI commands in PowerShell script tasks with GitHub Actions to automate resource deployments to Azure. Let's explore the steps required.

Running Bicep IaC with GitHub Actions

 We have discussed deploying Bicep script using an Azure DevOps pipeline in a pervious post. We have explored having a approvals working with GitHub actions in the post "Manual Approval in GitHub Actions".  Let's utilize manual approvals and deploy Bicep script with GitHub actions.

Manual Approval in GitHub Actions

Before deploying to an environment with GitHub actions, you may need to implement a manual approval, especially in production environment. If it is a infrastructure deployment pipeline you may need even implement approvals for development environments to avoid unstable environments due to infrastructure failures. You may want to check what happens if you deploy Bicep or Terraform script, and then approve the execution to the target environment. Let's try to understand how to implement a manual approval step in GitHub actions

Resolving “Response status code does not indicate success: 400 (Bad Request)” in NuGet Packages Push to GitHub Packages with GitHub Actions

GitHub packages registry can be use to keep your organization NuGet packages privately or share them publicly. If you create a package in a private repo it would be private to the repo or for the organization if you use an organization. If you keep your packages in a public repo you can share it publicly. Ideally when you build reusable NuGet packages you would build and publish such packages with GitHub action workflow to your GitHub packages. While implementing this you may encounter “Response status code does not indicate success: 400 (Bad Request)” at the push of the package, due to special needs of GitHub based NuGet packages. Let’s look at them in this post.

Deploying .NET 5 Web App via GitHub Actions to Azure App Service

.NET 5 is released recently and now you can develop applications using .NET. While releasing .NET five with zero delays Azure App Services started supporting .NET 5 with Early Access. This is helping us to deploy our application code, without having to deply them as self-contained with framework. Meaning we can now deploy our .NET 5 Web Apps, APIs or Function Apps to Azure, just as published project binaries and things will start to run without any issues. In this post let’s look at how we can setup a quick build deployment pipeline deploying a .NET 5 web application to Azure using GitHub Actions.

How to Run GitHub Actions Step When a Failure Occurred in a Previous Step

GitHub Actions are the CI/CD workflow implementation tool built into GitHub repos. While using the GitHub Actions workflows you may want to execute a cleanup, or rollback or even a ticket(issue) creation task in a situation where a job step is failed. In Azure DevOps pipelines each task had control support to easy implantations of the run on failure need. Let’s look at what it is in Azure DevOps then understand how we can achieve same goals in GitHub actions workflow steps.