Add Feature Flags module to Ligare.web and Ligare.platform #107
Conversation
a3aaebf to
a05d6ca
Compare
dc63f31 to
8e525d5
Compare
src/platform/Ligare/platform/feature_flag/database/migrate.py
Dismissed
Show dismissed
Hide dismissed
Moved over existing code from CAP and abstracted feature flag classes into generics. This allows us to get all, or filtered, feature flags in a type-safe way.
correctly in `get_feature_flags`. Also added clearer docblocks to feature flag functions.
Also removed `TAppConfig` generics from application builder.
…r has not been defined.
This requires some updates to how the Flask client creator for tests works. This commit contains an intentionally broken test.
- previously unable to run `make test*` or `make format*` targets due to empty variable value for `BUILD_TARGET` - `make test-pytest` did not exit with an error code when `pytest` had failed tests
bd283c8 to
6329907
Compare
application configs and modules to init methods used in tests. This changes allows tests to module configs and modules that would otherwise be included in the test app. Some tests may need to operate without certain modules.
Also add some more docs.
fb5eaca to
62e47bd
Compare
| @dataclass(frozen=True) | ||
| class FeatureFlagChange: | ||
| name: str | ||
| old_value: bool | None |
There was a problem hiding this comment.
Is it necessary to have both old and new values here? What do we gain from storing the old value, and is there a risk if this gets out of sync? (Say, with multiple requests)
There was a problem hiding this comment.
We only use this in the HTTP PATCH response as a means to report back the old and new values. Because the status code is the same regardless of whether a value did change, this is a means for the caller to determine whether the value actually changed.
I'm resolving some scaffolding bugs, but once those are complete we can use the scaffolded applications as reference implementations. Should make it easier to go off of than relying on CAP, since that mixes in a bunch of domain concerns as well. |
This PR contains refactors and feature additions to support adding a DI module to Ligare.platform that can handle the logic needed for Feature Flag usage, and the addition of an ASGI module to support a Feature Flag GET/PATCH API in Ligare.web.