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.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.
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.
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.
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.
We have dicussed how to "Copy Variable Groups Across Team Projects in Azure DevOps" in a previous post. In similar way we can use a scrip with Azure DevOps REST API to copy environment defined in Azure DevOps across team projects.
We have discueed, that we have to use an environment variable to handle input parameter default values, if we are using trigger for workflow on push in the post "Setting Workflow Environment Variable Based on Input Parameter in GitHub Actions - on workflow_dispatch and Use a Default Value on push". If we have to pass on the input paramter value from a workflow to a reusable workflow, it does not work as expected and it is a limitation of reusable workflows as explained in here. Let's try to understand with an example how to pass an env variable to a reusable workflow.
GitHub actions workflows support input only on manual trigger workflow_dispatch. What if we need to use default value in other triggers such as on push and use input parameter in case of manual trigger workflow_dispatch? Let's explore our options with an example.
