Conversation
| # CIRRUS_PAYLOAD_BUCKET and CIRRUS_PAYLOAD_ROOT_PREFIX are special variables | ||
| # that you do not need to provide literal values for; they are automatically | ||
| # replaced with the Cirrus payload bucket's name (NOT the ARN) and the root | ||
| # prefix for payloads, respectively, for your target deployment environment | ||
| # at runtime. |
There was a problem hiding this comment.
We could consider restricting these resources to just the payload bucket prefix, but that would not be backwards compatible. Users could set the prefix to an empty string to keep the current behavior, but leaving it set that way when upgrading to cirrus v2 that would defeat some of the point of the reorg.
I think I'd probably suggest leaving the permissions as-is, and restricting them in the future once we have everything on >=v2.
| Each interpolation sequence's lookup value must have an associated entry in this map. If not, Terraform will raise a runtime error. | ||
|
|
||
| Since the Cirrus data and payload buckets will always be different for each environment, there are two predefined variables `CIRRUS_DATA_BUCKET` and `CIRRUS_PAYLOAD_BUCKET` that can be used to automatically reference these bucket names in your task definition YAML. You don't need to add entries to this variable for these. | ||
| Since the Cirrus data and payload buckets will always be different for each environment, there are predefined variables `CIRRUS_DATA_BUCKET`, `CIRRUS_PAYLOAD_BUCKET`, and `CIRRUS_PAYLOAD_ROOT_PREFIX` that can be used to automatically reference these values in your task definition YAML. You don't need to add entries to this variable for these. |
There was a problem hiding this comment.
This statement is not totally true: the v2 reorg opens up the possibility of using one payload bucket across multiple deployments. I don't think it is worth capturing that here, but I figured I'd point this out in case someone else feels this needs to be revised.
|
I authored this PR as a draft because I expected it had a dependency on cutting a cirrus v2 release. But it ended up backwards compatible, so I think it can be merged any time. |
|
Looks good, and good catch on the |
|
@KayakinCoder should I bump the cirrus version default to 2.0.0 now that it has been released? I tested with v2.0.0 and python 3.14 and everything looked good. |
2 participants
Related issue(s)
Proposed Changes
cirrus)payload_tmp_lifecycle_expiration_daysvar is set to something other than0deploy_log_archive=falseby ensuringaws_flow_logresource is not created when that setting isfalseTesting
This change was validated by the following observations:
CIRRUS_PAYLOAD_ROOT_PREFIXCIRRUS_PAYLOAD_ROOT_PREFIXdeploy_log_archive=falseChecklist
General
If releasing a new version
If migration step(s) might be required
I have added any migration steps to MIGRATION.mdNo migration steps are required, this is a backwards-compatible change due to the default values.