Support Git-style searchPaths with wildcards in AWS S3 buckets (#2812)

[tomy8964]

Summary

Add full Git-style searchPaths support (placeholders + wildcards) to the AWS S3 backend so that users can migrate existing Git-based configurations without renaming to application.*.

• Implements literal, dot-wildcard (.*), single (?) and double (**) wildcard matching
• Retains the lookup order .properties → .json → .yml → .yaml when expanding literals or .* patterns
• Scans “directory” patterns for nested files
• Deduplicates identical keys across multiple patterns

This issue (#2812)
resolves #2812

---

Changes

1. Core Logic

   • Extended getS3ConfigFileWithSearchPaths(...) to treat {application} and {profile} placeholders identically to the Git backend

   • Added support for:

     • Literal + auto-ext: stops at first existing extension
     • Dot-wildcard (.*): expands against supported extensions in priority order
     • Single-character wildcard (?)
     • Multi-level wildcard (**)
     • Directory scan for literal prefixes ending with /

   • Ensured seenKeys set to avoid duplicate property sources

2. Tests
   Added new JUnit 5 tests in AwsS3EnvironmentRepositoryTests to cover all scenarios:

   • searchPaths_placeholderOnly_shouldResolveExactFile
   • searchPaths_wildcardOnly_shouldResolveAllProperties
   • searchPaths_placeholderAndWildcard_shouldResolveMatchingKeys
   • searchPaths_orderMatters_forPropertySourceOrder
   • searchPath_extensionPreserved (dynamic tests for each extension)
   • searchPaths_applicationAsDirectory_shouldStillHonorSearchPaths
   • multiDocumentYaml_withSearchPaths_shouldNotSplitDocuments
   • getLocations_returnsCorrect
   • searchPaths_deduplication_shouldOnlyAddOnce
   • searchPaths_singleCharacterWildcard_shouldMatchExactlyOneChar
   • searchPaths_withEmptyLabel_shouldUseDefaultLabel
   • searchPaths_multipleLabels_shouldApplyForEachLabelInReverseOrder
   • searchPaths_literalNotFound_shouldReturnEmpty

   …plus the additional edge cases for literal-stop, dot-wildcard priority, and nested directory patterns.

3. Example Usage

spring:
  cloud:
    config:
      server:
        awss3:
          bucket: my-config-bucket
          search-paths:
            - "{label}/{application}"          # literal + auto-ext
            - "{label}/{application}.*"        # dot-wildcard expansion
            - "{label}/common/*.json"          # JSON only in common/
            - "{label}/{application}.yml"      # explicit YML

---

Additional Notes

Backward Compatibility

This update does not break any existing AWS S3 config setups. The default lookup behavior is unchanged if no placeholders or wildcards are used in searchPaths.

Migration

Existing users migrating from Git-backed config servers can now use their current searchPaths (including wildcards and placeholders) on S3 with no renaming or convention change required.

Documentation

Documentation and usage examples for the enhanced searchPaths will be updated in the relevant documentation files after the merge.
If there are specific locations that require documentation updates, please let me know—I will be happy to update them.

Performance and Cost

Using wildcards (such as * or **) in searchPaths may result in additional AWS S3 API calls (e.g., ListObjects), especially for large buckets or deeply nested directory patterns.
This could lead to increased latency and higher AWS costs.
Users should consider the structure and size of their buckets when designing searchPaths and monitor AWS S3 usage accordingly.

---