A custom resource for managing service catalog products
To use this custom resource add the following snippet to a cloudformation template:
UpdateProductVersions:
Type: Custom::ProductProvider
Properties:
ServiceToken: !ImportValue
'Fn::Sub': '${AWS::Region}-cfn-cr-sc-product-provider-UpdateProvisioningArtifactFunctionArn'
ProductId: !Ref MyProductId
ProvisioningArtifactActive: "True"
ProvisioningArtifactGuidance: "DEPRECATED"
ProvisioningArtifactAction: "ALL_EXCEPT_LATEST"
Properties:
- ProductId [required] - The service catalog product ID (i.e. prod-iugafjcy2eyro).
- ProvisioningArtifactActive - Indicates whether the product version is active. Inactive provisioning artifacts are invisible to end users. End users cannot launch or update a provisioned product from an inactive provisioning artifact. Allowed values are True|False. Default is "True"
- ProvisioningArtifactGuidance - The value to apply to the product version guidance. Allowed values are DEFAULT|DEPRECATED. Default value is "DEFAULT"
- ProvisioningArtifactAction - ALL to apply to all artifacts, ALL_EXCEPT_LATEST to apply to all except latest artifact. Default value is "ALL"
More info about properties can be found in the update_provisioning_artifact API
Contributions are welcome.
Install the following applications:
Run pipenv install --dev
to install both production and development
requirements, and pipenv shell
to activate the virtual environment. For more
information see the pipenv docs.
After activating the virtual environment, run pre-commit install
to install
the pre-commit git hook.
First, make any needed updates to the base requirements in Pipfile
, then use
pipenv
to regenerate both Pipfile.lock
and requirements.txt
.
$ pipenv update --dev
We use pipenv
to control versions in testing, but sam
relies on
requirements.txt
directly for building the lambda artifact, so we dynamically
generate requirements.txt
from Pipfile.lock
before building the artifact.
The file must be created in the CodeUri
directory specified in
template.yaml
.
$ pipenv requirements > requirements.txt
Additionally, pre-commit
manages its own requirements.
$ pre-commit autoupdate
Use a Lambda-like docker container to build the Lambda artifact
$ sam build --use-container
Tests are defined in the tests
folder in this project, and dependencies are
managed with pipenv
. Install the development dependencies and run the tests
using coverage
.
$ pipenv run coverage run -m pytest tests/ -svv
Automated testing will upload coverage results to Coveralls.
Running integration tests requires docker
sam local invoke UpdateProvisioningArtifactFunction --event events/event.json
Deployments are sent to the
Sage cloudformation repository
which requires permissions to upload to Sage
bootstrap-awss3cloudformationbucket-19qromfd235z9
and
essentials-awss3lambdaartifactsbucket-x29ftznj6pqw
buckets.
sam package --template-file .aws-sam/build/template.yaml \
--s3-bucket essentials-awss3lambdaartifactsbucket-x29ftznj6pqw \
--output-template-file .aws-sam/build/cfn-cr-sc-product-provider.yaml
aws s3 cp .aws-sam/build/cfn-cr-sc-product-provider.yaml s3://bootstrap-awss3cloudformationbucket-19qromfd235z9/cfn-cr-sc-product-provider/master/
Create the following sceptre file config/prod/cfn-cr-sc-product-provider.yaml
template_path: "remote/cfn-cr-sc-product-provider.yaml"
stack_name: "cfn-cr-sc-product-provider"
stack_tags:
Department: "Platform"
Project: "Infrastructure"
OwnerEmail: "[email protected]"
hooks:
before_launch:
- !cmd "curl https://bootstrap-awss3cloudformationbucket-19qromfd235z9.s3.amazonaws.com/cfn-cr-sc-product-provider/master/cfn-cr-sc-product-provider.yaml --create-dirs -o templates/remote/cfn-cr-sc-product-provider.yaml"
Install the lambda using sceptre:
sceptre --var "profile=my-profile" --var "region=us-east-1" launch prod/cfn-cr-sc-product-provider.yaml
Steps to deploy from AWS console.
- Login to AWS
- Access the serverless application repository -> Available Applications
- Select application to install
- Enter Application settings
- Click Deploy
We have setup our CI to automate a releases. To kick off the process just create a tag (i.e 0.0.1) and push to the repo. The tag must be the same number as the current version in template.yaml. Our CI will do the work of deploying and publishing the lambda.