HYPERFLEET-350: Add openapi generate part to Dockerfile #32
Conversation
WalkthroughThe pull request introduces a multi-stage Dockerfile build process that adds OpenAPI code generation. A new Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
Dockerfile (3)
6-13: Build reproducibility concern: fetching OpenAPI spec from main branch.The default
OPENAPI_SPEC_REF=main(line 6) means each build may fetch a different version of the OpenAPI spec if the main branch changes. This reduces build determinism and can cause unexpected behavior changes without explicit version bumps.Consider one of the following approaches:
- Default to a stable release tag (e.g.,
OPENAPI_SPEC_REF=v1.0.0) instead ofmain.- Document that
OPENAPI_SPEC_REFmust be explicitly specified for production builds.- Use a commit SHA for maximum reproducibility.
Additionally, the external network call during build (lines 10-13) creates a runtime dependency on GitHub availability. Consider caching the OpenAPI spec or including it in the repository if it's core to the build.
10-13: Add checksum validation for the downloaded OpenAPI spec.The spec is downloaded via
wgetwithout integrity verification. Consider adding a checksum (SHA256) to validate the downloaded file and detect tampering or corruption.Example enhancement:
-RUN echo "Fetching OpenAPI spec from hyperfleet-api (ref: ${OPENAPI_SPEC_REF})..." && \ - mkdir -p openapi && \ - wget -O openapi/openapi.yaml "${OPENAPI_SPEC_URL}" || \ - (echo "Failed to download OpenAPI spec from ${OPENAPI_SPEC_URL}" && exit 1) +ARG OPENAPI_SPEC_SHA256="" +RUN echo "Fetching OpenAPI spec from hyperfleet-api (ref: ${OPENAPI_SPEC_REF})..." && \ + mkdir -p openapi && \ + wget -O openapi/openapi.yaml "${OPENAPI_SPEC_URL}" || \ + (echo "Failed to download OpenAPI spec from ${OPENAPI_SPEC_URL}" && exit 1) && \ + if [ -n "${OPENAPI_SPEC_SHA256}" ]; then \ + echo "${OPENAPI_SPEC_SHA256} openapi/openapi.yaml" | sha256sum -c - || exit 1; \ + fiThis is optional but recommended for security-sensitive deployments.
1-54: Operational advice: Consider build caching and CI/CD implications.The addition of the
openapi-genstage introduces a new network dependency and build step. In CI/CD pipelines:
- Each build will re-fetch the OpenAPI spec and re-generate the client, which may slow down builds. Consider using Docker layer caching or pre-built base images if this becomes a bottleneck.
- Document the
OPENAPI_SPEC_REFbuild argument so CI/CD can pin stable versions.- Ensure the GitHub URL and hyperfleet-api repository are accessible from your CI/CD environment.
Additionally, if the OpenAPI spec is versioned, consider storing generated clients in a separate artifact repository or cache to avoid regenerating on every build.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Dockerfile(2 hunks)
🔇 Additional comments (2)
Dockerfile (2)
17-22: Confirm the generated client integration approach.The removal of
go.modandgo.sumfrom the generated code (line 21) and the test directory (line 22) is appropriate to avoid module conflicts with the main build. Ensure this approach aligns with your project's Go dependency management and that the generated code has no unmet imports after removal.
33-34: LGTM — OpenAPI client integration is clean.The
COPY --from=openapi-genpattern cleanly integrates the generated client into the builder stage without polluting the build context. The multi-stage approach keeps the build efficient.
| @@ -1,3 +1,26 @@ | |||
| FROM openapitools/openapi-generator-cli:v7.16.0 AS openapi-gen | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
openapitools/openapi-generator-cli v7.16.0 security advisories vulnerabilities
💡 Result:
Short answer — summary and guidance:
-
The openapi-generator-cli repository itself has no published security advisories. [1]
-
The main OpenAPITools/openapi-generator project has several past advisories that may be relevant to users of the CLI (notably):
- CVE-2024-35219 — path‑traversal (arbitrary file read/delete) in the online generator; fixed in openapi-generator >= 7.6.0. Versions prior to 7.6.0 are affected. [2][3]
- CVE-2023-27162 — SSRF in the online endpoints; affected up to 6.4.0 and fixed in 6.5.0. [4]
-
Impact for v7.16.0:
- v7.16.0 is newer than 7.6.0, so CVE-2024-35219 is fixed in that lineage. There are no public advisories listing v7.16.0 as vulnerable on the openapi-generator-cli security page. Still, the upstream project has historical CVEs you should be aware of. [1][2][4][5]
Recommendations:
- Upgrade to the latest stable openapi-generator / openapi-generator-cli (7.17.0 or newer). [5]
- If you expose any online/code‑generation endpoints (web service), ensure you follow the project advisories and harden/disable any online-generation features; treat user-supplied paths/URLs as untrusted.
- Monitor the OpenAPITools security page and OSV/NVD feeds for new advisories. [1][2]
Sources:
- openapi-generator-cli GitHub security page (no advisories). [1]
- OSV / NVD / GHSA entry for CVE-2024-35219 (path traversal, fixed in >=7.6.0). [2][3]
- GitLab/NVD entries and advisories for CVE-2023-27162 (SSRF, fixed in 6.5.0). [4]
- openapi-generator v7.16.0 release notes. [5]
🌐 Web query:
openapitools/openapi-generator-cli latest version 2025
💡 Result:
The latest stable release is v7.17.0 (released Oct 29, 2025). (github.com)
Citations:
🌐 Web query:
openapitools/openapi-generator-cli Docker Hub official image trusted source
💡 Result:
Yes — openapitools/openapi-generator-cli on Docker Hub is the official Docker image published by the OpenAPI Tools organization and is the recommended/authoritative Docker distribution for OpenAPI Generator CLI. The project README and website point users to that Docker image, and the openapitools Docker Hub account shows the openapi-generator-cli repository (millions of pulls and active tags). [1][2][3]
If you want to verify at source: check the openapitools organization page on Docker Hub and the OpenAPI Generator project README/website which link to docker image usage. [1][2][3]
Sources:
- Docker Hub — openapitools organization / openapi-generator-cli. [1]
- OpenAPI Generator GitHub README (Docker section). [2]
- OpenAPI Generator website (usage via Docker). [3]
Consider upgrading openapitools/openapi-generator-cli to v7.17.0.
The openapi-generator-cli:v7.16.0 image is from the official OpenAPI Tools Docker Hub account and is secure—no known vulnerabilities affect v7.16.0 (CVE-2024-35219 and CVE-2023-27162 are fixed in that version). However, v7.17.0 is the latest stable release (Oct 2025), so consider upgrading for the most current bug fixes and improvements.
🤖 Prompt for AI Agents
In Dockerfile at lines 1-1, update the base image tag from
openapitools/openapi-generator-cli:v7.16.0 to v7.17.0; change the FROM line to
reference v7.17.0, then rebuild the image and run the generator tests/CI to
verify compatibility and adjust any breaking changes if test failures occur.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rafabene The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-merge-bot
bot
merged commit 0146d4b
into
openshift-hyperfleet:main
2 participants
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.