-
Notifications
You must be signed in to change notification settings - Fork 29
✨ Introduce changelog-driven FastAPI route configuration system #7620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Introduce changelog-driven FastAPI route configuration system #7620
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #7620 +/- ##
==========================================
+ Coverage 87.73% 89.04% +1.30%
==========================================
Files 1786 1250 -536
Lines 68922 52721 -16201
Branches 1134 224 -910
==========================================
- Hits 60472 46944 -13528
+ Misses 8138 5704 -2434
+ Partials 312 73 -239
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR introduces a changelog-driven FastAPI route configuration system in the common-library, aiming to improve API endpoint maintainability and documentation. Key changes include:
- Implementation of changelog entry classes (NewEndpoint, ChangedEndpoint, DeprecatedEndpoint, RetiredEndpoint) and related helper functions.
- Introduction of create_route_config and create_route_description functions to automatically adjust route properties based on API_VERSION and changelog data.
- Comprehensive test coverage added for validating changelog order and configuration outcomes.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
File | Description |
---|---|
packages/common-library/tests/test_changelog.py | Adds tests to validate changelog entries and route configuration logic. |
packages/common-library/src/common_library/changelog.py | Implements changelog entry classes and configuration helper functions. |
@mergify queue |
🟠 Waiting for conditions to match
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking nice! thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely a good improvement. One challenge I see is that we don't know in advance what the next released version of the api-server is. What I suggest is that the Make target which we use to bump the version of the api-server will display the diff in the openapi-specs. I volunteer to set that up. And then at least one can manually inspect what a change in the version exposes/deprecated/retires. What do you think?
3098f87
to
1700e54
Compare
…for deprecation logic
…constants, and add comprehensive tests for route configuration
…representation and enhance tests for route configuration
…roved consistency and type safety
1700e54
to
dac49f5
Compare
@mergify queue |
🛑 The pull request has been merged manuallyThe pull request has been merged manually at 975c581 |
|
What do these changes do?
The current release workflow for API entrypoints has proven to be error-prone and difficult to maintain. This PR introduces a new strategy aimed at improving the maintainability and documentation of our API endpoints. Note that it is built in
common_library
and so far it is not used in any service. If this is approach is accepted, the next step will be applying it in the api-server by replacing the existing methodProposal
We extend the concept of changelogs—already used in
api-server
—to drive Fastapiroute
decorator configuration dynamically. This includes automatically setting properties such asinclude_in_schema
,deprecated
, anddescription
based on a changelog and the currentAPI_VERSION
.Benefits
Example
When working to release something, assuming API_VERSION<0.10, this entrypoint will not be included in the OpenAPI specs, but it will happen as soon as we version bump it to 0.10 (and we will see in the
openapi.yaml
)In the following example the endpoint will be marked as deprecated as soon as
API_VERSION >= 0.9.0
and excluded from the OpenAPI schema automatically whenAPI_VERSION >= 0.9.0
, as it has been marked retiredExample, this code

will produce redoc documentation as follow:
Related issue/s
How to test
Dev-ops
None