-
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
(aws-events): cross-region event rules breaks cross-account codepipelines #15639
Comments
I'm suprised that this setup used to work at all, given that it looks like CodePipeline doesn't seem to support cross-account CodeCommit repositories. There is no mention of an And when I try your code for myself, I get this error in CodePipeline: |
I must have missed a dependency between the two stacks, please try deploying There's a published guide for a cross-account codepipeline, but really under the hood, it is just cross-account event delivery. |
Yes, I've seen it work now which is crazy. |
When we started supporting cross-region event targets, we needed to add a role to the event-bus target. At that point, we also opted to fall back to the role that the event target requested for itself. However, that was wrong: the role used in that place is *only* for passing events between event buses, and *never* for triggering the actual target. Solution: don't fall back, only use a special role for event passing. In fact, don't even do it if the target isn't in a different region, because apparently it's not necessary for cross-account event passing at all. Refactor the `events` code a little to make clear what is happening and why, because it was string to get messy. Fixes #15639.
…15717) When we started supporting cross-region event targets, we needed to add a role to the event-bus target. At that point, we also opted to fall back to the role that the event target requested for itself. However, that was wrong: the role used in that place is *only* for passing events between event buses, and *never* for triggering the actual target. Solution: don't fall back, only use a special role for event passing. In fact, don't even do it if the target isn't in a different region, because apparently it's not necessary for cross-account event passing at all. Refactor the `events` code a little to make clear what is happening and why, because it was starting to get messy. Fixes #15639. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
…ws#15717) When we started supporting cross-region event targets, we needed to add a role to the event-bus target. At that point, we also opted to fall back to the role that the event target requested for itself. However, that was wrong: the role used in that place is *only* for passing events between event buses, and *never* for triggering the actual target. Solution: don't fall back, only use a special role for event passing. In fact, don't even do it if the target isn't in a different region, because apparently it's not necessary for cross-account event passing at all. Refactor the `events` code a little to make clear what is happening and why, because it was starting to get messy. Fixes aws#15639. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ws#15717) When we started supporting cross-region event targets, we needed to add a role to the event-bus target. At that point, we also opted to fall back to the role that the event target requested for itself. However, that was wrong: the role used in that place is *only* for passing events between event buses, and *never* for triggering the actual target. Solution: don't fall back, only use a special role for event passing. In fact, don't even do it if the target isn't in a different region, because apparently it's not necessary for cross-account event passing at all. Refactor the `events` code a little to make clear what is happening and why, because it was starting to get messy. Fixes aws#15639. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ws#15717) When we started supporting cross-region event targets, we needed to add a role to the event-bus target. At that point, we also opted to fall back to the role that the event target requested for itself. However, that was wrong: the role used in that place is *only* for passing events between event buses, and *never* for triggering the actual target. Solution: don't fall back, only use a special role for event passing. In fact, don't even do it if the target isn't in a different region, because apparently it's not necessary for cross-account event passing at all. Refactor the `events` code a little to make clear what is happening and why, because it was starting to get messy. Fixes aws#15639. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Upgrading from <=1.112.0 caused my cross-account codepipelines to be undeployable. I have a multi-account setup with CodeCommit repositories hosted in one account triggering CodePipelines in several different accounts. Following CDK upgrade deployment fails with
It appears as though the change in #14731 alters the change of the rule target to include a roleArn, at least that appears to be the difference in what is synthesized.
Reproduction Steps
Apologies if this is somewhat convoluted, I've attempted to extract an example that best represents the situation as it exists in my application. If you need more detail or more color around the situation, let me know.
app.js
config.json
SourceStack.js
PipelineStack.js
What did you expect to happen?
I expected the application to deploy and function as it did in version <=1.112.0.
What actually happened?
I received an error:
Environment
Other
It would seem to me that the cross-region events features should be rolled back or put on a flag if a quick fix is not available. As of now I'm effectively locked at version 1.112.0.
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: