Using GitHub Actions workflow to generate another GitHub Actions workflow

As everyone in the company has access to GitHub, Github already have access to all the resources being deployed. It is a good idea to utilise GitHub action workflow to operate daily BAU operations. for example:

• Restarting applications
• Shutdown/Start databases
• Deploy/Un-deploy resource on Cloud

As mentioned in the GitHub:

https://github.blog/changelog/2021-11-10-github-actions-input-types-for-manual-workflows/

You can now specify input types for manually triggered workflows allowing you to provide a better experience to users of your workflow. In addition to the default string type, we now support choice, boolean, and environments.

Here is a corrected version of your text:

In my case, I developed a workflow for a Service Desk engineer to restart AWS EKS deployments. The Service Desk engineer can simply run a GitHub Actions workflow to restart deployments on our AWS EKS platform without using the kubectl command like the following:

kubectl rollout restart deployment hello-world1 -n [namespace]

• First version of the “EKS-deployments restaror” workflow:

However, the Service Desk engineer still needs to enter information about the EKS deployments, such as environments and namespaces, as they don’t have access to the kubectl command-line environments. This creates a 'chicken and egg' issue.

Therefore, I need to develop the workflow using choices so the engineer can simply select the deployments they want to restart.

• Second version of the “EKS-deployment-restartor” workflow:

Now, the engineer can simply select the environments, namespaces, and deployment name from the drop-down list

How?

As deployments on the EKS platform change every minute, it is NOT a good idea to hardcode this drop-down list. This drop-down list needs to be dynamically updated when deployments change in different environments of the EKS platform.

I developed a “generator” workflow to dynamically generate this “EKS-deployments-restartor” workflow.

1. The “generator” workflow looks up all the EKS deployments information across different environments (test, QA, prod, etc.) and produces an options list as follows:

          - test | private | helloworld-1-deployment
          - test | private | helloworld-2-deployment
          - test | private | helloworld-3-deployment
          - test | private | helloworld-4-deployment
          - prod | private | helloworld-1-deployment
          - prod | private | helloworld-2-deployment
          - prod | private | helloworld-3-deployment
          - prod | private | helloworld-4-deployment

Essentially, running the ‘kubectl get deployments’ command in all environments.

2. The “generator” workflow embeds this option list in the “EKS-deployment-restartor” template.

template-eks-deployment-restartor.yaml:

name: Generated-pipeline - Selected deployment restarter
on:
  workflow_dispatch:
    inputs:
      deployment_selection:
        description: 'Please select the deploy you want to restart. ENV | NAMESPACE | DEPLOYMENT'
        required: true
        type: choice
        $REPLACE_ME_CONTENT

I use envsubst command to replace the REPLACE_ME_CONTENT with the option list created in step 1 to produce the drop-down list

envsubst '$REPLACE_ME_CONTENT' < template-eks-deployment-restartor.yaml > eks-deployment-restartor.yaml

output:

name: Generated-pipeline - Selected deployment restarter
on:
  workflow_dispatch:
    inputs:
      deployment_selection:
        description: 'Please select the deploy you want to restart. ENV | NAMESPACE | DEPLOYMENT'
        required: true
        type: choice
        options:
          - test | private | helloworld-1-deployment
          - test | private | helloworld-2-deployment
          - test | private | helloworld-3-deployment
          - test | private | helloworld-4-deployment
          - prod | private | helloworld-1-deployment
          - prod | private | helloworld-2-deployment
          - prod | private | helloworld-3-deployment
          - prod | private | helloworld-4-deployment

3. The “generator” workflow creates a pull request to update this “generated-EKS-deployments-restartor “workflow.

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v5
        with:
          token: ${{ env.GITHUB_USER_TOKEN }}
          add-paths: |
            .github/workflows/
          commit-message: "Update option list in generated-eks-deployment-restartor.yaml."
          title: "New update on generated-eks-deployment-restartor.yaml"
          body: "Update option list in generated-eks-deployment-restartor. Please perform review."
          labels: workflows
          branch: create-pull-request/patch-${{ github.sha }}
          team-reviewers: devops
          base: main

Once the pull request is approved and merged, the newly generated EKS-deployments-restartor workflow which reflects the current deployment situation in all environments.

We can also chain this 'generator' workflow with the application deployment workflow, so every time the application get deployed, it will also generate the EKS-deployments-restartor workflow again.