Introduce completely separate chalice stages #264
Conversation
jamesls
requested review from
dstufft,
stealthycoin,
JordonPhillips and
kyleknap
chalice/awsclient.py
Outdated
| try: | ||
| self._client('apigateway').get_rest_api(restApiId=rest_api_id) | ||
| return True | ||
| except botocore.exceptions.ClientError as e: |
There was a problem hiding this comment.
I think you can use modeled exceptions for this one if you want. NotFoundException is modeled in api gateway's service model.
There was a problem hiding this comment.
Yeah I'll get these updated, there's a few places I'm catching ClientError that can be updated. I'll just need to bump the min botocore version to 1.5.0.
|
|
||
|
|
||
| class DeployedResources(object): | ||
| def __init__(self, backend, api_handler_arn, |
There was a problem hiding this comment.
That's a lot of arguments. Wonder if this can be simplified but seems to be in all practicality is a namedtuple. So I don't feel too strongly about needing to change it.
Codecov Report
@@ Coverage Diff @@
## package #264 +/- ##
===========================================
- Coverage 82.91% 82.33% -0.58%
===========================================
Files 17 17
Lines 1539 1585 +46
Branches 193 198 +5
===========================================
+ Hits 1276 1305 +29
- Misses 212 227 +15
- Partials 51 53 +2
Continue to review full report at Codecov.
|
This introduces a change to how stages work in chalice. Previously a "stage" in chalice corresponded to an API gateway stage. While this could theoretically work for lambda functions as well (via aliasing and function versions) it would not necessarily scale with other AWS resources. Now, chalice "stages" are entirely new sets of resources. For example, if I run: $ chalice deploy dev # Note 'dev' can be omitted, it's the default $ chalice deploy prod I will have two completely separate sets of API gateway rest APIs, Lambda functions, and IAM roles. To help track this, a ".chalice/deployed.json" is written on deploys that contains the deployed values per-stage. There's still some additional work remaining, primarily against upgrading from old versions to this new version. We should be warning or erroring out in that scenario, but that will be addressed as a separate commit. Additionally, the "chalice url/logs" command can be updated to use the ".chalice/deployed.json" file as well, but that will be added as a separate commit.
This was added in v1.5.0 of botocore so I've bumped the min version of botocore accordingly.
jamesls
force-pushed
the
separate-stages
branch
from
93aa095
to
6a13ad2
Compare
|
@jamesls - thanks for doing this! Chalice seemed promising, but was a non-starter unless it had full dev/prod/test environments. I'll check out the |
This introduces a change to how stages work in chalice.
Previously a "stage" in chalice corresponded to an API gateway
stage. While this could theoretically work for lambda functions
as well (via aliasing and function versions) it would not necessarily
scale with other AWS resources. Now, chalice "stages" are
entirely new sets of resources. For example, if I run:
I will have two completely separate sets of API gateway rest APIs,
Lambda functions, and IAM roles.
To help track this, a ".chalice/deployed.json" is written on deploys
that contains the deployed values per-stage.
There's still some additional work remaining, primarily against
upgrading from old versions to this new version. We should be warning
or erroring out in that scenario, but that will be addressed as a
separate commit.
Additionally, the "chalice url/logs" command can be updated to use
the ".chalice/deployed.json" file as well, but that will be added as
a separate commit.