feat: Add ability to use waitForTaskToken for ECS tasks

[nicolaei]

Description

This change adds the ability to use waitForTaskToken for ECS tasks.

Why is the change necessary?

To add support for documentet features. Ref the ECS step docs in the step function documentation.

Solution

The solution uses the already established pattern of having an argument wait_for_callback, as seen in the lambda task.

But because we can't have both wait_for_completion and wait_for_callback at the same time, I've added a condition to raise a ValueError if both are set to True. I'm happy to change this if you've already got an established pattern for argument errors.

Testing

Created a Unittest and also using this in a project at work.

---

Pull Request Checklist

Please check all boxes (including N/A items)

Testing

• [x] Unit tests added
• [x] Integration test added
• [x] Manual testing - why was it necessary? could it be automated?

Documentation

• [x] docs: All relevant docs updated
• [x] docstrings: All public APIs documented

Title and description

• [x] Change type: Title is prefixed with change type: and follows conventional commits
• [x] References: Indicate issues fixed via: Fixes #xxx

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

[wong-a]

Thanks for the PR! For integrations that support all 3 integration patterns, we started to introduce a different way to set this using the IntegrationPattern enum instead of separate args for each pattern.

• https://github.com/aws/aws-step-functions-data-science-sdk-python/commit/f9e63b312f543954c663e305fd5eedd9b2cdd360
• https://github.com/aws/aws-step-functions-data-science-sdk-python/pull/176

[nicolaei]

Sorry about the multiples of force-pushes (and subsequent spams from the build). Had some issues with the test-suite on my local machine for some reason 🤔

---

Thanks for the PR! For integrations that support all 3 integration patterns, we started to introduce a different way to set this using the IntegrationPattern enum instead of separate args for each pattern.

• f9e63b3
• refactor: Update AWS Glue Databrew StartJobRun step to use integration pattern input #176

Would you like me to change the PR to use that pattern? I could introduce it to all the other task classes in compute.py while I'm at it if you'd like.

Seeing that it would be a breaking change as well, I'd probably have to change the PR title to breaking?

[wong-a]

Would you like me to change the PR to use that pattern? Seeing that it would be a breaking change as well, I'd probably have to change the PR title to breaking?

See https://github.com/aws/aws-step-functions-data-science-sdk-python/pull/180#discussion_r748630286

I could introduce it to all the other task classes in compute.py while I'm at it if you'd like.

We like to keep PRs small, so just ECS is more than fine. The main motivation here is supporting all 3 integration patterns and ECS is the only implemented integration that doesn't expose all of them.

[nicolaei]

Sorry for the late change here, but here you go!

[nicolaei]

@wong-a: Any chance we can get this merged? 😄

[StepFunctions-Bot]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject6AEA49D1-sEHrOdk7acJc
• Commit ID: f7ca980e7884a619c6cfb9f2515ab7dcaa02c226
• Result: FAILED
• Build Logs (available for 30 days)

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

[nicolaei]

I updated the tests with explicit testing of both old-style and new-style parameters now!

I'm a bit confused why the tests are failing though, because these build-issues seem totally unrelated, and I only updated my test-code 🤔 Any thoughts @jormello?