Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign updocumentation issue w.r.t to 'chalice generate-pipeline' and python 3.8 #1412
Comments
|
I have read the documentation more closely and I think that that a good way forward is to use the 'chalice package' command to generate a terraform config and it works quite well. I have been able to create and destroy my environment several times this way. But I want to configure some more things. For example, I added my own main.tf file to create a VPC and terraform seems to do the right thing by making the lambda function inside this new VPC. My annoyance now seems to be the setting of certain parameters for terraform. For example, chalice correctly assumes that region should not be hardcoded in the 'aws' provider. But that forces 'terraform plan' and 'terraform apply' to ask this question on the command line. Ideally, to be able to run terraform without console input. I want to keep chalice.tf.json in source control along with my main.tf which further customizes the environment. Ideally, I should never have to hand edit or merge chalice.tf.json. I can add the region inside chalice.tf.json but I wish there was a way to override the provider settings from my main.tf file. That way, chalice.tf.json will always be a generated file which is only changed by chalice. |
|
I have made some more progress on this. Terraform cloud integrates very well with github actions. I have been able to trigger the formation of the infrastructure quite easily. At this point, maybe this issue becomes a feature request. What would be helpful is to have something like |
|
Awesome, thanks for the feedback. I like the idea of adding an FWIW, I've not seen https://github.com/marketplace/actions/chalice-extended-action before. It's not something we've created or maintain, but it does look interesting. |
The deployment pipeline generated from the ``generate-pipeline`` command hasn't been touched in several years. In looking over the code there's been notable changes in the underlying services we use for the deployment pipeline: * There's a new 0.2 version of the CodeBuild buildspec that has notable improvements from the 0.1 version buildspec. * The way that CodeBuild manages language images has changed. Rather than having separate codebuild images for each runtime, you can now specify the runtime you need in your codebuild spec file (leading to issues such as aws#1412). As a result you couldn't generate a deployment pipeline that worked with Python 3.8. * CloudFormation added support for ssm/ssm-secure/secretsmanager. While we can't use ssm-secure for the GitHub OAuth token, secretsmanager is supported so we can more securely store our token instead of requiring it as a template parameter. The output of `generate-pipeline` is in a grey area in terms of what to support for backwards compatibility. If the expectation is you can use the output `generate-pipeline` to successfully set up a deployment pipeline, then these changes are backwards compatible. However, the template parameters are changed as well as the CodeBuild image used which could negatively impact customers. As a result, I've decided to make this an opt-in change (for now). There's a new `--pipeline-version` parameter where specifying `v2` will get you the new features listed above. The default value is `v1` which will generate the same template as previous versions. The other benefit of making this opt-in is we can restrict which Python versions we support. The new CodeBuild images only support Python 3.7 and 3.8 so we can only support these new versions without requiring fallbacks for earlier python version (you can just use `v1` if you want to use older python versions). Note that there was a bugfix needed when configuring a GitHub repository as a source. This was fixed in the `v1` template as well as the `v2` template.
Even though I have used 'chalice deploy' successfully with python 3.8, 'chalice generate-pipeline' will not work because AWS CodeDeploy does not yet support python 3.8.
It would help if the docs mentioned this and maybe put a timeline for when CodeDeploy plans to add that support.
It would also help if there were instructions to set up a pipeline using github actions. I have found this: https://github.com/marketplace/actions/chalice-extended-action
But I am not sure if it is reliable and in heavy use.