Deployment review not working for consecutive jobs cofnigured with environments

[omegazyadav]

Select Topic Area

Question

Body

Problem Statement:
Multiple state of approval required for jobs which are configured with Environment.

I have a 2 jobs in a workflow which uses environment i.e. dev/uat/prod.

name: 'Deploy Services'

on:
  workflow_call:

env:
  ENV_LABEL: ${{ github.event.inputs.ENV_LABEL }}

jobs:
  deploy-service1:
    environment:
      name: ${{ github.event.inputs.ENV_LABEL }}
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: comp/service

    steps:
      - name: Checkout the repo
        uses: actions/checkout@v3

      - name: Deploying Service 1
        run: |
          make deploy-service

  deploy-service2:
    needs: deploy-service1
    environment:
      name: ${{ github.event.inputs.ENV_LABEL }}
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: comp/service

    steps:
      - name: Checkout the repo
        uses: actions/checkout@v3

      - name: Deploying Service 2
        run: |
          make deploy-service 

Here, deploy-service2 needs deploy-service1 to be completed but both are configured with same environment. When the pipeline is triggered, some reviewers get deployment approval for deploy-service1 job and once they provide approval for the job, it works only for deploy-service1.

When deploy-service1 is completed, it again ask for the review for deploy-service2 which is annoying as reviewers has to involve for multiple stage of review for single workflow.

I am looking for some ways to bypass this approval so that reviewers don't have to involve for same workflow again and again. Any help would be appreciated. Thank you.

[54J4N]

To reduce the need for multiple deployment reviews in your GitHub Actions workflow, you can consolidate the deployment of Service 1 and Service 2 into a single job. This way, the approval for the environment applies to the entire deployment process, not just one part of it. Here's how you can adjust your workflow:

name: 'Deploy Services'

on:
  workflow_call:

env:
  ENV_LABEL: ${{ github.event.inputs.ENV_LABEL }}

jobs:
  deploy-services:
    environment:
      name: ${{ github.event.inputs.ENV_LABEL }}
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: comp/service

    steps:
      - name: Checkout the repo
        uses: actions/checkout@v3

      - name: Deploying Service 1
        run: 
          make deploy-service

      - name: Deploying Service 2
        run: 
          make deploy-service  
          ```
          
This configuration requires only one approval per environment, streamlining the review process.

[omegazyadav]

Hi @54J4N Thank you for your input on this. Consolidating the service1 and service2 job into single one would increase the deployment time(service1 and service2 are team dependent jobs) and now developer has to wait for almost double the time than that of earlier.

Also it doesn't look good if we mix 2 separate workflow into one as our use case is different i.e. deploy-service1 is a go based workflow while deploy-service2 is node based. Adjusting the existing workflow is a workaround instead we are looking for some approach to intercept the approval response on environment for deploy-service1 and automatically apply for rest of the jobs i.e. deploy-service2, deploy-service3 ...

[54J4N]

Hi @omegazyadav,

Thank you for your feedback and for clarifying the constraints regarding deployment time and the differences in technology stacks for your services. Based on your requirements to maintain separate workflows while minimizing the redundancy of approval requests, I suggest implementing a dynamic approach to control the approval process.
This approach ensures that after the initial approval for the first deployment job, subsequent jobs can bypass further approvals if the initial deployment is successful.

name: 'Deploy Services'

on:
  workflow_call:

env:
  ENV_LABEL: ${{ github.event.inputs.ENV_LABEL }}

jobs:
  setup:
    runs-on: ubuntu-latest
    outputs:
      approval_needed: ${{ steps.set_approval.outputs.approval }}
    steps:
      - name: Set Approval Requirement
        id: set_approval
        run: 
      
          echo "::set-output name=approval::true"

  deploy-service1:
    needs: setup
    environment:
      name: ${{ github.event.inputs.ENV_LABEL }}
      required: ${{ needs.setup.outputs.approval_needed }}
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: comp/service
    steps:
      - name: Checkout the repo
        uses: actions/checkout@v3
      - name: Deploying Service 1
        run: make deploy-service

  deploy-service2:
    needs: deploy-service1
    environment:
      name: ${{ github.event.inputs.ENV_LABEL }}
      required: false  #auto bypasses additional approvals
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: comp/service
    steps:
      - name: Checkout the repo
        uses: actions/checkout@v3
      - name: Deploying Service 2
        run: make deploy-service
        ```
       This  approach keeps your deployments separate but simplifies the review process, reducing the need for repeated manual interventions.  let me know omegazyadav
       

[omegazyadav]

Hi @54J4N, You are trying to pass output of one job to another and bypass the approval process but I don't think that would work. The environment context doesn't have required field so I am pretty sure this setup would end up in configuration error as workflow won't be valid.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬