Amazon Web Services Question posted in
The official Amazon Web Services documentation can be found here.

Amazon web services – Github Actions to only apply the review position for specific jobs in a workflow

I am new to GitHub actions. I use it to deploy to an AWS account, a lambda application committed to a GitHub repository. Currently, I am using this workflow below so that only a pull request that is merged and closed will trigger the workflow. This is a dotnet application which requires a build step.

name: Deploying Lambda

on:
  pull_request:
    types: [closed]
    branches:
      - 'dev'

jobs:

  build-latest:
    runs-on: ubuntu-latest
    environment: DEV

    steps:
      # ... existing steps

  unit-tests-and-cdknag-execution:
    needs: get-latest-and-build
    runs-on: ubuntu-latest
    environment: DEV

    steps:
      # ... existing steps

  deploy-build:
    needs: unit-tests-execution
    runs-on: ubuntu-latest
    environment: DEV


    steps:
      # ... existing steps

I don’t want the review happening at every job. It should only happen for the deploy-build job. The GitHub console doesn’t allow me to specify which job the approval should be asked for. When I set up the environment for requiring approval, it does it automatically for all jobs in the workflow. Is there a way around this?

Tags:

2

Answers


  1. 0

    Remove

    environment; DEV

    from all other jobs. It should only be set on the deploy-build job.

    Login or Signup to reply.
  2. 0

    I don’t believe you can access Environment-specific Variables/Secrets without declaring the env: in a job, ie vars.myVar and secrets.mySecret:

    Secrets stored in an environment are only available to workflow jobs that reference the environment.

    This is different from environment variables, ie env.myVar, which are subject to the typical scope rules.

    Once you declare an env: in a job, you get access to the vars and secrets, and you are also subject to the protection rules, if any, on that environment. So you’ll get an approval gate anywhere you declare the Env. There’s no way around that; and they can only be declared at the Job level, not the Step level. My impression is that is to protect the secrets from being sent to a Runner, and potentially exposed, without approval.

    What do you need the environment vars/secrets for in the non-approval-needed jobs? Can they be set as standard env vars? Do they differ between Environments? Can you set them globally? Can all of the steps that need the vars be done in a single job?

    Ultimately, consider the structure of your workflow and how it might be massaged to fit better into the constraints.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search