test(ffe): use canonical fixtures#1979
Conversation
📚 Documentation Check Results📦
|
🔒 Cargo Deny Results📦
|
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. |
🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: 4aefcc6 | Docs | Datadog PR Page | Give us feedback! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1979 +/- ##
==========================================
+ Coverage 72.58% 72.69% +0.11%
==========================================
Files 451 451
Lines 74095 74258 +163
==========================================
+ Hits 53782 53983 +201
+ Misses 20313 20275 -38
🚀 New features to boost your workflow:
|
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
sameerank
left a comment
There was a problem hiding this comment.
It might help to include instructions like this for folks who may not be familiar
If this is a fresh clone, initialize submodules first:
git submodule update --init --recursive
perhaps in this section?
Lines 27 to 30 in 6e559d7
There was a problem hiding this comment.
Since datadog-ffe is used in several SDKs we would eventually need to publish it. Having git submodules embedded into the crate proved to be problematic for third party consumers. In order to minimize risks, I would recommend the following options:
- Create another crate for the canonical tests which will contain the git submodule and pulls the
datadog-ffeas a dependency, this approach is used in another pojects likeserde(test-suite). That way there will be no dependency to an internal repo on the published crate. That crate can be part of the workspace, the tests will be run each timedatadog-ffeis modified and since it will be mark withpublish = falsethere will be no risk of getting into trouble with downstream projects. - If option 1 is not feasible because of time of any project limitation, at the very least I would consider feature gate those tests and disable them by default. That way third party consumers won't fall into building issues if the tests are triggered. However this will require to modify the CI a bit in order to include that feature into the tests workflow.
Motivation
Use
DataDog/ffe-system-test-dataas libdatadog's canonical FFE/OpenFeature JSON fixture source instead of keeping local copied fixtures.Changes and Decisions
datadog-ffe/ffe-system-test-dataas a submodule pinned to merged canonicalmaincommit4446371bc1ca52bd526356927ef42d380145b118; remove copieddatadog-ffe/tests/datafixtures.ufc-config.jsonandevaluation-cases/*.json, with paths anchored fromCARGO_MANIFEST_DIR.result.reasonstays out of scope while reason behavior is still evolving..gitmodulesand weekly Dependabotgitsubmoduleupdates.https://datadoghq.atlassian.net/wiki/spaces/PANA/pages/6713639211/FFE+SDK+Fixture+Contribution+Guide