v1.9.1

Support restoring to a specific time @ericluria (#216)

what

• Adds restore_to_time as an attribute of the restore_to_point_in_time parameter, allowing to restore to a specific datetime rather than the latest restorable time.

why

• Fixes missing functionality that's supported by the aws_rds_cluster resource.

references

• Closes #163

questions

I noticed while making this PR that source_cluster_identifier defaults to "120m", which looks like an inadvertent copy-and-paste from another parameter. In the aws_rds_cluster resource, this parameter is required, so it doesn't make sense to have a default anyway. Would you recommend leaving this parameter as-is, or should we fix it?

edit: fixed as part of this PR

🤖 Automatic Updates

Update release workflow to allow pull-requests: write @osterman (#214)

what

• Update workflow (.github/workflows/release.yaml) to have permission to comment on PR

why

• So we can support commenting on PRs with a link to the release

Update GitHub Workflows to use shared workflows from '.github' repo @osterman (#212)

what

• Update workflows (.github/workflows) to use shared workflows from .github repo

why

• Reduce nested levels of reusable workflows

Update GitHub Workflows to Fix ReviewDog TFLint Action @osterman (#211)

what

• Update workflows (.github/workflows) to add issue: write permission needed by ReviewDog tflint action

why

• The ReviewDog action will comment with line-level suggestions based on linting failures

Update GitHub workflows @osterman (#210)

what

• Update workflows (.github/workflows/settings.yaml)

why

• Support new readme generation workflow.
• Generate banners

Use GitHub Action Workflows from `cloudposse/.github` Repo @osterman (#207)

what

• Install latest GitHub Action Workflows

why

• Use shared workflows from cldouposse/.github repository
• Simplify management of workflows from centralized hub of configuration