Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(codepipeline): allow cross-account CloudFormation Actions #3208

Merged

Conversation

skinny85
Copy link
Contributor

@skinny85 skinny85 commented Jul 5, 2019

This adds a property 'account' to all CloudFormation CodePipeline Actions,
and properly handles passing it in the Pipeline construct.


Please read the contribution guidelines and follow the pull-request checklist.

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

@skinny85 skinny85 requested review from RomainMuller and a team as code owners July 5, 2019 00:16
let targetAccountStack: Stack | undefined = this._crossAccountSupport[targetAccount];
if (!targetAccountStack) {
const app = this.requireApp();
targetAccountStack = new Stack(app, `cross-account-support-stack-${targetAccount}`, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to add the stack directly under the app. Add it inside the pipeline's scope

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scratch that. This does not work for some reason. The unit test in the codepipeline-actions package that tests the new behavior for the CFN actions fail when anchoring the new stack under the pipeline:

Error: Can only reference cross stacks in the same region and account. target = PipelineStack/Pipeline/cross-account-support-stack-123456789012/PipelineStackPipeline9DB740AF-Deploy-CFN-DeploymentRole/Resource

It seems to me like the cross-account behavior is not triggered at all when I add the new stack under the pipeline's scope (this is an error message from CfnReference).

Any ideas why might that be...? Could it be because Stack.of(...) does not work correctly if stacks are nested under constructs...?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right. I think there is a bug in how substacks consume references. I will run some more tests tomorrow morning and hope to have some better understanding of this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This actually makes sense. The pipeline stack references the role in the other account and the automatic cross-stack references are triggered, but those only work for same-environment since they use exports/imports.

Digging further...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, haven't managed to figure out what the issue is. I still think there is a bug somewhere, but you'll have to dig further from your end. I've added a bunch of tests to verify some assumptions: #3373

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I've updated the PR to fix the out of order imports. Let's see if the build passes this time.

@skinny85 skinny85 force-pushed the feature/cross-account-cfn-codepipeline branch from 44bd30e to 15d43cb Compare July 7, 2019 23:32
@skinny85
Copy link
Contributor Author

skinny85 commented Jul 7, 2019

Updated with the comments on the previous revision.

@skinny85 skinny85 force-pushed the feature/cross-account-cfn-codepipeline branch from 15d43cb to fee4c7a Compare July 19, 2019 00:25
@skinny85 skinny85 requested a review from a team as a code owner July 19, 2019 00:25
@skinny85
Copy link
Contributor Author

I've updated the PR with all comments.

The only exception is changing the parent of the newly created stack, as anchoring it under the pipeline construct makes the unit test fail (see above comment).

packages/@aws-cdk/aws-codepipeline/lib/pipeline.ts Outdated Show resolved Hide resolved
if (this.isAwsOwned(action)) {
return action.actionProperties.role;
} else {
throw new Error("Specifying a Role is not supported for actions with an owner different than 'AWS' - " +
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The terminology "owner" here is extremely confusing (especially since we use it to indicate "owned resources"). How about something like "The action X does not support specifying a role".

Copy link
Contributor Author

@skinny85 skinny85 Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear: I'm talking here about this property.

Given that, does the error message makes sense? (I'm not worried about the isAwsOwned() method, it's private anyway)

EDIT: maybe this is a better explanation of the owner property

packages/@aws-cdk/aws-codepipeline/lib/pipeline.ts Outdated Show resolved Hide resolved
@skinny85
Copy link
Contributor Author

Newest batch of addressed comments.

@skinny85
Copy link
Contributor Author

Feel free to re-review @eladb .

eladb
eladb previously approved these changes Jul 29, 2019
Copy link
Contributor

@eladb eladb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update README

@NGL321
Copy link
Contributor

NGL321 commented Aug 1, 2019

Can the conflicts here be resolved and the PR merged?

@skinny85
Copy link
Contributor Author

skinny85 commented Aug 1, 2019

Please hold off on merging this ATM. I'll handle it.

@skinny85 skinny85 force-pushed the feature/cross-account-cfn-codepipeline branch from 54dacc8 to 9a35fd3 Compare August 3, 2019 00:22
@skinny85
Copy link
Contributor Author

skinny85 commented Aug 3, 2019

I realized something while working on the cross-account events in #3323. In previous revisions of this PR, I was caching the "scaffold stacks" (the ones generated for the IAM roles needed for cross-account deployments) for the actions on the Pipeline level. But that doesn't make sense; it should be global, on the App level, like we did for events in #3323 . I've updated the PR changing this; I also need to change the approach for the replication bucket stacks in a similar matter, but since I'm working on large changes in that area anyway, I'll defer that to a later PR.

@skinny85 skinny85 added the pr/do-not-merge This PR should not be merged at this time. label Aug 6, 2019
@skinny85 skinny85 force-pushed the feature/cross-account-cfn-codepipeline branch from 9a35fd3 to 696e2ee Compare August 9, 2019 20:38
@skinny85
Copy link
Contributor Author

skinny85 commented Aug 9, 2019

Rebased.

This adds a property 'account' to all CloudFormation CodePipeline actions,
and properly handles passing it in the pipeline construct.
@skinny85 skinny85 force-pushed the feature/cross-account-cfn-codepipeline branch from 696e2ee to 5f04f2b Compare August 9, 2019 21:27
@skinny85
Copy link
Contributor Author

skinny85 commented Aug 9, 2019

Updated the ReadMe.

@skinny85 skinny85 merged commit 8df4b7e into aws:master Aug 9, 2019
@skinny85 skinny85 deleted the feature/cross-account-cfn-codepipeline branch August 9, 2019 22:19
@NGL321 NGL321 added the contribution/core This is a PR that came from AWS. label Sep 27, 2019
@tjenkinson tjenkinson mentioned this pull request Feb 25, 2021
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. pr/do-not-merge This PR should not be merged at this time.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants