[Bug]: Copilot env deploy fails with '✘ service "$SERVICE_NAME" must have "http.alias" specified when CloudFront is enabled' when service using default alias

[gidsg]

Description:

We have an env with the Cloudfront distribution enabled, initialised with a domain.

We deployed a service using the default alias (i.e. no alias specified in the manifest and deployed successfully with the default URL alias: https://$SVC.$ENV.$APP.$DOMAIN

When we re-deploy the env it shows an error: ✘ service "$SERVICE_NAME" must have "http.alias" specified when CloudFront is enabled'

Details:

copilot 1.33.4 deployed using Github Actions (https://github.com/communitiesuk/funding-service-design-workflows/actions/runs/9647224457/job/26605499412)

Observed result:

✘ service "$SERVICE_NAME" must have "http.alias" specified when CloudFront is enabled'

Expected result:

Using default alias should be sufficient and not cause env deploy to fail.

Debugging:

[dannyrandall]

Hi @gidsg, is this the same as this feature request? https://github.com/aws/copilot-cli/issues/5868

[gidsg]

is this the same as this feature request? https://github.com/aws/copilot-cli/issues/5868

@dannyrandall No, I believe this is a separate bug.

For example, if you:

• Initialise an app using --domain
• Deploy an env in that app
• Deploy a service in that env (without an alias)
• Re-deploy the env It will fail with ✘ service "$SERVICE_NAME" must have "http.alias" specified when CloudFront is enabled'

...even though the service has deployed successfully using the default domain name alias as described in: https://aws.github.io/copilot-cli/docs/developing/domain/#use-app-associated-root-domain

Therefore we believe this failure is erroneous and the env should not require a custom http.alias to be set.

This is a pain point for our team, as we have to provision additional DNS records to fix the env deploy even when the default alias is sufficient, in order to work around this issue.

[huanjani]

Hello, @gidsg!

It looks to me like the failure actually isn't erroneous: there is a validation (on the env side of things) to ensure that http: alias is specified when cdn is enabled. https://github.com/aws/copilot-cli/blob/473f331ac8127775896a70ef2c9cfb4a487a87d4/internal/pkg/describe/env.go#L281.

Here's a potential workaround (I haven't tested it): What if you put the default alias into the http.alias field? 🤔

[gidsg]

Here's a potential workaround (I haven't tested it): What if you put the default alias into the http.alias field?

@huanjani Thanks for the suggestion, yeah, so that is an option, the problem is that it triggers the ACM validation which requires a DNS change. (Which is a pain point on our side as our team don't control the DNS, so the service then rolls back)

It's strange because we should have a wildcard certificate on that subdomain but Copilot still seems to do an additional ACM request e.g. in ACM console

Maybe I'm misunderstanding how this should work?

[iamhopaul123]

Hello @gidsg. Sorry about the churn. It can be painful if you don't have permission over the DNS. As a workaround, what if you put *.dev. as the alias name?