-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Add --stage argument to chalice commands #270
Conversation
This is used to track when major features are introduced in the config file. Version is missing in existing config files so it will be assumed to be 1.0, hence the starting value of "2.0" in this commit.
This refactoring makes it easier to write CLI tests for all the various commands.
Remove all references to a plain "stage_name". Stage names are now explicit. Either you mean "API Gateway stage name" or "chalice stage name".
This allows for some configuratio to be specified as a top level key in .chalice/config.json as well as a chalice stage specific value. Now that chalice stages are completely separate sets of resources, you can have different config values per stage.
The "chalice deploy <stage>" is deprecated. Instead, I've added two options in its place: * --api-gateway-stage, for users that want the existing behavior * --stage, for the new stage behavior which creates an entirely separate set of AWS resources. I've also added a deprecation warning if you specify a positional stage as well as param validation if you specify both the api gateway stage as well as the positional stage param. As part of this commit I've also updated the remaining commands that need to be stage aware: * package * url * generate-sdk * logs For each of these commands I've added a "--stage" option that uses the deployed values JSON file to look up the appropriate stage values.
chalice/cli/factory.py
Outdated
exception = Exception( | ||
"Unable to import your app.py file: %s" % e | ||
) | ||
# exception.exit_code = 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Old code I need to update. This code was originally from the cli init.py which used click exceptions to propagate exit codes.
chalice/config.py
Outdated
] | ||
def _chain_lookup(self, name, varies_per_chalice_stage=False): | ||
# type: (str, bool) -> Any | ||
all_dicts = [self._user_provided_params] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all_dicts is probably not the best name considering that another dict is added to it if varies_per_chalice_stage
is true. How bout something like search_dicts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
Codecov Report
@@ Coverage Diff @@
## package #270 +/- ##
===========================================
+ Coverage 83.98% 85.75% +1.77%
===========================================
Files 17 17
Lines 1592 1664 +72
Branches 196 201 +5
===========================================
+ Hits 1337 1427 +90
+ Misses 202 184 -18
Partials 53 53
Continue to review full report at Codecov.
|
chalice/cli/__init__.py
Outdated
deprecated_api_gateway_stage is not None: | ||
raise _create_deprecated_stage_error(api_gateway_stage, | ||
deprecated_api_gateway_stage) | ||
if api_gateway_stage is None and deprecated_api_gateway_stage is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this just be deprecated_api_gateway_stage is not None
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated, that was before adding the mutually exclusive part validation so the first clause isn't needed anymore.
chalice/cli/factory.py
Outdated
"Are you sure this is a chalice project?") | ||
app_obj = self.load_chalice_app() | ||
user_provided_params['chalice_app'] = app_obj | ||
if autogen_policy is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would autogen_policy be None
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm double checking on this, but I think this code is no longer relevant.
The idea a while back was to toggle between three states: not set, true, and false. This specific check was to check if the user explicitly set a true/false value and if so then add it to the dict of user provided params. The "not set" was needed because of config precedence. If this option was not set, then move on to the next dict in the _chain_lookup
of the Config
obj.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you could never set autogen_policy from the config file, only via the CLI.
I think the policy management and configuration could use a refresh. This would be a fairly large change (I think) so I'll address this in a separate PR.
Quicker feedback cycles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just mainly small questions and comments
|
||
def _warn_pending_removal(deprecated_stage): | ||
# type: (str) -> None | ||
click.echo("You've specified a deploy command of the form " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be to stderr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. I updated all the error messages to print to stderr.
chalice/cli/__init__.py
Outdated
@@ -201,11 +218,17 @@ def deploy(ctx, autogen_policy, profile, stage): | |||
@click.option('--include-lambda-messages/--no-include-lambda-messages', | |||
default=False, | |||
help='Controls whether or not lambda log messages are included.') | |||
@click.option('--stage', default='dev') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are users able to set the default for stage to override dev
as the default? If so how does that happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not right now. I'm hesitant to allow people to change the default to something like "prod". I'd prefer if you're deploying from a script you have to run --stage prod
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to be explicit, especially for debugging purposes.
chalice/cli/__init__.py
Outdated
"region value in our ~/.aws/config file.") | ||
return 2 | ||
except Exception as e: | ||
click.echo(str(e)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want to print this to stderr as well.
the config.environment_variables would be:: | ||
|
||
{"TABLE": "foo", "S3BUCKET": "devbucket"} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And so prod
would be?
{"TABLE": "prodtable", "S3BUCKET": "prodbucket"}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I updated the docs.
chalice/config.py
Outdated
] | ||
def _chain_lookup(self, name, varies_per_chalice_stage=False): | ||
# type: (str, bool) -> Any | ||
all_dicts = [self._user_provided_params] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah or cfg_dicts_chain
?
chalice/config.py
Outdated
def __init__(self, | ||
chalice_stage='dev', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a lot of hardcoded default dev
values. Wonder if it makes sense to have it be a constant to import or required instead of optional in case it ever needs to be updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created a constants.py
and moved a few of the constants over to that module.
tests/functional/cli/test_factory.py
Outdated
assert logging.getLogger('').level == logging.DEBUG | ||
|
||
|
||
def test_can_create_botocoreo_session_cli_factory(clifactory): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo botocoreo --> botocore
chalice/cli/__init__.py
Outdated
# This is the version that's written to the config file | ||
# on a `chalice new-project`. It's also how chalice is able | ||
# to know when to warn you when changing behavior is introduced. | ||
CONFIG_VERSION = '2.0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should maybe throw errors if we encounter a config version higher than that version of the chalice can support
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable, I'll update.
Removes hardcoded stage name of dev throughout the code and consolidates to a single location.
@kyleknap I believe all the feedback's been incorporated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I like the addition of the constants
module.
Before it would just print the top level file where the error occurs. Now it tries to reconstruct the error message you'd see if you let a syntaxerror propagate. This should help in troubleshooting.
Cool, also @stealthycoin I improved the error messages on import errors:
|
Rebased and merged in 76bd8e1 |
This pr builds on #264
to provide a consistent CLI experience when working with chalice stages.
There's several changes in this PR.
First, the code now clearly indicates whether we mean "chalice stage", which is
a completely separate collection of AWS resources, or an "API Gateway stage"
which is a specific configuration within a chalice stage (it's essentially the
URL prefix to use for your REST API for now).
chalice_stage_name
isgenerally used when we mean a chalice stage and
api_gateway_stage
is usedwhen we mean the latter, and with the exception of the actual CLI option
(
--stage
) every existing reference to a "stage" has been renamed to oneof those two values.
Next, I've deprecated the form "chalice deploy ". You now get an error
message if you use this form which instructs you use to use
--api-gateway-stage
:To get the new stage functionality introduced in #264 you need to use
chalice deploy --stage prod
.And finally, I've added a
--stage
option to the remaining set of chalicecommands that should be stage specific:
All of these commands have also been updated to pull the deployed values
from the
.chalice/deployed.json
file instead of trying to query it usingthe SDK as it was doing previously.