fix(amazonq): /test file collection usecase adds more patterns to filtering.

[ashishrp-aws]

Problem

/test has been seeing quite a lot of failures due to file paylaod limit exceeded errors in past weeks in both IDEs but in last week there has been huge rise in these errors for /test on VSCode.

Solution

We have noticed a change that ignores to use default patterns in file filtering was introduced in PR #6561 . We have also collected data from internal customers by adding payload manifest in JetBrains for these errors and compiled a list of extensions which are causing this issue. We have decided to add these patterns to ignore list on VSCode as well.

• For Test Generation useCase, we have added back default pattern ignore list
• we have created testGenIgnorePattern list and added these patterns to Filtering methods for Test Generation UseCase.
• Fixed the workspace folders sorting for Test Generation useCase in ziputils and removed it from workspaceUtils

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

• This pull request modifies code in src/* but no tests were added/updated.
  • Confirm whether tests should be added or ensure the PR description explains why tests are not required.
• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
  • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
  • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.

[jpinkney-aws]

Ideally we would get rid of this from processSourceFiles as well. I'm guessing this is neccessary for this release though?

FWIW you can see the consequence of this all throughout the zipUtil package. Theres generateZip and generateZipTestGen which already do very similiar things

[jpinkney-aws]

ci is failing

[ashishrp-aws]

Ideally we would get rid of this from processSourceFiles as well. I'm guessing this is neccessary for this release though?

FWIW you can see the consequence of this all throughout the zipUtil package. Theres generateZip and generateZipTestGen which already do very similiar things

Yes...necessary there to differentiate usage for review and test