2023-12-19 12:04:02 +03:00
|
|
|
set positional-arguments
|
|
|
|
|
|
|
|
default:
|
|
|
|
just --list
|
|
|
|
|
2024-07-25 19:15:52 +03:00
|
|
|
build:
|
2024-08-07 18:02:33 +03:00
|
|
|
cargo build --release --all-targets
|
2023-12-19 12:04:02 +03:00
|
|
|
|
2024-04-02 18:08:38 +03:00
|
|
|
format:
|
|
|
|
cargo fmt --check
|
Format everything with Prettier. (#530)
I found myself wanting to rewrite JSON files with `sed`. The problem is,
then I want to run a formatter over them afterwards, and this will
change the whole file, not just the area I touched.
I would like to propose the nuclear option in remedying this: format
everything now. This is a very large change that should make it easier
to keep files to a consistent format in the future.
I have chosen to use Prettier for this because (a) it has a useful
`--write` command and (b) it also does GraphQL, Markdown, YAML, etc.
I've elected to exclude two sets of files:
1. `crates/custom-connector/data/*.json`, because they are actually
multiple JSON objects, one per line, which Prettier cannot parse.
2. `crates/lang-graphql/tests/**/*.graphql`, because it contains invalid
GraphQL, and the parser is intended to work with strangely-formatted
GraphQL.
The main changes are standardizing whitespace, adding a newline at the
end of files, and putting JSON arrays on one line when they fit.
V3_GIT_ORIGIN_REV_ID: 92d4a535c34a3cc00721e8ddc6f17c5717e8ff76
2024-04-30 17:58:09 +03:00
|
|
|
prettier --check .
|
2024-06-04 17:14:54 +03:00
|
|
|
! command -v nix || nix fmt -- --check .
|
2024-04-02 18:08:38 +03:00
|
|
|
alias fmt := format
|
|
|
|
|
2024-07-25 19:15:52 +03:00
|
|
|
fix:
|
2024-05-28 11:50:46 +03:00
|
|
|
cargo clippy --all-targets --no-deps --fix --allow-no-vcs
|
2024-04-08 13:13:26 +03:00
|
|
|
cargo fmt
|
2024-05-02 11:43:16 +03:00
|
|
|
just fix-format
|
2024-06-04 17:14:54 +03:00
|
|
|
! command -v nix || nix fmt
|
2024-05-02 11:43:16 +03:00
|
|
|
|
|
|
|
fix-format:
|
Format everything with Prettier. (#530)
I found myself wanting to rewrite JSON files with `sed`. The problem is,
then I want to run a formatter over them afterwards, and this will
change the whole file, not just the area I touched.
I would like to propose the nuclear option in remedying this: format
everything now. This is a very large change that should make it easier
to keep files to a consistent format in the future.
I have chosen to use Prettier for this because (a) it has a useful
`--write` command and (b) it also does GraphQL, Markdown, YAML, etc.
I've elected to exclude two sets of files:
1. `crates/custom-connector/data/*.json`, because they are actually
multiple JSON objects, one per line, which Prettier cannot parse.
2. `crates/lang-graphql/tests/**/*.graphql`, because it contains invalid
GraphQL, and the parser is intended to work with strangely-formatted
GraphQL.
The main changes are standardizing whitespace, adding a newline at the
end of files, and putting JSON arrays on one line when they fit.
V3_GIT_ORIGIN_REV_ID: 92d4a535c34a3cc00721e8ddc6f17c5717e8ff76
2024-04-30 17:58:09 +03:00
|
|
|
prettier --write .
|
2023-12-19 12:04:02 +03:00
|
|
|
|
2024-07-23 14:43:29 +03:00
|
|
|
run-local-with-shell:
|
|
|
|
#!/usr/bin/env bash
|
|
|
|
cargo run --bin custom-connector | ts "custom-connector:" &
|
|
|
|
OTLP_ENDPOINT=http://localhost:4317 \
|
|
|
|
cargo run --bin dev-auth-webhook | ts "dev-auth-webhook:" &
|
|
|
|
RUST_LOG=DEBUG cargo run --bin engine -- \
|
|
|
|
--otlp-endpoint http://localhost:4317 \
|
2024-08-07 09:23:12 +03:00
|
|
|
--authn-config-path static/auth/auth_config.json \
|
2024-07-23 14:43:29 +03:00
|
|
|
--metadata-path crates/engine/tests/schema.json \
|
|
|
|
--expose-internal-errors | ts "engine: " &
|
|
|
|
wait
|
|
|
|
|
2024-04-03 11:03:18 +03:00
|
|
|
# start all the docker deps for running tests (not engine)
|
2024-03-28 13:26:32 +03:00
|
|
|
start-docker-test-deps:
|
2024-03-12 18:26:31 +03:00
|
|
|
# start connectors and wait for health
|
Make tests run over both the ndc v0.1.x and v0.2.x custom connectors (#879)
This PR updates as many tests as possible that use the custom connector
so that the tests run over two versions of the custom connector:
1. The custom connector in the repo, which currently speaks `ndc_models`
v0.2.x
2. The custom connector from the past (commit ), which is the last
version to speak `ndc_models` v0.1.x
This helps us test both the NDC v0.1.x and v0.2.x code paths. When the
postgres connector upgrades to v0.2.x, we can use the same approach as
in this PR to get the tests to run over multiple versions of the
postgres connector too, for much better coverage. This approach with the
custom connector will become less useful over time as the v0.1.x
connector is not updated and will diverge in data from the v0.2.x
connector. The postgres connector is likely to be longer-lasting, as it
is more stable.
The basic test used for `execute` integration tests is
`test_execution_expectation` (in `crates/engine/tests/common.rs`) and it
has been extended into a version called
`test_execution_expectation_for_multiple_ndc_versions` that takes
metadata on a per NDC version basis and then runs the test multiple
times, once for each NDC version. This allows one to swap out the
DataConnectorLink involved in the test to a different one that points at
either the v0.1.x or v0.2.x versions of the connector. The assertion is
that both connectors should produce the same results, even if they talk
a different version of the NDC protocol. As each version runs, we
`println!` the version so that if the test fails you can look in stdout
for the test and see which one was executing when it failed.
Tests that use the custom connector now use
`test_execution_expectation_for_multiple_ndc_versions` and run across
both connector versions. Some tests were unable to be used across both
version as the data between the two versions has changed. Some tests
were modified to avoid the changed data so as to support running across
both versions. Any tests that use `test_execution_expectation_legacy`
don't run across both versions because those tests aren't backed by the
same test implementation as
`test_execution_expectation_for_multiple_ndc_versions`.
Unfortunately the custom connector doesn't use the standard connector
SDK, so it doesn't support `HASURA_CONNECTOR_PORT`. This means that the
old connector is stuck on 8101. To work around this, I've moved the
current connector port to 8102 instead. Technically we might be able to
use docker to remap the ports, but then this binds us into always
running the connectors in docker in order to move their ports around, so
I avoided that approach.
Completes APIPG-703
V3_GIT_ORIGIN_REV_ID: fb0e410ddbee0ea699815388bc63584d6ff5dd70
2024-07-25 16:31:16 +03:00
|
|
|
docker compose -f ci.docker-compose.yaml up --wait postgres postgres_connector custom_connector custom_connector_ndc_v01
|
2024-03-12 18:26:31 +03:00
|
|
|
|
2024-03-28 13:26:32 +03:00
|
|
|
# start all the docker run time deps for the engine
|
|
|
|
start-docker-run-deps:
|
|
|
|
# start auth_hook and jaeger
|
|
|
|
docker compose up --wait auth_hook jaeger
|
|
|
|
|
2024-04-03 14:50:56 +03:00
|
|
|
# pull / build all docker deps
|
|
|
|
docker-refresh:
|
|
|
|
docker compose -f ci.docker-compose.yaml pull postgres_connector
|
|
|
|
docker compose -f ci.docker-compose.yaml build custom_connector
|
|
|
|
|
2024-03-12 18:26:31 +03:00
|
|
|
# stop all the docker deps
|
|
|
|
stop-docker:
|
|
|
|
docker compose -f ci.docker-compose.yaml down -v
|
2024-03-28 13:26:32 +03:00
|
|
|
docker compose down -v
|
2024-03-12 18:26:31 +03:00
|
|
|
|
|
|
|
# run the tests using local engine (once)
|
2024-07-25 19:15:52 +03:00
|
|
|
test *ARGS: start-docker-test-deps
|
2024-05-31 17:10:36 +03:00
|
|
|
#!/usr/bin/env bash
|
|
|
|
if command -v cargo-nextest; then
|
|
|
|
COMMAND=(cargo nextest run)
|
|
|
|
else
|
|
|
|
COMMAND=(cargo test)
|
|
|
|
fi
|
|
|
|
COMMAND+=(--no-fail-fast "$@")
|
|
|
|
echo "${COMMAND[*]}"
|
|
|
|
"${COMMAND[@]}"
|
2024-03-12 18:26:31 +03:00
|
|
|
|
|
|
|
# run a watch process that runs the tests locally
|
2024-07-25 19:15:52 +03:00
|
|
|
watch: start-docker-test-deps start-docker-run-deps
|
2024-03-29 09:36:19 +03:00
|
|
|
RUST_LOG=DEBUG \
|
2024-06-27 21:43:43 +03:00
|
|
|
cargo watch -i "**/*.snap.new" \
|
2024-05-07 13:13:38 +03:00
|
|
|
-x test \
|
2024-04-08 13:13:26 +03:00
|
|
|
-x 'clippy --no-deps' \
|
2024-03-29 09:36:19 +03:00
|
|
|
-x 'run --bin engine -- \
|
|
|
|
--otlp-endpoint http://localhost:4317 \
|
2024-08-07 09:23:12 +03:00
|
|
|
--authn-config-path static/auth/auth_config.json \
|
2024-06-27 15:42:27 +03:00
|
|
|
--metadata-path crates/engine/tests/schema.json \
|
|
|
|
--expose-internal-errors'
|
2024-03-13 14:14:07 +03:00
|
|
|
|
|
|
|
# check the code is fine
|
2024-07-25 19:15:52 +03:00
|
|
|
lint:
|
2024-05-28 11:50:46 +03:00
|
|
|
cargo clippy --all-targets --no-deps
|
2024-06-04 17:14:54 +03:00
|
|
|
! command -v nix || nix flake check
|
2024-03-12 18:26:31 +03:00
|
|
|
|
2024-03-28 12:16:54 +03:00
|
|
|
# ensure we don't have unused dependencies:
|
|
|
|
machete:
|
|
|
|
cargo machete --with-metadata
|
|
|
|
|
2024-03-15 16:05:32 +03:00
|
|
|
# update golden tests
|
2024-07-25 19:15:52 +03:00
|
|
|
update-golden-files: start-docker-test-deps
|
2024-06-17 22:15:16 +03:00
|
|
|
UPDATE_GOLDENFILES=1 cargo test
|
2024-05-02 11:43:16 +03:00
|
|
|
just fix-format
|
2024-03-15 16:05:32 +03:00
|
|
|
|
2024-07-11 17:15:12 +03:00
|
|
|
update-custom-connector-schema-in-test-metadata: && fix-format
|
|
|
|
#!/usr/bin/env bash
|
|
|
|
set -e
|
|
|
|
docker compose -f ci.docker-compose.yaml up --build --wait custom_connector
|
|
|
|
|
Make tests run over both the ndc v0.1.x and v0.2.x custom connectors (#879)
This PR updates as many tests as possible that use the custom connector
so that the tests run over two versions of the custom connector:
1. The custom connector in the repo, which currently speaks `ndc_models`
v0.2.x
2. The custom connector from the past (commit ), which is the last
version to speak `ndc_models` v0.1.x
This helps us test both the NDC v0.1.x and v0.2.x code paths. When the
postgres connector upgrades to v0.2.x, we can use the same approach as
in this PR to get the tests to run over multiple versions of the
postgres connector too, for much better coverage. This approach with the
custom connector will become less useful over time as the v0.1.x
connector is not updated and will diverge in data from the v0.2.x
connector. The postgres connector is likely to be longer-lasting, as it
is more stable.
The basic test used for `execute` integration tests is
`test_execution_expectation` (in `crates/engine/tests/common.rs`) and it
has been extended into a version called
`test_execution_expectation_for_multiple_ndc_versions` that takes
metadata on a per NDC version basis and then runs the test multiple
times, once for each NDC version. This allows one to swap out the
DataConnectorLink involved in the test to a different one that points at
either the v0.1.x or v0.2.x versions of the connector. The assertion is
that both connectors should produce the same results, even if they talk
a different version of the NDC protocol. As each version runs, we
`println!` the version so that if the test fails you can look in stdout
for the test and see which one was executing when it failed.
Tests that use the custom connector now use
`test_execution_expectation_for_multiple_ndc_versions` and run across
both connector versions. Some tests were unable to be used across both
version as the data between the two versions has changed. Some tests
were modified to avoid the changed data so as to support running across
both versions. Any tests that use `test_execution_expectation_legacy`
don't run across both versions because those tests aren't backed by the
same test implementation as
`test_execution_expectation_for_multiple_ndc_versions`.
Unfortunately the custom connector doesn't use the standard connector
SDK, so it doesn't support `HASURA_CONNECTOR_PORT`. This means that the
old connector is stuck on 8101. To work around this, I've moved the
current connector port to 8102 instead. Technically we might be able to
use docker to remap the ports, but then this binds us into always
running the connectors in docker in order to move their ports around, so
I avoided that approach.
Completes APIPG-703
V3_GIT_ORIGIN_REV_ID: fb0e410ddbee0ea699815388bc63584d6ff5dd70
2024-07-25 16:31:16 +03:00
|
|
|
new_capabilities=$(curl http://localhost:8102/capabilities | jq)
|
|
|
|
new_schema=$(curl http://localhost:8102/schema | jq)
|
2024-07-16 04:52:56 +03:00
|
|
|
ndc_version="v0.2"
|
2024-07-11 17:15:12 +03:00
|
|
|
|
|
|
|
# Should only be tests that actually talk to the running connector and therefore must be up to date
|
|
|
|
test_directories=(./crates/engine/tests/execute)
|
|
|
|
|
|
|
|
find "${test_directories[@]}" -name '*.json' -print0 |
|
|
|
|
while IFS= read -r -d '' file; do
|
|
|
|
# Check if the file actually contains a custom connector DataConnectorLink
|
|
|
|
if jq -e '
|
|
|
|
(. | type == "object") and has("subgraphs") and (.subgraphs | length > 0) and (.subgraphs[] | has("objects") and (.objects | length > 0))
|
Make tests run over both the ndc v0.1.x and v0.2.x custom connectors (#879)
This PR updates as many tests as possible that use the custom connector
so that the tests run over two versions of the custom connector:
1. The custom connector in the repo, which currently speaks `ndc_models`
v0.2.x
2. The custom connector from the past (commit ), which is the last
version to speak `ndc_models` v0.1.x
This helps us test both the NDC v0.1.x and v0.2.x code paths. When the
postgres connector upgrades to v0.2.x, we can use the same approach as
in this PR to get the tests to run over multiple versions of the
postgres connector too, for much better coverage. This approach with the
custom connector will become less useful over time as the v0.1.x
connector is not updated and will diverge in data from the v0.2.x
connector. The postgres connector is likely to be longer-lasting, as it
is more stable.
The basic test used for `execute` integration tests is
`test_execution_expectation` (in `crates/engine/tests/common.rs`) and it
has been extended into a version called
`test_execution_expectation_for_multiple_ndc_versions` that takes
metadata on a per NDC version basis and then runs the test multiple
times, once for each NDC version. This allows one to swap out the
DataConnectorLink involved in the test to a different one that points at
either the v0.1.x or v0.2.x versions of the connector. The assertion is
that both connectors should produce the same results, even if they talk
a different version of the NDC protocol. As each version runs, we
`println!` the version so that if the test fails you can look in stdout
for the test and see which one was executing when it failed.
Tests that use the custom connector now use
`test_execution_expectation_for_multiple_ndc_versions` and run across
both connector versions. Some tests were unable to be used across both
version as the data between the two versions has changed. Some tests
were modified to avoid the changed data so as to support running across
both versions. Any tests that use `test_execution_expectation_legacy`
don't run across both versions because those tests aren't backed by the
same test implementation as
`test_execution_expectation_for_multiple_ndc_versions`.
Unfortunately the custom connector doesn't use the standard connector
SDK, so it doesn't support `HASURA_CONNECTOR_PORT`. This means that the
old connector is stuck on 8101. To work around this, I've moved the
current connector port to 8102 instead. Technically we might be able to
use docker to remap the ports, but then this binds us into always
running the connectors in docker in order to move their ports around, so
I avoided that approach.
Completes APIPG-703
V3_GIT_ORIGIN_REV_ID: fb0e410ddbee0ea699815388bc63584d6ff5dd70
2024-07-25 16:31:16 +03:00
|
|
|
and any(.subgraphs[].objects[]; .kind == "DataConnectorLink" and .definition.url.singleUrl.value == "http://localhost:8102")' "$file" >/dev/null; then
|
2024-07-11 17:15:12 +03:00
|
|
|
|
|
|
|
# Update its schema, capabilities and version
|
|
|
|
jq --argjson newCapabilities "$new_capabilities" --argjson newSchema "$new_schema" --arg ndcVersion "$ndc_version" '
|
Make tests run over both the ndc v0.1.x and v0.2.x custom connectors (#879)
This PR updates as many tests as possible that use the custom connector
so that the tests run over two versions of the custom connector:
1. The custom connector in the repo, which currently speaks `ndc_models`
v0.2.x
2. The custom connector from the past (commit ), which is the last
version to speak `ndc_models` v0.1.x
This helps us test both the NDC v0.1.x and v0.2.x code paths. When the
postgres connector upgrades to v0.2.x, we can use the same approach as
in this PR to get the tests to run over multiple versions of the
postgres connector too, for much better coverage. This approach with the
custom connector will become less useful over time as the v0.1.x
connector is not updated and will diverge in data from the v0.2.x
connector. The postgres connector is likely to be longer-lasting, as it
is more stable.
The basic test used for `execute` integration tests is
`test_execution_expectation` (in `crates/engine/tests/common.rs`) and it
has been extended into a version called
`test_execution_expectation_for_multiple_ndc_versions` that takes
metadata on a per NDC version basis and then runs the test multiple
times, once for each NDC version. This allows one to swap out the
DataConnectorLink involved in the test to a different one that points at
either the v0.1.x or v0.2.x versions of the connector. The assertion is
that both connectors should produce the same results, even if they talk
a different version of the NDC protocol. As each version runs, we
`println!` the version so that if the test fails you can look in stdout
for the test and see which one was executing when it failed.
Tests that use the custom connector now use
`test_execution_expectation_for_multiple_ndc_versions` and run across
both connector versions. Some tests were unable to be used across both
version as the data between the two versions has changed. Some tests
were modified to avoid the changed data so as to support running across
both versions. Any tests that use `test_execution_expectation_legacy`
don't run across both versions because those tests aren't backed by the
same test implementation as
`test_execution_expectation_for_multiple_ndc_versions`.
Unfortunately the custom connector doesn't use the standard connector
SDK, so it doesn't support `HASURA_CONNECTOR_PORT`. This means that the
old connector is stuck on 8101. To work around this, I've moved the
current connector port to 8102 instead. Technically we might be able to
use docker to remap the ports, but then this binds us into always
running the connectors in docker in order to move their ports around, so
I avoided that approach.
Completes APIPG-703
V3_GIT_ORIGIN_REV_ID: fb0e410ddbee0ea699815388bc63584d6ff5dd70
2024-07-25 16:31:16 +03:00
|
|
|
(.subgraphs[].objects[] | select(.kind == "DataConnectorLink" and .definition.url.singleUrl.value == "http://localhost:8102").definition.schema)
|
2024-07-11 17:15:12 +03:00
|
|
|
|= (.capabilities = $newCapabilities | .schema = $newSchema | .version = $ndcVersion)
|
|
|
|
' $file \
|
|
|
|
| sponge $file
|
|
|
|
|
|
|
|
echo "Updated $file"
|
|
|
|
else
|
|
|
|
echo "Skipping $file: Does not appear to be a metadata file with a custom connector"
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
|
|
|
|
docker compose -f ci.docker-compose.yaml down
|
|
|
|
|
2024-03-28 13:26:32 +03:00
|
|
|
# run the engine using schema from tests
|
2024-07-25 19:15:52 +03:00
|
|
|
run: start-docker-test-deps start-docker-run-deps
|
2024-03-28 13:26:32 +03:00
|
|
|
RUST_LOG=DEBUG cargo run --bin engine -- \
|
|
|
|
--otlp-endpoint http://localhost:4317 \
|
2024-08-07 09:23:12 +03:00
|
|
|
--authn-config-path static/auth/auth_config.json \
|
2024-06-27 15:42:27 +03:00
|
|
|
--metadata-path crates/engine/tests/schema.json \
|
|
|
|
--expose-internal-errors
|
2024-04-26 11:43:19 +03:00
|
|
|
|
|
|
|
# check the docker build works
|
2024-05-02 17:22:44 +03:00
|
|
|
build-docker-with-nix binary="engine":
|
2024-04-26 11:43:19 +03:00
|
|
|
#!/usr/bin/env bash
|
2024-05-02 17:22:44 +03:00
|
|
|
echo "$(tput bold)nix build .#{{ binary }}-docker | gunzip | docker load$(tput sgr0)"
|
|
|
|
gunzip < "$(nix build --no-warn-dirty --no-link --print-out-paths '.#{{ binary }}-docker')" | docker load
|
2024-04-26 11:43:19 +03:00
|
|
|
|
2024-05-02 17:22:44 +03:00
|
|
|
# check the arm64 docker build works
|
|
|
|
build-aarch64-docker-with-nix binary="engine":
|
2024-04-26 11:43:19 +03:00
|
|
|
#!/usr/bin/env bash
|
2024-05-02 17:22:44 +03:00
|
|
|
echo "$(tput bold)nix build .#{{ binary }}-docker-aarch64-linux | gunzip | docker load$(tput sgr0)"
|
|
|
|
gunzip < "$(nix build --no-warn-dirty --no-link --print-out-paths --system aarch64-linux '.#{{ binary }}-docker-aarch64-linux')" | docker load
|