-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Add support for CloudFormation actions, continued #525
Conversation
--- Author's note: This work mostly belongs to Max Hall (@hallmaxw) It was at some point commented out during a refactor - this is just adding it back. Most of the credit should go to him. --- Anywho - this adds the ability for customers to use CloudForamtion actions in CodePipeline. This follows the same pattern as previous CodePipeline actions by making it it's own package.
Because you're probably wondering, this is the inheritance diagram of actions, and what each shared class adds to the mix.
|
@@ -0,0 +1 @@ | |||
export * from './pipeline-action'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import iam = require('@aws-cdk/aws-iam'); | ||
import cdk = require('@aws-cdk/cdk'); | ||
|
||
// tslint:disable:max-line-length |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of the long URL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disable only around that comment block?
/** | ||
* The name of the output artifact to generate | ||
* | ||
* Only applied if `outputFileName` is set as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be tempted to have
output?: {
fileName: string;
artifactName?: string;
}
So you cannot specify outputArtifactName
if it makes no sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmmyeah. But in general we keep the property namespace flat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's why I only say tempted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with Rico.Optimize for the common case which is to just specify the file name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally artifact names exist only to allow references in the Pipeline model which are achieved much better with object references in the CDK.
Copy: @skinny89
}); | ||
|
||
if (props.outputFileName) { | ||
this.artifact = this.addOutputArtifact(props.outputArtifactName || (this.parent!.name + this.name + 'Artifact')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why use this.parent!
when you have the guaranteed non-null parent
available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the constructor parent is not optional, so therefore it must be assigned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean why can't you use parent
instead of this.parent!
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. Well. I guess I could :)
|
||
constructor(parent: codepipeline.Stage, id: string, props: CloudFormationDeploymentActionCommonProps, configuration: any) { | ||
super(parent, id, props, { | ||
Capabilities: props.trustTemplate ? [CloudFormationCapabilities.NamedIAM] : props.capabilities, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if you trust the template, you cannot add other capabilities than NamedIAM
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yes, good point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although, what other capabilities are there :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, none, but nothing says it'll remain like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn’t future proof this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's risky... very likely to be overlooked if/when new capabilities get added. And the fix is not horribly expensive either...
ParameterOverrides: props.parameterOverrides, | ||
TemplateConfiguration: props.templateConfiguration, | ||
StackName: props.stackName, | ||
...configuration, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move ...configuration
up-front, because otherwise it can override the values you specified before...
}); | ||
|
||
if (props.role) { | ||
this.role = props.role; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you specify your own role, and say you trust the template, the policy doesn't get amended to extend any action on all resources. This seems to contradict the documentation of trustTemplate
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not contradict the documentation of role
, and it was intended this way (similar to default of capabilities
). This is a shortcut if you can't be bothered to specify anything. If you can, then you should just spell it out all the way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah no, the docs say it adds to the "default role", which is only the role that gets created if you don't specify anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels to me like a warning probably should be emitted...
"jsx": "react", | ||
"jsxFactory": "jsx.create" | ||
}, | ||
"_generated_by_jsii_": "generated by jsii - you can delete, and ideally add to your .gitignore" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do what the tool says!
* | ||
* @default false | ||
*/ | ||
trustTemplate?: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think something like fullTrust
or adminPrivileges
or root
. Something that has to do with "admin"
/** | ||
* Whether the deployed templates are trusted. | ||
* | ||
* If `true`, the default `role` will have full permissions and the default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Be more explicit in the docs about the IAM policy that this implies
const changeSetName = "ChangeSetIntegTest"; | ||
const stackName = "IntegTest-TestActionStack"; | ||
|
||
const role = new Role(stack, 'CfnChangeSetRole', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the default role
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is, now we're integ-testing both variants :).
"artifactId": "cloudformation-codepipeline" | ||
} | ||
}, | ||
"dotnet": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'd need to remove this target from here and "re-add" it into #524 ideally.
import cdk = require('@aws-cdk/cdk'); | ||
import { PolicyStatement, ServicePrincipal } from '@aws-cdk/cdk'; | ||
import { Test } from 'nodeunit'; | ||
import { CreateReplaceChangeSet, CreateUpdateStack, ExecuteChangeSet } from '../lib/pipeline-action'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing 's'
…bs/aws-cdk into mindstorms6/cloudformation-actions
Address review comments, fix input/output artifacts issue, expand README
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.