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.

Fix Keda Upgrade on AKS with Helm Fail Due to Field Ownership Conflicts

 AKS runs an internal mutating component called the admissionsenforcer (part of the AKS-managed "admissions enforcer" / addon-manager). After KEDA's ValidatingWebhookConfiguration (keda-admission) is created, AKS automatically injects a namespaceSelector into every webhook entry to exclude AKS control-plane / managed namespaces (so KEDA's webhooks never intercept system pods). When it does this, it takes Server-Side Apply (SSA) field ownership of those namespaceSelector fields under the field manager named admissionsenforcer. 

So after the first deploy:

• keda-admission webhook exists
• AKS has mutated .webhooks[*].namespaceSelector and now owns those fields

In the second deploy, the KEDA chart  tries to re-apply the same ValidatingWebhookConfiguration with the field manager helm. SSA detects that helm wants to set fields already owned by admissionsenforcer → field ownership conflict:

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.

Monitor and Profile Memory Usage in a Running .NET Linux Pod in AKS

 Sometimes we need to understand what causes high memeory usages or if any memory leaks in our application setup. When we see pod memeory is not reclaimed for longer intervals, analyzing the usage and diagnosing where exactly is the problem would be useful to fix the issues. Such profiling of memeory, we should be able to do in a running container inside a pod to understand the full details. Let's look at step by step how to profile and monitor memory usage in a .NET app running in a Linux pod in AKS.

Expectaion is to have the ability to monitor live counters as shown below.