Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple production_environment #208

Closed
mnaser opened this issue Sep 15, 2023 · 7 comments · Fixed by #209
Closed

Multiple production_environment #208

mnaser opened this issue Sep 15, 2023 · 7 comments · Fixed by #209
Assignees
Labels
enhancement New feature or request

Comments

@mnaser
Copy link

mnaser commented Sep 15, 2023

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

@mnaser mnaser added the bug Something isn't working label Sep 15, 2023
@GrantBirki
Copy link
Member

@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)

Screenshot 2023-09-15 at 7 30 15 AM

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
Copy link
Author

mnaser commented Sep 15, 2023

@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
Copy link
Member

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

@mnaser
Copy link
Author

mnaser commented Sep 15, 2023

@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/[email protected]
        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
Copy link
Member

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 GrantBirki self-assigned this Sep 15, 2023
@GrantBirki GrantBirki added enhancement New feature or request and removed bug Something isn't working labels Sep 15, 2023
@GrantBirki
Copy link
Member

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

@mnaser
Copy link
Author

mnaser commented Sep 15, 2023

@GrantBirki worked beautifully, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants