feat: API implementation and Docker artifact publishing#1
Conversation
|
|
||
| @Bean | ||
| public ValidationRunner validationRunner(VersionResolver versionResolver) { | ||
| return new ValidationRunner(versionResolver); |
There was a problem hiding this comment.
I am not sure the ValidationRunner is completely thread safe.
There was a problem hiding this comment.
This uses the same pattern as the current API => https://github.com/MobilityData/gtfs-validator/blob/87109ed0858fbad23ccf47bb5925cd3ea38acf99/web/service/src/main/java/org/mobilitydata/gtfsvalidator/web/service/Main.java#L32
There was a problem hiding this comment.
I guess in that case the current API is wrong. Or the number of simultaneous requests is limited to 1? Not sure.
See ValidationRunner.run for a non thread safe operation.
It's not catastrophic if it fails, just that the memory info int he report could be wrong.
There was a problem hiding this comment.
Let's fix it then. I see that the memory reporting is impacted, not the validation output. In the current MD deployment, we don't have concurrent calls; that's why there is no impact on the memory reports.
There was a problem hiding this comment.
It can be fixed or documented that the number of concurrent requests should not be more than 1, like in the current web validator.
But fixing is safer.
There was a problem hiding this comment.
Created GTFS issue and added a comment in the code.
Description
This PR adds the first stable implementation of the OpenAPI schema. The implementation uses the https://github.com/openapitools/openapi-generator Maven plugin to generate most of the code and interfaces. The core validator functionality is located in the official GTFS validator repository.
Out of scope
completeandheavyenough to review.From our AI friend
This pull request introduces the initial setup for the GTFS Validator API project, providing a production-ready, containerized, and CI-integrated Spring Boot HTTP API for the MobilityData Canonical GTFS Schedule Validator. The changes establish the build system, code formatting, Dockerization, continuous integration workflows, and detailed documentation, as well as the application entry point.
The most important changes are:
Build System and Dependency Management
pom.xmlconfiguring the project as a Spring Boot application, managing dependencies (including the validator core and patched transitive dependencies), plugins for OpenAPI code generation, code formatting (Spotless with google-java-format), and resource handling. The build also integrates the OpenAPI spec and sets up code style enforcement.Dockerization
Dockerfileto build and package the application as a minimal, production-ready container image, running as a non-root user and exposing configuration viaJAVA_OPTS..dockerignorefile to exclude unnecessary files and directories from Docker build context, improving build efficiency and security.Continuous Integration
.github/workflows/build.ymlfor building, testing, and enforcing code style on every push, pull request, or manual trigger..github/workflows/docker.ymlworkflow to build and publish multi-arch Docker images to GitHub Container Registry on pushes, tags, releases, and pull requests.OpenAPI Code Generation
.openapi-generator-ignoreto prevent overwriting custom source files during OpenAPI code generation, ensuring maintainability of hand-written code.Documentation and Entry Point
README.mddescribing the project, endpoints, build/test instructions, Docker usage, CI/CD processes, configuration, and project structure.src/main/java/org/mobilitydata/gtfsvalidator/api/Application.javafor the Spring Boot service.