chore(scheduler): Integration Test

[Jacco]

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.

• A schedule is deployed that triggers a Lambda five minutes 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

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

[gitpod-io]

[aws-cdk-automation]

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.

[Jacco]

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:

• Create the schedule with a cron schedule with a DISABLED sate
• Add a Custom Resource lambda that accepts the arn of a Schedule
• The Lambda will change the Schedule from cron to at with a time in 5 minutes (and set the state to ENABLED)

Apart from that I think I need to change the PR title from feat to fix.

@filletofish @kaizencc

[kaizencc]

@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.

[filletofish]

Are the stacks deleted in the end of integration test? If the stacks are deleted - then I agree that using rate would be much easier.

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.

[kaizencc]

Yes, stacks are deleted at the end of yarn integ

[Jacco]

Thank I will get back to this. (Might take a while since I will be AFK for at least a week)

[aws-cdk-automation]

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-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 198c509
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

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.

[aws-cdk-automation]

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.