feat(core): cfn constructs (L1s) can now accept constructs as parameters for known resource relationships

[leonmk-aws]

Issue # (if applicable)

Closes #.

Reason for this change

Allow passing L2s and L1s to L1s

Description of changes

Added a new relationship decider to parse the relationship information from the database and allow the other deciders to modify the properties / constructors accordingly. The relationship deciders assumes that:

• All modules will be built
• The properties in the relationship will exist (and have the same naming)

This generates code that looks like this for non nested properties:

In the properties:
readonly role: IamIRoleRef | string;

This is then used in the constructor:
this.role = (props.role as IamIRoleRef)?.roleRef?.roleArn ?? props.role;
If there were multiple possible IxxRef:
(props.targetArn as SqsIQueueRef)?.queueRef?.queueArn ?? (props.targetArn as SnsITopicRef)?.topicRef?.topicArn ?? props.targetArn

For nested properties

The props behave the same way, "flatten" functions are generated to recursively perform the same role that was done in the constructor for non nested properties:

function flattenCfnIdentityPoolRoleAttachmentRoleMappingProperty(props: CfnIdentityPoolRoleAttachment.RoleMappingProperty): CfnIdentityPoolRoleAttachment.RoleMappingProperty {
  return {
    "ambiguousRoleResolution": props.ambiguousRoleResolution,
    "identityProvider": props.identityProvider,
    "rulesConfiguration": (cdk.isResolvableObject(props.rulesConfiguration) ? props.rulesConfiguration : (props.rulesConfiguration ? flattenCfnIdentityPoolRoleAttachmentRulesConfigurationTypeProperty(props.rulesConfiguration) : undefined)),
    "type": props.type
  };
}

For arrays

 // @ts-ignore TS6133
function flattenCfnCodeSigningConfigAllowedPublishersProperty(props: CfnCodeSigningConfig.AllowedPublishersProperty | cdk.IResolvable): CfnCodeSigningConfig.AllowedPublishersProperty | cdk.IResolvable {
  if (cdk.isResolvableObject(props)) return props;
  return {
    "signingProfileVersionArns": props.signingProfileVersionArns?.map((item: any) => (item as SignerISigningProfileRef)?.signingProfileRef?.signingProfileArn ?? item)
  };
}

For arrays of nested props:

    this.fileSystemConfigs = (cdk.isResolvableObject(props.fileSystemConfigs) ? props.fileSystemConfigs : (props.fileSystemConfigs ? props.fileSystemConfigs.map(flattenCfnFunctionFileSystemConfigProperty) : undefined));

Database assumptions

Properties (the properties in sense of props of a resource but also prop of a type) have a a relationshipRefs array containing the relationship information:
relationshipRefs: [{ typeName: "AWS::IAM::Role", propertyPath: "Arn" }, ...]

Description of how you validated changes

• Checked the diffs between the previously generated code and the new one.
• Added snapshot tests
• Added unit tests for lambda
• Deployed a stack manually consisting of mixes of L1 and L2 resources using the new capabilities this PR adds

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[rix0rrr]

Add a unit tests somewhere that looks like this:

test('it works', () => {
  const stack = new Stack();

  const cfnRole = new CfnRole(stack, ...);
  const cfnFunction = new CfnFunction(stack, ..., {
    role: cfnRole,    // <-- I want to see this compile
  });

  Template.fromStack(stack).hasResourceProperties('AWS::Lambda::Function', { 
    Role: { Ref: ... }    // <-- and this produce the right template
  });
});

Can be any two resources that show up in the relationship data, pick your fave.

[leonmk-aws]

Added unit tests in the lambda construct, testing unions, array of unions and nested relationships, as well as code to ensure arn properties appear first in the generated code: 02a8656

[gasolima]

LGTM, I looked at the generated file and checked that the changes is ok. But didn't check if those relationship are right or not, since the only way to do it is to deploy stacks which unfeasible.

[gasolima]

I think having a separate file for L1 things is better idea than putting everything here. Just to make it separate for ppl to understand.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

This pull request has been removed from the queue for the following reason: pull request dequeued.

Pull request #35713 has been dequeued. Mergify failed to merge the pull request. GitHub can't merge the pull request after 14 retries.
Waiting for the branch protection required status checks to be validated.

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.
If you do update this pull request, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mrgrain]

@Mergifyio refresh

[mergify]

refresh

✅ Pull request refreshed

[mergify]

This pull request has been removed from the queue for the following reason: pull request dequeued.

Pull request #35713 has been dequeued. Mergify failed to merge the pull request. GitHub can't merge the pull request after 14 retries.
Waiting for the branch protection required status checks to be validated.

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.
If you do update this pull request, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[leonmk-aws]

@Mergifyio refresh

[mergify]

refresh

✅ Pull request refreshed

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.