Multiple `production_environment`

[mnaser]

Describe the Issue

I've got a scenario where I have multiple production environments all managed in the same environment.

There doesn't seem to be a way to have multiple production environments managed within the same repository? While there are ways to have multiple environments, it feels that the production_environment is meant for the main one?

Does it make sense to just set production_environment to something obscure if you have multiple production environments?

Action Configuration

No response

Relevant Actions Log Output

No response

Extra Information

No response

[GrantBirki]

@mnaser have you read the little bitsof docs that float around about this variable here?

This variable effectively is just used to tell the GitHub API when a deployment starts if it is the "production" env or not.

You can read more about this variable in the official GitHub docs as well (see screenshot)

The majority of the use cases I have seen for this value is when users have a unique env name and they need to overwrite it. For example, if you call production something else like prd, or prod then you would want to use this variable.

That being said, I have actually not come across this use case that is yours yet. Please do some tinkering, swap around this variable, set it to something obscure, etc. Let me know the results here and how it works for you! If it doesn't work out well, I'll look into creating a solution. Thanks! 🙇

[mnaser]

@GrantBirki thanks!! i'm playing around with it, I actually do not have a single "production" environment in this case, so I left it set to production and trying to play with it on how it will end up working.

So far, so good, I haven't seen anything wild, the only thing is that if someone does .deploy with no target, it will deploy try to production and inevitably fail because that 'environment' doesn't exist... i think the nice thing I'm thinking about would be if there's a way to have a bool that says "enforce_env" or something like that, so users MUST have an environment in their .deploy command

[GrantBirki]

@mnaser Would you be able to copy / paste or link to your branch-deploy configuration? I'm curious about what settings you have.

[mnaser]

@mnaser Would you be able to copy / paste or link to your branch-deploy configuration? I'm curious about what settings you have.

I can't link it because it's a private repository that we use to deploy, but...

name: branch-deploy

on:
  issue_comment:
    types: [created]

permissions:
  checks: read
  contents: write
  deployments: write
  id-token: write
  pull-requests: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ github.event.issue.pull_request }}

    steps:
      - uses: github/branch-deploy@v7.5.2
        id: branch-deploy
        with:
          reaction: rocket
          sticky_locks: true
          environment_targets: |-
            beep
            boop
          environment_urls: |-
            beep|https://dashboard.openstack.beep.local
            boop|https://dashboard.openstack.boop.local

      - uses: actions/checkout@v4
        if: ${{ steps.branch-deploy.outputs.continue == 'true' }}
        with:
          ref: ${{ steps.branch-deploy.outputs.ref }}

      - name: Deploy environment
        uses: ./.github/actions/deploy
        if: ${{ steps.branch-deploy.outputs.continue == 'true' && steps.branch-deploy.outputs.noop != 'true' }}
        with:
          environment: "${{ steps.branch-deploy.outputs.environment }}"
          tailscale-authkey: ${{ secrets.TAILSCALE_AUTHKEY }}
          teleport-auth-token: ${{ secrets.TELEPORT_AUTH_TOKEN }}

So in my case, I can only deploy to beep or boop. I have no production and all my environments are well... production :)

[GrantBirki]

I think the solution here is to have production_environment become production_environments (with an s). Then this value would accept a comma separated list of strings -> beep,boop. The branch-deploy Action would then mark beep and boop as production environments when making deployment requests.

This would fix the problem at hand for you and likely all other users in the future.

The only issue is that this would be a pretty significant breaking change as the input variable would change values by adding that trailing "s". However, I think we can show deprecation messages in the logs and push a v8.0.0 tag.

[GrantBirki]

@mnaser Please go ahead and give the pre-release tag v8.0.0 a go and let me know how it works! 🚀

[mnaser]

@GrantBirki worked beautifully, thank you.