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

(integ-runner): assertion stacks are not deploying to the cloud #21639

Closed
Bhuwan opened this issue Aug 17, 2022 · 1 comment · Fixed by #21646
Closed

(integ-runner): assertion stacks are not deploying to the cloud #21639

Bhuwan opened this issue Aug 17, 2022 · 1 comment · Fixed by #21646
Assignees
Labels
@aws-cdk/assertions Related to the @aws-cdk/assertv2 package bug This issue is a bug. effort/small Small work item – less than a day of effort in-progress This issue is being actively worked on. p1

Comments

@Bhuwan
Copy link

Bhuwan commented Aug 17, 2022

Describe the bug

I am trying to utilize integ-runner to build some very basic integration tests with assertions. I've noticed that while the integration test executes successfully, the stack for the Assertion never deploys to AWS.

Additionally, I tried to run some basic integration tests that are packaged with CDK, and the behavior is the same (the assertion stack is not deployed / executed). A sample would be @aws-cdk/aws-appsync/test/integ.log-retention.ts

Expected Behavior

  • integration test fails
  • assertion stack deployed to AWS

Current Behavior

  • integration test succeeds (despite a purposely failing assertion)
  • no assertion stack is deployed to AWS

Reproduction Steps

Here is a very basic integration test:

test/integ.sample.ts

import { IntegTest, ExpectedResult } from '@aws-cdk/integ-tests-alpha';
import { Stack } from 'aws-cdk-lib';


const app = new cdk.App();
const testCase = new Stack(app, 'cdk-integ-lambda-bundling');
const integ = new IntegTest(app, 'test.app', {
  testCases: [testCase],
});



const invoke = integ.assertions.invokeFunction({
  functionName: 'expected_to_fail',
});
invoke.expect(ExpectedResult.objectLike({
  Payload: '200',
}));

app.synth();

then execute:

npm run build
integ-runner --update-on-failed

Possible Solution

No response

Additional Information/Context

integ runner version = 2.38.0
See slack discussion https://cdk-dev.slack.com/archives/C018XT6REKT/p1660683475680059 with @mrgrain

CDK CLI Version

2.34.2

Framework Version

No response

Node.js Version

18.7.0

OS

macOS Monterey (arm)

Language

Typescript

Language Version

3.9.7

Other information

No response

@Bhuwan Bhuwan added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Aug 17, 2022
@github-actions github-actions bot added the @aws-cdk/assertions Related to the @aws-cdk/assertv2 package label Aug 17, 2022
@corymhall corymhall assigned corymhall and unassigned kaizencc Aug 17, 2022
@corymhall corymhall added p1 effort/small Small work item – less than a day of effort in-progress This issue is being actively worked on. and removed needs-triage This issue or PR still needs to be triaged. labels Aug 17, 2022
@mergify mergify bot closed this as completed in #21646 Aug 18, 2022
mergify bot pushed a commit that referenced this issue Aug 18, 2022
It is no longer valid in CDK v2 to specify stacks to deploy by the stack
name. This PR updates the logic to use the stack id.

I've also re-ran the integration tests that use assertions to verify
that the assertion stacks are now deployed.

fixes #21639


----

### All Submissions:

* [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md)

### Adding new Unconventional Dependencies:

* [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies)

### New Features

* [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)?
	* [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)?

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

josephedward pushed a commit to josephedward/aws-cdk that referenced this issue Aug 30, 2022
It is no longer valid in CDK v2 to specify stacks to deploy by the stack
name. This PR updates the logic to use the stack id.

I've also re-ran the integration tests that use assertions to verify
that the assertion stacks are now deployed.

fixes aws#21639


----

### All Submissions:

* [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md)

### Adding new Unconventional Dependencies:

* [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies)

### New Features

* [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)?
	* [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)?

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/assertions Related to the @aws-cdk/assertv2 package bug This issue is a bug. effort/small Small work item – less than a day of effort in-progress This issue is being actively worked on. p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants