<@U01JVDKASAC> I think I’m going to have to Reimpl...
# help
d
@Frank I think I’m going to have to Reimplement
StaticSite
as it currently does not seem to allow us to setup an origin group with the one that is created as part of the construct. Or am I missing something?
I would do it after the fact using L1 but the origin looks like
<unresolved-lazy>
to me at that point… not sure what to do with that?
f
@Dan Van Brunt can you give this a try:
Copy code
import * as origins from '@aws-cdk/aws-cloudfront-origins';

new sst.StaticSite(this, "MySite", {
  ...,
  cfDistribution: {
    additionalBehaviors: {
      origin: new origins.OriginGroup(...)
    }
  }
});
d
@Frank did you have a sec to look at this example? I need to know what the primary origin is in order to group them, no? And the primary is created in StaticSite
so if I was allowed to create my own bucket and origin outside of StaticSite and then pass them into that
cfDistribution
then I think that would work?
Does StaticSite allow us to pass in our own bucket?
oh shoot… it does I think
k let me try something
f
Currently the districution is created like this:
Copy code
return new cloudfront.Distribution(this, "Distribution", {
      // these values can be overwritten by cfDistributionProps
      defaultRootObject: indexPage,
      errorResponses,
      ...cfDistributionProps,
      // these values can NOT be overwritten by cfDistributionProps
      domainNames,
      certificate: this.acmCertificate,
      defaultBehavior: {
        origin: new cfOrigins.S3Origin(this.s3Bucket, {
          originPath: this.deployId,
        }),
        viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
        ...(cfDistributionProps.defaultBehavior || {}),
      },
    });
You can supply the bucket, but you also need to know the
deployId
i think.
d
ya saw that. but was more unsure about the s3Bucket
deployId ?
oh
right for the origin
f
Every deploy is deployed into a separate folder, with folder name containing the deployId, which is just a hash
lemme think
d
ya… was never sure why that was needed
I guess it updates the new folder and THEN cuts over the Distro/origin?
so its an instant cutover?
actually… Looks like you can’t pass in a
IBucket
into StaticSite…. just the bucket props Maybe its ok to just pass in the Arn as
bucket.bucketArn
?
Any idea if its even possible to query in code what those
<unresolved-lazy>
sections of the origins are? Since you are only creating one in static site…. I could just assume the first one is the primary
then modify using L1 of
cf.CfnDistribution
after StaticSite has resolved
f
yup… the L1 way might be the quickest workaroudn here for now
taking a look at lazy resolve
d
but when I console.log things I see this….
Copy code
"origins": "<unresolved-lazy>",
  "originGroups": "<unresolved-lazy>",
f
Can you try
Stack.resolve(origins)
and see what that gives u?
d
I did and it netted in a circular depencency error
f
I’m trying it rn.. what did u try just curious
I tried this
Copy code
const cfnDistribution = site.cfDistribution.node.defaultChild as cf.CfnDistribution;
    const stack = cdk.Stack.of(this);
    const config = stack.resolve(cfnDistribution.distributionConfig);
    console.log(config);
And it printed out
Copy code
{
  enabled: true,
  origins: [
    {
      domainName: [Object],
      id: 'devplaygroundsiteFrontendDistributionOrigin17965B565',
      originPath: '/deploy-7deba22a90a2dd9b208d57d40f2bdbcf',
      s3OriginConfig: [Object]
    }
  ],
  defaultCacheBehavior: {
    pathPattern: '*',
    targetOriginId: 'devplaygroundsiteFrontendDistributionOrigin17965B565',
    cachePolicyId: '658327ea-f89d-4fab-a63d-7e88639e58f6',
    compress: true,
    viewerProtocolPolicy: 'redirect-to-https'
  },
  aliases: [],
  customErrorResponses: [
    {
      errorCode: 403,
      responseCode: 200,
      responsePagePath: '/index.html'
    },
    {
      errorCode: 404,
      responseCode: 200,
      responsePagePath: '/index.html'
    }
  ],
  defaultRootObject: 'index.html',
  httpVersion: 'http2',
  ipv6Enabled: true
}
d
oohhhh thats great. let me try again
@Frank What does
stack.resolve()
actually do? I mean, currently I need to add a custom header to one of the origins but I don’t know which until I use that
resolve
on the config so I can see. Is there any order of operations issues with using
resolve
then modifying the
cfDistribution
after?