When I switch the cloudformation pipe to a new version it fails to detect that the stack already exists and attempts to create a new stack. The new stack creation fails because the stack already existed in AWS, and subsequently the pipe fails.
For example, I've created several stack using the pipe: atlassian/aws-cloudformation-deploy:0.6.3. If I go back to one of those pipelines and change it to the latest version (0.9.2) it will not detect the existing stack in AWS, attempt to create a new stack, and fail.
Hi @Clayo84 ,
Thank you for your question!
We'll investigate this case and notify you.
Best regards,
Oleksandr Kyrdan
@Clayo84we are trying to reproduce your issue and find root cause now.
Could you share your bitbucket pipeline file, that part where you execute cloudformation pipes, both versions?
I just tried to reproduce and did not succeed, hope after your sharing will get the root cause.
Regards, Galyna
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Halyna Berezovska @Oleksandr Kyrdan Certainly! The relevant code is going from this:
- step:
name: Update Cloudformation stack
script:
- pipe: atlassian/aws-cloudformation-deploy:0.6.3
variables:
#WAIT: 'true'
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_DEFAULT_REGION: ${AWS_DEFAULT_REGION}
CAPABILITIES: ['CAPABILITY_IAM', 'CAPABILITY_NAMED_IAM']
TEMPLATE: serverless_app.yml
STACK_NAME: ${BITBUCKET_REPO_SLUG}-cloudformation-${BITBUCKET_BRANCH}
STACK_PARAMETERS: >
[{
"ParameterKey": "EnvironmentParam",
"ParameterValue": "$BITBUCKET_BRANCH"
},{
"ParameterKey": "NameStubParam",
"ParameterValue": "$BITBUCKET_REPO_SLUG"
}]
To this:
- step:
name: Update Cloudformation stack
script:
- pipe: atlassian/aws-cloudformation-deploy:0.9.2
variables:
#WAIT: 'true'
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_DEFAULT_REGION: ${AWS_DEFAULT_REGION}
CAPABILITIES: ['CAPABILITY_IAM', 'CAPABILITY_NAMED_IAM']
TEMPLATE: serverless_app.yml
STACK_NAME: ${BITBUCKET_REPO_SLUG}-cloudformation-${BITBUCKET_BRANCH}
STACK_PARAMETERS: >
[{
"ParameterKey": "EnvironmentParam",
"ParameterValue": "$BITBUCKET_BRANCH"
},{
"ParameterKey": "NameStubParam",
"ParameterValue": "$BITBUCKET_REPO_SLUG"
}]
EXTRA_PARAMETERS: >
{
"NotificationARNs": [name-removed-to-protect-the-innocent]
}
Please excuse the formatting, I promise it's properly lined up in the file.
Let me know if you need anything else from me!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Clayo84no matter, formatting is fine!
I see you're using
${BITBUCKET_REPO_SLUG}-cloudformation-${BITBUCKET_BRANCH}
as STACK_NAME variable.
Are you sure that your branch was not changed there ?
Me, did not change the branch while testing and it worked.
Also, just in case I tried to test another case and switch to the new branch (in case if your branch or repo is different from previous one).
I did got the error:
✖ Failed to update the stack.
ERROR: Failed to get information about stack mysteep-new-check-branch.
An error occurred (ValidationError) when calling the DescribeStacks operation: Stack with id mysteep-new-check-branch does not exist
An error occurred (ValidationError) when calling the UpdateStack operation: Invalid ARN name-removed-to-protect-the-innocent
It indeed logs that stack does not exist, buit this is just the output, the root cause was in incorrect role arn in EXTRA_PARAMETERS.
Clearing EXTRA_PARAMETERS, I have succeeded creating new stack (even previous one from another branch already existed).
I'd like to note that if you want the same stack to be updated , you should mention that stack, otherwise if branch or repo is different, the stack name will be also different.
So please, tell your purpose: do you want to create new stack on new branch, e.g., or update the previous one?
In the first case you can go more deep in extra params and look into aws docs for NotificationARNs notation (you can find it here https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-stack.html#aws-properties-stack-properties) . I guess arn should be like
"NotificationARNs": ["arn:aws:sns:us-east-1:111122223333:my-topic"] format
In the second case, ensure that you're on the same repo or branch, or just use the hardcoded stack name.
Regards, Galyna
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Not exactly.
I had obfuscated the SNS ARN because it included my tenant id.
I have since found that updating to the 0.10.0 version of this pipe appears to be handling the existing stack as expected.
Thank you for the time you've spent investigating this issue for me.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.