We use the AWS Account feature of Octopus to store the api/key secret for accessing AWS resources. However we are required to rotate those values periodically. That works smoothly for new and manual deployments of existing releases. When the release deploys it always grabs the current key/secret. There is no need to update the release’s variable snapshot. (all this is good)
However, when an auto deploy for an existing release is triggered it does NOT retrieve the current AWS key/secret values. This is a significant problem for our AWS projects that have autoscaling enabled. The only work around we’ve found is to redeploy all releases that use the AWS variable (and have triggers) after rotating the keys. We don’t have to create a new release, but we do have to manually deploy to each environment.
Is there a workaround to this that we’re missing and if not can the auto deploy process be updated (or at least have the option) to use the current account keys. I fully understand that, by design, the auto deploy always uses the variable snapshot it was deployed with (and that makes a degree of sense), but this seems like a special use case. FWIW I think there should be a way to explicitly update the auto deploy variable snapshot, but that’s a fight for another day.
Thank you for bringing this to our attention. I have raised it with some of the engineers here.
What you are describing is the currently implemented solution. A deploy that is triggered, will use the snapshotted variables that were created at the time the release was created. As you say, it kind of makes sense, however, it is not likely that you would ever want to use a snapshotted version of an account connection, especially one with an old key.
I just wanted to reach out and let you know that we have flagged this as an issue with Octopus, but at this point we do not have capacity to assign an engineer to resolve the issue. We’ll keep the issue open, but unfortunately we can not provide any guidance as to when it will be resolved. I’m sorry for the inconvenience, and we do appreciate that you took the time to report the issue.
Since it doesn’t look like Engineering will have time to fix this anytime soon, can you give me more information on the Override? The docs say how to create one but aren’t super clear on exactly what the effect of an override is. Does the override only affect the next triggered release or does it lock all triggered releases to that version?
Sorry for the delay. I was unsure of the answer to this, but have reached out to the team.
The override should exist for the next triggered release only. It will revert back to the latest release after the next deployment.
I see now, that this is not a good permanent solution for you unless you program the override command to run each time before the next triggered release. However this feels very hacky. You will most likely have to resort to creating the release again each time until engineering nips this one in the bud.