The GitHub Actions job "Licensing - RAT Report" on grails-core.git/feat/openapi-springdoc-8.0.x has failed. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: 57bb1db4fdade33accc8bcc9436c3e0e6cefdc99 / Scott Murphy Heiberg <[email protected]> Follow the URL mappings when describing controllers they do not name Expansion synthesized a "/$controller/$action/$id" shape from the controller artefacts without checking that any mapping served it. A generated REST API application is mapped the other way round - the action is named and the controller left to the request - so it got a document whose every operation was wrong in both directions: the paths it serves were absent, and the paths described returned 404. The guide's advice to remove the default mapping had no effect either, because the mapping was never consulted. Expansion now follows the mappings. A mapping that names the action is described at the URL that mapping serves, one that names neither is expanded across the controller's actions as before, and an application whose mappings name every controller gets neither. The default mapping form carries a distinct operation identifier, so a controller reached both ways no longer produces two operations with the same identifier for springdoc to disambiguate by order. Also from the same review: - a zero bound was dropped, because Groovy reads it as falsy: min: 0 and maxSize: 0 are real constraints - a nested command object was neither pruned nor constrained, so one nested command reintroduced the sixty schemas pruning exists to remove - a schema named through @Schema(name) was registered under that name but referred to and overlaid under the class name, losing its constraints - the array form of @ApiResponse content was ignored, which is the form used to declare a collection response - a greedy parameter was always called path while the declared parameter kept the constraint's name, so the two did not agree - a mapping declared for a status code became a path - schemas were resolved with the 3.0 converter into a 3.1 document, and the string constraints were applied by Java class rather than declared type, so they were silently skipped under 3.1 - the mapping context is resolved through a provider, so an application with more than one datastore starts - an unsupported HTTP method skips its mapping and logs, rather than failing the document - grails-datamapping-validation and grails-validation are declared, being used from src/main rather than only from tests Three tests asserted nothing and were replaced: the greedy path test passed on an empty collection, the idempotency test compared a schema with itself because the second pass short-circuits, and the expansion tests passed mapping closures that did not contain the mapping whose behavior they described. Report URL: https://github.com/apache/grails-core/actions/runs/33442417213 With regards, GitHub Actions via GitBox
