Would you like to take a look at a human-readable changelog of AWS CloudFormation resource offerings? Take a look here: aws-cfn-resource-specs/CHANGELOG.md
It is a result of updates AWS does to their AWS CloudFormation Resource Specification files. The repository audits AWS CloudFormation schema daily to see:
- What AWS services are supported by CloudFormation
- What services are supported in what regions in CloudFormation
- What resources have since been renamed or removed after their initial release; the changelogs currently reference a type as removed only, as it is difficult to know when a removal was actually a renaming
- What documentation links are broken within the CFN Resource Spec files provided by AWS
- What resources, if any, are mentioned in other specification files outside of
us-east-1. Certain tools have been dependent on the
us-east-1spec file as the master source file, though my tooling has discovered errors where certain supported resources were not included (when they were supported)
Both machine-readable and human-readable changelogs are generated after a new specification version is released by the AWS CloudFormation team.
When it comes to a centralized changelog of what AWS services are supported by AWS CloudFormation, and in what regions, the official documentation is lacking.
Right now, one can take a look at the AWS CloudFormation User Guide Release History page for a description of new and updated resources. That, and keep an eye out for updates dropped in AWS blog posts.
What's missing from that release history?
- Information about what regions are supporting each new resource
- What regions newly support existing resources
- What resources have since been renamed or removed
- The version number of an associated CloudFormation resource specification
The official release history shows the following, in regard to the last chunk of December 2019:
Duplicate: A column that includes whether this resource already was added to the release history, and is somehow reappearing again as a new resource. This seems to be a bug, making it a little confusing.
|ResourceType||New or Updated?||Date||Duplicate||Problem|
|AWS::WAFv2::WebACLAssociation||New||12/19/2019||Doesn't exist anywhere in documentation, and doesn't exist in
Some column information:
- Added Region Count: How many new regions is this now available in?
- Release History? Is this documented in the AWS Release History?
- Blog?: Is there a blog article referencing this? If so, link provided.
- Details:: Misc. such as a link to the list of regions it is available in
|Name||Type||New?||Added Region Count||Release History?||Blog?||Details|
|AWS::DLM::LifecyclePolicy.CrossRegionCopyRetainRule||Property||Yes||13||No||No||Docs page says "Currently not supported by CloudFormation."|
|AWS::DLM::LifecyclePolicy.CrossRegionCopyRule||Property||Yes||13||No||No||Docs page says "Currently not supported by CloudFormation."|
A changelog file, such as this generated MarkDown file for v10.x specifications, can be automated to try and include much of this information.
Blog links would take a lot of time and experimenting to try and look for and include in something auto-generated, so I wouldn't try it. Unless AWS does something interesting in the future where related blog posts are referenced by AWS CFN user guide docs or vice-versa? If so, that would provide a simplified path for including blog links in changelogs.
My changelog is currently missing when new property options are appearing such as
MaxAllocatedStorage being added to
AWS::RDS::DBInstance. Once this is supported, the GitHub repo will be a great launching point for looking into what's new.
There are some other problems at the moment, which I've opened issues for:
- Need to split the monolithic workflow into separate workflows, in order to prevent run steps breaking due to AWS rate-limiting documentation scraping (Issue #28)
- I want to create a docker container for testing GitHub Action run steps, otherwise I am stuck iterating against live GitHub Actions to ensure I'm not breaking a workflow. This slows down development until this is done (Issue #9)
- Use the GitHub Releases API to automatically (Issue #16):
- Label the latest release as Latest release
- Duplicate the changelog Markdown into the newest GitHub Release
- As long as the above two are not automated, this has to be manually done.
- And others...
I think it would be a great idea to create some automation around a Twitter account, and potentially an email newsletter, that sends out notifications of new releases.
At the moment, it would simply be a matter of adding one extra run step to GitHub Actions for each of those.
NOTE: To get an in-depth look at the history of this project, take a look at the following previous blog posts:
Originally published at https://icanteven.io on January 4th, 2020