How to "environmentalize" a workflow?

Code to Cloud GitHub Actions
#1

I’m trying to understand how you can “environmentalize” a Github actions workflow, that is, have a workflow use different values depending on the environment. Here is my use-case:

  • I have a manual workflow to deploy my application to an environment (development, qa, staging, production) which is specified via a workflow input.
  • The environments are hosted in AWS and AWS credentials a different for each environment.

Configuring an environment is as simple as this:

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID_DEVELOPMENT }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY_DEVELOPMENT }}
    aws-region: 'us-east-1'

My question is what is the best way to have my workflow ensure all environments will be configured.

I’ve done a bit of searching for this answer, but haven’t found anything. The only option I’ve seen so far is to use Github actions contexts which would result in my workflow having a step for each environment where i have an if expression to determine which step to actually run. Eg.

- name: Configure Dev AWS credentials
  if: ${{ github.event.inputs.env_to_promote_to === 'development' }}
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID_DEVELOPMENT }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY_DEVELOPMENT }}
    aws-region: 'us-east-1'

That seems like a really suboptimal solution since most of my *.yml file will be conditional steps to configure AWS.

This discussion seemed to offer a potential solution, but the syntax is such that I’m not sure how I’d use it.

1 Like
#2

The basic idea is to set the keys as environment secrets and then always use the same name. Then you can use your workflow_dispatch input as the name of the environment, and the right set of secrets will be made available to the workflow:

  jobs:
    deploy:
      environment: ${{ github.event.inputs.env_to_promote_to }}
      steps:
        # This secret is named `AWS_ACCESS_KEY_ID` in _every_ environment
        - run: ./do-something ${{ secrets.AWS_ACCESS_KEY_ID }}
#3

@cschleiden When you say “environment”, what are you referring to? Is there a concept of environments in Github or the secrets module (which I’m unfamiliar with) where you can use the same secret ID for different values?

#4

Yes, please see: Environments - GitHub Docs

And specifically this section: Environments - Secrets - GitHub Docs

#5

@cschleiden This appears to be exactly what I need. That said, my repos are private and my organization has GitHub Enterprise. I’m seeing some statements in the page you linked that I’m interpreting as conflicting and I’m unclear if, given my situation, environment secrets are an option.

In the purple box, it reads “Environments, environment protection rules, and environment secrets are available in public repositories for all products and in private repositories for GitHub Enterprise.” But then in the About environments section, it says “Environment protection rules and environment secrets are only available on public repositories.”

Are you able to say if environment secrets work for private repos with GitHub Enterprise?

#6

@mellis481 That appears to be a bug in our documentation :grimacing: We’ll get that fixed.

On an enterprise plan environments (and all associated features) are also available for private repositories.

1 Like
#7

@cschleiden I’m just now realizing that it appears the environment secrets are at the repository-level not organization-wide. Is that correct? If so, then it would appear this solution is not going to be satisfactory for me because the environment-based secrets I need go across numerous repositories in my organization.

#8

Yes, environment are repository scoped.

#9

@cschleiden are organization-level secrets on any roadmap?

1 Like