-
Notifications
You must be signed in to change notification settings - Fork 72
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
[Unified Fides Resources] Update Test Env Setup and Quickstart #2225
[Unified Fides Resources] Update Test Env Setup and Quickstart #2225
Conversation
- Instead of a patch to /connection/connection_key/dataset do a post to /dataset/upsert and then a patch to /connection/connection_key/datasetconfig. - Fix logging issue.
I wonder if it's related to populating the application db versus the test db. EDIT: Nevermind Thomas, I spotted it, this branch was trying to connect to the test db not the application db after all for some reason. |
…es" should be scanning the application db not the test db.
@@ -7,7 +7,7 @@ db = "fides" | |||
test_db = "fides_test" | |||
|
|||
[credentials] | |||
app_postgres = {connection_string="postgresql+psycopg2://postgres:fides@fides-db:5432/fides_test"} | |||
app_postgres = {connection_string="postgresql+psycopg2://postgres:fides@fides-db:5432/fides"} |
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.
I'm not sure why I made this change on this branch, that was a mistake - this should be looking at the running application db not the test db, and it was why we've had a failing test on this branch for awhile.
@@ -324,7 +344,7 @@ def create_dsr_policy(key: str): | |||
if response.ok: | |||
policies = (response.json())["succeeded"] | |||
if len(policies) > 0: | |||
logger.info("Created fidesops policy with key=%s via {url}", key) | |||
logger.info("Created fidesops policy with key={} via {}", key, url) |
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 had been causing the quickstart to break FYI, not sure if people are using the quickstart
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.
I believe @seanpreston said it was still being used for manual testing. If that's the case I think we should also be running it during CI checks (another ticket for another time)
…aset key with new saas fixtures.
… sub categories to avoid conflict when resolving data categories.
@allisonking the main reason I put up this PR was to get relevant passing on |
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.
🚀
@@ -91,7 +91,6 @@ dataset: | |||
fidesops_meta: | |||
data_type: string | |||
- name: shopify_customer_id | |||
data_categories: [system.operations] |
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.
how come this had to be deleted?
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.
Ah sorry, with the unified-fides-resources
merge, the ops side has a constraint where you can't put data categories at the "object" level. If you have nested data, data categories need to be on the sub-fields. This is because DSR's use the data categories to figure out which fields to send to the user. If the top level field and sub field have different data categories that conflict, we could get in a state where we don't know which data we should send.
Thanks for the review @allisonking |
Closes N/A
Code Changes
Steps to Confirm
nox -s test_env
nox -s clean
nox -s quickstart
- run quickstart through to the endPre-Merge Checklist
CHANGELOG.md
Description Of Changes
Get tests passing on
unified-fides-resources
branch after update with main.Also: Remove remaining uses of ops dataset endpoints in fides that we'd like to eventually deprecate (not a blocker for
unified-fides-resources
): deprecation will happen as a follow-up in the future: #2092. These endpoints still work, but are riskier because a dataset is upserted in the background, and we don't want people to unintentionally override their datasets.