-
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
chore(scheduler): Integration Test #26268
Conversation
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 pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
Ok I found the problem with the build: const now_time = new Date(Date.now());
const in_a_munite = new Date(now_time.getTime() + 5*60000); This part generates different CloudFormation every time it is run. And that the build script thinks that the CloudFormation has changed so it should be re-tested. I can only think of one solution:
Apart from that I think I need to change the PR title from |
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.
@Jacco we shouldn't have to make any changes specifically for an integ test. In fact, this PR should be titled a "chore" since it does not add any additional feature to the module. if you did find anything that needs fixing, those should come in a separate PR :).
As for the issue you are facing, why not use the scheduler.ScheduleExpression.rate(Duration.minutes(1))
?
Yes it is slightly different than running once in a minute but the expectation is that the integ test gets destroyed once it is verified.
Are the stacks deleted in the end of integration test? If the stacks are deleted - then I agree that using If the stacks are not deleted, how would you detect that the tag was created during this integration test run and not during the previous one? And more generally, just curious, why did you decide to assert on the target result. Would it be easier to just check if the target is invoked? (e.g. using logs, metrics). You could also use SQS as a target and check that the message arrives to the queue. |
Yes, stacks are deleted at the end of |
Thank I will get back to this. (Might take a while since I will be AFK for at least a week) |
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
This PR has been in the BUILD FAILING state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error. |
Continuing @Jacco work from #26268 Currently we were second-guessing if the implementations of ScheduleExpression and ScheduleTargetInput generate valid and correct CloudFormation. This integration test verifies that lambda invoke target is invoked: - A schedule is deployed that triggers a Lambda every minute after deployment. - The function adds a Tag to itself Key=OutputValue Value=base64 of the JSON string made of the input event - An assertion is made that checks for 10 minutes if the expected Tag appears Advances #23394 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Even though some parts are only defined in private still we can already test wether the current stuff generates CloudFormation that can actually be deployed.
Currently we were second-guessing if the implementations of ScheduleExpression and ScheduleTargetInput generate valid and correct CloudFormation.
This integration test is a proof of concept.
This integration test can evolve with the evolving of the Constuct.
Advances #23394
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license