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

future state of environments #343

Closed
ITProKyle opened this issue May 26, 2020 · 2 comments · Fixed by #586
Closed

future state of environments #343

ITProKyle opened this issue May 26, 2020 · 2 comments · Fixed by #586
Labels
feature Request or pull request for a new feature

Comments

@ITProKyle
Copy link
Contributor

In working on #333, there was some brief discussion around how this functionality should be enabled in the config file. This lead to the idea of using something along the lines of future to opt-in to using behavior that we intend to make standard in the next major release.

This leaves us room to continue supporting legacy features of environments while preparing for the release of Runway v2.0 and allowing users to begin explicitly using the new syntax early.

Here we will outline the syntax and behaviors being removed and those being made standard.

Usage Being Discontinued in v2.0

Passing values to modules (superseded by parameters)

environments:
  <env_name>:
    key: val

v2.0

TBD with some behavior described in #333

@ITProKyle ITProKyle added the feature Request or pull request for a new feature label May 26, 2020
@ITProKyle
Copy link
Contributor Author

ITProKyle commented May 26, 2020

Proposed Verbose Syntax

It could be easier to parse and read environments if we make the definitions more verbose by turning them into objects instead of using a string

environments:
  old-list:
    - <account-id>/<region>  # could also be only <account-id> or <region>
  new-list:
    - account_id: <account-id>
      region: <region>
  # we can also support the use of alias instead of account id
    - account_alias: <account-alias>

This could also remove the need for account_id and account_alias module options. We could take it one step further and move assume_role into the environment definition to tie a role arn or multiple role arns to an environment.

Other Syntax Options

# this would apply to all environment names
# best used when a lookup resolves to this value
environments:
  account_id: <account-id>
  region: <region>

We could also move the definitions of environments to the top level or another file and reference them by name on the deployments/modules

environments:  # key could be different
  example:
    - account_id: <account-id>
      region: <region>

deployments:
  - environments:  # key could be different
      - example
    modules:
      - sampleapp.cfn

@ITProKyle
Copy link
Contributor Author

Proposed Opt-in

future:  # top-level config option
  environments: true

@ITProKyle ITProKyle linked a pull request May 3, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Request or pull request for a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant