CNAMEAlreadyExists

[wzalazar]

Describe the bug

When the CI deploying the app I'm receiving this issue

To Reproduce

actually I don't know how to reproduce

Expected behavior

Deploy the app

[gamribeiro]

Are you committing your application state in source control? That is the files under the .serverless directory. If don’t, Ci will create a new Cloudfront in every build.

[wzalazar]

@gamribeiro sorry, Should I commit this folder? I didn't find any information in the documentation about how we have to work with the CI tools.

I'm using other serverless components and it doesn't need to commit anything related to the serverless.

Also reviewing the configuration in the .serverless folder there are files with paths related to my computer so I think it won't work in the CI.

[gamribeiro]

In the documentation they tell us:

CI/CD] A new CloudFront distribution is created on every CI build. I wasn't expecting that:
You need to commit your application state in source control. That is the files under the .serverless directory. The serverless team is currently working on remote state storage so this won't be necessary in the future.

.serverless directory is where they keep it your application state.

Try to:

• Run serverless with one new Cname firstbuild.exemple.com
• .serverless directory will be created with all templates.
• Delete .serverless
• Run serverless again with same Cname firstbuild.exemple.com
• You should get this error, because firstbuild.exemple.com will be associated with another cloudfront already.

After that, you can try to do not delete .serverless and rebuild your application. It will only updated your assets and not try to create a new cloudfront.

[wzalazar]

@gamribeiro thanks, well I tried some stuff yesterday and I had an issue creating the same app with different subdomains keeping the .serveless folder. Is this an expected behavior?

For the hand I will try your advice, but I think before I have to remove all resources inside in AWS.

I will leave comments later.

[mrowles]

It seems bad practice to have to commit .serverless folder. I deploy purely from CI/CD using secret account variables that I don't know, so I can't generate this folder locally. Seems like it was built quite differently to how we know Serverless to work, can we not just utilize cloudformation?

[wzalazar]

It seems bad practice to have to commit .serverless folder.

Yes

can we not just utilize cloudformation.

Seems there is an issue with the cloudformation limits #17

[SarKurd]

It seems bad practice to have to commit .serverless folder. I deploy purely from CI/CD using secret account variables that I don't know, so I can't generate this folder locally. Seems like it was built quite differently to how we know Serverless to work, can we not just utilize cloudformation?

We deploy purely from CI too, store the state in an S3 bucket

Get state from S3 -> build and deploy -> update the state in S3

We use plugins/s3-cache for Drone CI

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dphang]

Updated CI/CD / multi-stage deployment FAQs here: https://github.com/serverless-nextjs/serverless-next.js#cicd-multi-stage-deployments--a-new-cloudfront-distribution-is-created-on-every-ci-build-i-wasnt-expecting-that.

Yes, the DX can be better especially for CI/CD use, I think we should integrate it in the component using AWS S3 buckets to store state or with new serverless components version (I use the former, haven't read up much on the latter yet). I will consider how to do this.