-
Notifications
You must be signed in to change notification settings - Fork 4k
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(assets): surface the CFN Parameters that Assets create #2057
Conversation
There is a pretty serious issue with this solution. Because Assets check whether the file/directory they point to exists, this forces the build in CodePipeline to happen sequentially - first the packaging of the Lambda source into a deployable artifact, and only then |
Fair point. The Correct Solution (tm) is probably to add a The toolkit already has a |
const parameterOverrides: { [name: string]: any } = {}; | ||
parameterOverrides[lambdaCode.asset.bucketNameParam.logicalId] = lambdaBuildAction.outputArtifact.bucketName; | ||
parameterOverrides[lambdaCode.asset.objectKeyParam.logicalId] = lambdaBuildAction.outputArtifact.objectKey; | ||
pipeline.addStage({ |
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.
Can you build the next layer on top of this as well?
So that we basically do:
const stack = new MyStack(app, 'MyStack');
stack.addToPipeline(pipeline); // (*)
And make that work? What will we need to map assets used in the application to build artifacts? Can we even find a list of all assets, so that the addToPipeline()
call can determine that we satisfied all requirements? Etc.
// (*) I know this exact method call will not work because the package dependency arrows will point the wrong way, but I'm mirroring the build.addToPipeline()
etc. methods here.
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.
We are actually planning to remove all the addTpPipeline methods since we are moving all the pipeline integration classes to a centralized package. But maybe something like an integration class would work.
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.
But yeah, this is waaayy to verbose
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.
Can you build the next layer on top of this as well?
So that we basically do:
const stack = new MyStack(app, 'MyStack'); stack.addToPipeline(pipeline); // (*)And make that work? What will we need to map assets used in the application to build artifacts? Can we even find a list of all assets, so that the addToPipeline() call can determine that we satisfied all requirements? Etc.
// (*) I know this exact method call will not work because the package dependency arrows will point the wrong way, but I'm mirroring the build.addToPipeline() etc. methods here.
We can't be so high level, unfortunately. You wouldn't know which Pipeline Artifacts to use to override each Asset - the customer needs to specify 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 know, but what I'm saying is trying to get as close to that as possible.
const parameterOverrides: { [name: string]: any } = {}; | ||
parameterOverrides[lambdaCode.asset.bucketNameParam.logicalId] = lambdaBuildAction.outputArtifact.bucketName; | ||
parameterOverrides[lambdaCode.asset.objectKeyParam.logicalId] = lambdaBuildAction.outputArtifact.objectKey; | ||
pipeline.addStage({ |
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.
We are actually planning to remove all the addTpPipeline methods since we are moving all the pipeline integration classes to a centralized package. But maybe something like an integration class would work.
const parameterOverrides: { [name: string]: any } = {}; | ||
parameterOverrides[lambdaCode.asset.bucketNameParam.logicalId] = lambdaBuildAction.outputArtifact.bucketName; | ||
parameterOverrides[lambdaCode.asset.objectKeyParam.logicalId] = lambdaBuildAction.outputArtifact.objectKey; | ||
pipeline.addStage({ |
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.
But yeah, this is waaayy to verbose
568c565
to
4db81c5
Compare
4db81c5
to
7caf911
Compare
Added mention of |
This is needed in order to override them when deploying the Stack through CodePipeline.
7caf911
to
6bb1900
Compare
@@ -324,9 +324,69 @@ This package defines the following actions: | |||
changes from the people (or system) applying the changes. | |||
* **CloudFormationExecuteChangeSetAction** - Execute a change set prepared previously. | |||
|
|||
##### Lambda deployed through CodePipeline |
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.
This section makes me feel that maybe we should merge the README files of aws-codepipeline and aws-codepipeline-actions. It feels artificial to have to jump between the two... What do you think?
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 don't have any philosophical objections to that, I do have one practical concern though: nesting. As you can see, we've reached H5 in the ReadMe for codepipeline-actions
, and I assume we'll need to increase the nesting of the headings by at least one level if we move them to the codepipeline
ReadMe.
|
||
```typescript | ||
const lambdaStack = new cdk.Stack(app, 'LambdaStack', { | ||
autoDeploy: false, // to make working with the 2 Stacks easier in the toolkit |
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.
Change the comment to describe what this does
cdkBuildAction, | ||
], | ||
}); | ||
// finally, deploy your Lambda Stack |
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.
Style: new line before each "//" line
runtime: lambda.Runtime.NodeJS810, | ||
}); | ||
// used to make sure each CDK synthesis produces a different Version | ||
const version = func.newVersion(); |
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.
This sounds weird and scary?... We can't have "cdk synth" produce a different result each time. Is this just temporary until we have #1400?
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 meant to be used in a Pipeline, so I believe that's fine.
@@ -51,6 +52,13 @@ export class Artifact { | |||
public toString() { | |||
return this.artifactName; | |||
} | |||
|
|||
public overrideAsset(asset: assets.Asset): { [name: string]: string } { |
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 documentation. I am not sure about this name... Reads weird: artifact.overrideAsset(asset)
. What does this mean? Maybe something like artifact.wireAsset(asset)
or artifact.useAsset(asset)
?
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.
The word used is override
because you're changing what the asset points to. Before, it was referencing something on the file system - now, it references something in the Pipeline. So I think it makes a lot of sense.
But if you prefer useAsset
(wireAsset
I don't think is great...), I won't fight you (too strongly ;p) on it.
Talked with Elad offline about this PR. We decided not to go through with it. |
This is needed in order to override them when deploying the Stack through CodePipeline.
Pull Request Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.