graphql-engine/v3/crates/metadata-resolve/tests/metadata_golden_tests.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

76 lines
2.5 KiB
Rust
Raw Normal View History

Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
//! Tests that attempt to resolve different metadata files and assert that they parse successfully
//! or fail in the expected way.
use std::fs;
use std::path::{Path, PathBuf};
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
use serde_json::Value;
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
use metadata_resolve::MetadataResolveFlagsInternal;
#[test_each::path(glob = "crates/metadata-resolve/tests/passing/**/", name(segments = 2))]
#[allow(clippy::needless_pass_by_value)] // must receive a `PathBuf`
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
fn test_passing_metadata(comparison_folder_path: PathBuf) -> anyhow::Result<()> {
let passing_example = comparison_folder_path.join("metadata.json");
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
let metadata_resolve_flags_internal = MetadataResolveFlagsInternal {
enable_boolean_expression_types: true,
};
let metadata_json_value = read_json(&passing_example)?;
let metadata = open_dds::traits::OpenDd::deserialize(metadata_json_value)?;
let resolved = metadata_resolve::resolve(metadata, &metadata_resolve_flags_internal);
match resolved {
Ok(_) => Ok(()),
Err(msg) => panic!("{msg}"),
}
}
#[test_each::file(
glob = "crates/metadata-resolve/tests/failing/**/metadata.json",
name(segments = 3)
)]
#[allow(clippy::needless_pass_by_value)] // must receive a `PathBuf`
fn test_failing_metadata(
metadata_json_text: &str,
metadata_json_path: PathBuf,
) -> anyhow::Result<()> {
let comparison_folder_path = metadata_json_path.parent().unwrap();
let failing_reason = comparison_folder_path.join("expected_error.txt");
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
let metadata_resolve_flags_internal = MetadataResolveFlagsInternal {
enable_boolean_expression_types: true,
};
let error_untrimmed = fs::read_to_string(failing_reason).unwrap();
let error = error_untrimmed.trim();
match serde_json::from_str(metadata_json_text) {
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
Ok(metadata_json_value) => {
match open_dds::traits::OpenDd::deserialize(metadata_json_value) {
Ok(metadata) => {
match metadata_resolve::resolve(metadata, &metadata_resolve_flags_internal) {
Ok(_) => panic!("Expected to fail with {error}"),
Err(msg) => similar_asserts::assert_eq!(error, msg.to_string()),
}
}
Err(msg) => similar_asserts::assert_eq!(msg.to_string(), error),
};
}
Err(msg) => {
similar_asserts::assert_eq!(msg.to_string(), error);
}
};
Ok(())
}
fn read_json(path: &Path) -> anyhow::Result<Value> {
let json_string = fs::read_to_string(path)?;
let value = serde_json::from_str(&json_string)?;
Ok(value)
}