.serverless and .serverless_nextjs should be included on .gitignore?

[kyun]

I wonder .serverless and .serverless_nextjs should be ignored or not.

because if I add .serverless to .gitignore and I pull my project to another PC, I can't deploy it on another PC.

I can see CNAMEAlreadyExists Error Code only.

CNAMEAlreadyExists: One or more of the CNAMEs you provided are already associated with a different resource.

So, now I don't add .serverless to .gitignore but I am a nervous little bit because I don't know it is fine.

If I should .serverless with .gitignore, how can I avoid CNAMEAlreadyExists Error?

[medv]

You should include .serverless in your repository until the serverless framework removes the need for this.

[kyun]

@medv you mean .serverless has no credential information which should be private?

[medv]

It just contains resource definition and their ARNs. You also don't need to include .next and .serverless_nextjs folders as they are just the result of a build, so will be re-generated on each build. The .serverless folder contains all your infrastructure ARNs, so it's important to include it for other machines to be able to resume deploying to the existing resources.

[drakejin]

Has any solution to commit without AWS resources' arns?
I think it's a little nervous about that.
As you know as terraform state can manage(upload) on AWS s3 bucket.
So, I wonder there Is a solution like a terraform case on the serverless framework.

about terrafrom reference link here:

• https://www.terraform.io/docs/providers/terraform/d/remote_state.html

[medv]

There are other recent issues here that demonstrate how to put .serverless into s3 and sync it during CI step:

#328 (comment)

[drakejin]

@medv Oh Yes, I didn't think about that.
That's solution fit on @zynkn @Drake-Jin .
It's awesome what manage .serverless state on S3 bucket If it were created
Thanks.

[tyler-ground]

Yeah, putting it in a remote file store is the way to go. In github actions, I S3 copy before deploy then S3 copy back after.

This has the problem of parallel deployments conflicting but it may not matter as I've re-deployed with slightly out of date infrastructure config and it still worked.

[GraemeAllanBryce]

This document from the CEO of serverless includes the statement

Every Component now stores its state automatically in the cloud, so you can easily collaborate on them and run them in CI/CD.

Does this mean that the .serverless folder no longer requires to be part of the repository?

It is mentioned in the docs of this project that serverless were working on a solution to store state - I assume that the above link was the announcement of this event!

[danielcondemarin]

This document from the CEO of serverless includes the statement

Every Component now stores its state automatically in the cloud, so you can easily collaborate on them and run them in CI/CD.

Does this mean that the .serverless folder no longer requires to be part of the repository?

It is mentioned in the docs of this project that serverless were working on a solution to store state - I assume that the above link was the announcement of this event!

That is correct, however, to benefit from this the nextjs component needs to be upgraded to use the new serverless components version which introduced some breaking changes. I have already started working on the upgrade and should have more info on that soon.

[GraemeAllanBryce]

It may also be a valuable option for some folks to be able to specify an s3 bucket to store the state files and then simply recover this at the start of each deploy. This is an approach I have seen taken elsewhere and is reported to work well. G Graeme Bryce +44 (0) 7745 056933 [email protected]

…

On 27 May 2020, at 15:02, Daniel ***@***.***> wrote:  This document from the CEO of serverless includes the statement Every Component now stores its state automatically in the cloud, so you can easily collaborate on them and run them in CI/CD. Does this mean that the .serverless folder no longer requires to be part of the repository? It is mentioned in the docs of this project that serverless were working on a solution to store state - I assume that the above link was the announcement of this event! That is correct, however, to benefit from this the nextjs component needs to be upgraded to use the new serverless components version which introduced some breaking changes. I have already started working on the upgrade and should have more info on that soon. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[michaelgutierrez0]

This document from the CEO of serverless includes the statement

Every Component now stores its state automatically in the cloud, so you can easily collaborate on them and run them in CI/CD.

Does this mean that the .serverless folder no longer requires to be part of the repository?
It is mentioned in the docs of this project that serverless were working on a solution to store state - I assume that the above link was the announcement of this event!

That is correct, however, to benefit from this the nextjs component needs to be upgraded to use the new serverless components version which introduced some breaking changes. I have already started working on the upgrade and should have more info on that soon.

Hi Daniel,
Have you had any luck switching to this new version? I think it will help with my use case. My use case is that I would like to use the custom domain feature but with an environment variable. Currently I am using codebuild to run serverless. My issue is now I want to make a new code build for the beta env that uses an env var to set the domain name. The issue with this is that .serverless and .serverless_next have the domain name stored in them which is in the code repo. Thank you!

[dphang]

I think this can be closed. With the CDK construct it should be easier to manage state via the CDK / and you can customize it, and there are other workarounds using the normal deployer (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)..

Though we could possibly still upgrade to get parity for the legacy deployer (though not sure we will keep adding new configuration there if the CDK makes IaC easier)