graphql-engine/server/lib/api-tests/api-tests.cabal

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

329 lines
9.7 KiB
Plaintext
Raw Normal View History

cabal-version: 2.2
name: api-tests
version: 1.0.0
build-type: Simple
copyright: Hasura Inc.
extra-source-files: README.md
library
build-tool-depends: hspec-discover:hspec-discover
hs-source-dirs: src
default-language: GHC2021
ghc-options:
-Wall
-Werror
default-extensions:
BlockArguments
DataKinds
DeriveGeneric
DerivingStrategies
ImportQualifiedPost
LambdaCase
MultiWayIf
NamedFieldPuns
NoImplicitPrelude
OverloadedStrings
PatternGuards
QuasiQuotes
RecordWildCards
ScopedTypeVariables
TypeApplications
TypeFamilies
build-depends:
, HUnit
, aeson
, aeson-pretty
, base
, bytestring
, dc-api
, fast-logger
, graphql-parser
, hasura-prelude
, hspec
, hspec-core
, http-conduit
, http-types
, lens
, lens-aeson
, managed
, morpheus-graphql
, pg-client
, postgresql-simple
, postgres-options
, safe-exceptions
, split
, string-interpolate
, sop-core
, test-harness
, text
, unordered-containers
, uuid
, vector
exposed-modules:
Spec
SpecHook
Test.API.ConcurrentBulkSpec
Test.API.ExplainSpec
Test.API.Metadata.ComputedFieldsSpec
Test.API.Metadata.InconsistentSpec
Fix metadata defaults bug - Defaults serialised into metadata table - GDC-647 ## Description There is a bug in the metadata defaults code, see [the original PR](https://github.com/hasura/graphql-engine-mono/pull/6286). Steps to reproduce this issue: * Start a new HGE project * Start HGE with a defaults argument: `HASURA_GRAPHQL_LOG_LEVEL=debug cabal run exe:graphql-engine -- serve --enable-console --console-assets-dir=./console/static/dist --metadata-defaults='{"backend_configs": {"dataconnector": {"mongo": {"display_name": "BONGOBB", "uri": "http://localhost:8123"}}}}'` * Add a source (doesn't need to be related to the defaults) * Export metadata * See that the defaults are present in the exported metadata ## Related Issues * Github Issue: https://github.com/hasura/graphql-engine/issues/9237 * Jira: https://hasurahq.atlassian.net/browse/GDC-647 * Original PR: https://github.com/hasura/graphql-engine-mono/pull/6286 ## Solution * The test for if defaults should be included for metadata api operations has been extended to check for updates * Metadata inconsistencies have been hidden for `/capabilities` calls on startup ## TODO * [x] Fix bug * [x] Write tests * [x] OSS Metadata Migration to correct persisted data - `server/src-rsr/migrations/47_to_48.sql` * [x] Cloud Metadata Migration - `pro/server/res/cloud/migrations/6_to_7.sql` * [x] Bump Catalog Version - `server/src-rsr/catalog_version.txt` * [x] Update Catalog Versions - `server/src-rsr/catalog_versions.txt` (This will be done by Infra when creating a release) * [x] Log connection error as it occurs *(Already being logged. Requires `--enabled-log-types startup,webhook-log,websocket-log,http-log,data-connector-log`) * [x] Don't mark metadata inconsistencies for this call. ## Questions * [ ] Does the `pro/server/res/cloud/migrations/6_to_7.sql` cover the cloud scenarios? * [ ] Should we have `SET search_path` in migrations? * [x] What should be in `server/src-rsr/catalog_versions.txt`? ## Testing To test the solution locally run: > docker compose up -d and > cabal run -- exe:api-tests --skip BigQuery --skip SQLServer --skip '/Test.API.Explain/Postgres/' ## Solution In `runMetadataQuery` in `server/src-lib/Hasura/Server/API/Metadata.hs`: ```diff - if (exportsMetadata _rqlMetadata) + if (exportsMetadata _rqlMetadata || queryModifiesMetadata _rqlMetadata) ``` This ensures that defaults aren't present in operations that serialise metadata. Note: You might think that `X_add_source` would need the defaults to be present to add a source that references the defaults, but since the resolution occurs in the schema-cache building phase, the defaults can be excluded for the metadata modifications required for `X_add_source`. In addition to the code-change, a metadata migration has been introduced in order to clean up serialised defaults. The following scenarios need to be considered for both OSS and Cloud: * The user has not had defaults serialised * The user has had the defaults serialised and no other backends configured * The user has had the defaults serialised and has also configured other backends We want to remove as much of the metadata as possible without any user-specified data and this should be reflected in migration `server/src-rsr/migrations/47_to_48.sql`. ## Server checklist ### Catalog upgrade Does this PR change Hasura Catalog version? - ✅ Yes ### Metadata Does this PR add a new Metadata feature? - ✅ No ### GraphQL - ✅ No new GraphQL schema is generated ### Breaking changes - ✅ No Breaking changes ## Changelog __Component__ : server __Type__: bugfix __Product__: community-edition ### Short Changelog Fixes a metadata defaults serialization bug and introduces a metadata migration to correct data that has been persisted due to the bug. PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7034 GitOrigin-RevId: ad7d4f748397a1a607f2c0c886bf0fbbc3f873f2
2022-12-07 01:33:54 +03:00
Test.API.Metadata.TransparentDefaultsSpec
Test.API.Schema.RunSQLSpec
Test.Auth.Authorization.DisableRootFields.Common
Test.Auth.Authorization.DisableRootFields.DefaultRootFieldsSpec
Test.Auth.Authorization.DisableRootFields.SelectPermission.DisableAllRootFieldsSpec
Test.Auth.Authorization.DisableRootFields.SelectPermission.EnableAggSpec
Test.Auth.Authorization.DisableRootFields.SelectPermission.EnableAllRootFieldsSpec
Test.Auth.Authorization.DisableRootFields.SelectPermission.EnablePKSpec
Test.Auth.Authorization.DisableRootFields.SelectPermission.RelationshipSpec
Test.Databases.BigQuery.Queries.SpatialTypesSpec
Test.Databases.BigQuery.Queries.TypeInterpretationSpec
Test.Databases.BigQuery.Schema.ComputedFields.TableSpec
Test.Databases.Postgres.BackendOnlyPermissionsSpec
Test.Databases.Postgres.DataValidation.PermissionSpec
Test.Databases.Postgres.JsonbSpec
Test.Databases.Postgres.TimestampSpec
Test.Databases.Postgres.UniqueConstraintsSpec
Test.Databases.SQLServer.DefaultValues.OnConflictSpec
Test.Databases.SQLServer.InsertVarcharColumnSpec
Test.Databases.SQLServer.VarcharLiteralsSpec
Test.DataConnector.AggregateQuerySpec
Test.DataConnector.MetadataApiSpec
Test.DataConnector.MockAgent.AggregateQuerySpec
Test.DataConnector.MockAgent.BasicQuerySpec
Test.DataConnector.MockAgent.CustomScalarsSpec
Test.DataConnector.MockAgent.ErrorSpec
Test.DataConnector.MockAgent.MetadataApiSpec
Test.DataConnector.MockAgent.QueryRelationshipsSpec
Test.DataConnector.MockAgent.TransformedConfigurationSpec
Test.DataConnector.QuerySpec
Test.DataConnector.SelectPermissionsSpec
Test.EventTriggers.MSSQL.EventTriggerDropSourceCleanupSpec
server: provide an option to enable event triggers on logically replicated tables ## Description ✍️ This PR introduces a new feature to enable/disable event triggers during logical replication of table data for PostgreSQL and MS-SQL data sources. We introduce a new field `trigger_on_replication` in the `*_create_event_trigger` metadata API. By default the event triggers will not fire for logical data replication. ## Changelog ✍️ __Component__ : server __Type__: feature __Product__: community-edition ### Short Changelog Add option to enable/disable event triggers on logically replicated tables ### Related Issues ✍ https://github.com/hasura/graphql-engine/issues/8814 https://hasurahq.atlassian.net/browse/GS-252 ### Solution and Design - By default, triggers do **not** fire when the session mode is `replica` in Postgres, so if the `triggerOnReplication` is set to `true` for an event trigger we run the query `ALTER TABLE #{tableTxt} ENABLE ALWAYS TRIGGER #{triggerNameTxt};` so that the trigger fires always irrespective of the `session_replication_role` - By default, triggers do fire in case of replication in MS-SQL, so if the `triggerOnReplication` is set to `false` for an event trigger we add a clause `NOT FOR REPLICATION` to the the SQL when the trigger is created/altered, which sets the `is_not_for_replication` for the trigger as `true` and it does not fire during logical replication. ### Steps to test and verify ✍ - Run hspec integration tests for HGE ## Server checklist ✍ ### Metadata ✍ Does this PR add a new Metadata feature? - ✅ Yes - Does `export_metadata`/`replace_metadata` supports the new metadata added? - ✅ PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6953 Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com> Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com> GitOrigin-RevId: 92731328a2bbdcad2302c829f26f9acb33c36135
2022-11-29 20:41:41 +03:00
Test.EventTriggers.MSSQL.EventTriggersForReplicationSpec
Test.EventTriggers.MSSQL.EventTriggersUniqueNameSpec
Test.EventTriggers.MSSQL.EventTriggersNameQuotingSpec
Test.EventTriggers.MSSQL.EventTriggersUntrackTableCleanupSpec
Test.EventTriggers.PG.EventTriggersExtensionSchemaSpec
Test.EventTriggers.PG.EventTriggersForReplicationSpec
Test.EventTriggers.PG.EventTriggersRecreationSpec
Test.EventTriggers.PG.EventTriggersReplaceMetadataCleanupSpec
Test.EventTriggers.PG.EventTriggersRunSQLSpec
Test.EventTriggers.PG.EventTriggersUniqueNameSpec
Test.EventTriggers.PG.EventTriggersUntrackTableCleanupSpec
Test.Harness.Quoter.YamlSpec
Test.HelloWorldSpec
Test.Mutations.Delete.AllSpec
Test.Mutations.Delete.FieldSpec
Test.Mutations.Delete.NestedFieldSpec
Test.Mutations.Delete.PrimaryKeySpec
Test.Mutations.Insert.MultipleSpec
Test.Mutations.Insert.SingleSpec
Test.Mutations.MultiplePerRequest.UpdateManySpec
Test.Mutations.Update.FieldSpec
Test.Mutations.Update.PrimaryKeySpec
Test.Mutations.Upsert.OnConflictSpec
server: use kriti template to generate query param from list ## Description ✍️ This PR adds support to generate query params directly using a kriti template which can be used to flatten a list of parameter arguments as well. ### Changes in the Metadata API Earlier the `query_params` key inside `request_transform` used to take in an object of key/value pairs where the `key` represents the query parameter name and `value` points to the value of the parameter or a kriti template which could be resolved to the value. With this PR, we provide the user with more freedom to generate the complete query string using kriti template. The `query_params` can now take in a string as well which will be a kriti template. This new change needs to be incorporated on the console and CLI metadata import/export as well. - [x] CLI: Compatible, no changes required - [ ] Console ## Changelog ✍️ __Component__ : server __Type__: feature __Product__: community-edition ### Short Changelog use kriti template to generate query param from list of arguments ### Related Issues ✍ https://hasurahq.atlassian.net/browse/GS-243 ### Solution and Design ✍ We use a kriti template to generate the complete query parameter string. | Query Template | Output | |---|---| | `{{ concat ([concat({{ range _, x := [\"apple\", \"banana\"] }} \"tags={{x}}&\" {{ end }}), \"flag=smthng\"]) }}`| `tags=apple&tags=banana&flag=smthng` | | `{{ concat ([\"tags=\", concat({{ range _, x := $body.input }} \"{{x}},\" {{ end }})]) }}` | `tags=apple%2Cbanana%2C` | ### Steps to test and verify ✍ - start HGE and make the following request to `http://localhost:8080/v1/metadata`: ```json { "type": "test_webhook_transform", "args": { "webhook_url": "http://localhost:3000", "body": { "action": { "name": "actionName" }, "input": ["apple", "banana"] }, "request_transform": { "version": 2, "url": "{{$base_url}}", "query_params": "{{ concat ([concat({{ range _, x := $body.input }} \"tags={{x}}&\" {{ end }}), \"flag=smthng\"]) }}", "template_engine": "Kriti" } } } ``` - you should receive the following as output: ```json { "body": { "action": { "name": "actionName" }, "input": [ "apple", "banana" ] }, "headers": [], "method": "GET", "webhook_url": "http://localhost:3000?tags=apple&tags=banana&flag=smthng" } ``` PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6961 Co-authored-by: Tirumarai Selvan <8663570+tirumaraiselvan@users.noreply.github.com> GitOrigin-RevId: 712ba038f03009edc3e8eb0435e723304943399a
2022-11-29 23:26:04 +03:00
Test.PortedFromPytest.TestGraphQLQueryBasicCitus
Test.PortedFromPytest.TestGraphQLQueryFunctions
Test.Queries.AggregationSpec
Test.Queries.CustomFunctions.PortedSpec
Test.Queries.DistinctSpec
Test.Queries.FilterSearch.AggregationPredicatesSpec
Test.Queries.FilterSearch.FilterSearchSpec
Test.Queries.NestedObjectSpec
Test.Queries.Paginate.LimitSpec
Test.Queries.Paginate.OffsetSpec
Test.Queries.Simple.InvalidQuerySpec
Test.Queries.Simple.MissingTableSpec
Test.Queries.Simple.NoQueriesAvailableSpec
Test.Queries.Simple.ObjectQueriesSpec
Test.Queries.Simple.OperationNameSpec
Test.Queries.Simple.PrimaryKeySpec
Test.Queries.SortSpec
Test.Queries.VariablesAliasesFragments.AliasesSpec
Test.Queries.VariablesAliasesFragments.Directives.DirectivesSpec
Test.Queries.VariablesAliasesFragments.Directives.IncludeAndSkipSpec
Test.Queries.VariablesAliasesFragments.Directives.IncludeSpec
Test.Queries.VariablesAliasesFragments.Directives.SkipSpec
Test.Queries.VariablesAliasesFragments.FragmentsSpec
Test.Queries.VariablesAliasesFragments.VariablesSpec
Test.Regression.AggregateBoolExpConflictSpec
Test.Regression.ArrayLiteralTextEncodingSpec
Test.Regression.DoNotTruncateSessionVariables8158Spec
Test.Regression.DropColumnWithPermissions8415Spec
Test.Regression.InsertOnConflict8260Spec
Test.Regression.LongIdentifiers3796Spec
Test.Regression.MultiColumnObjectRelationshipsSpec
[server] prune join fields of remote relationships to remote schema (close hasura/graphql-engine#8345) ## Description This PR fixes hasura/graphql-engine#8345: when creating the final representation of a remote relationship to a remote schema (a `RemoteJoin`), we would mistakenly label ALL join fields in the selection set as being relevant to that one relationship: if there are more than one remote relationship to process in that selection set, that would be the union of all their join fields. The problem with this error is that, when processing remote relationships, we correctly ignore all the ones for which at least one join key is null. Consequently, this error would result in us ignoring remote relationships for which an _unrelated_ join key was null, resulting in that data missing in the final JSON result. This PR simply ensures that the aggregation of fields that are passed to `createRemoteJoin` is pruned to only contain the fields relevant to the join being created. This is a very small change, and the bulk of this PR is the regression tests. ## Changelog __Component__ : server __Type__: bugfix __Product__: community-edition ### Short Changelog fix remote relationship to remote schema sometimes being erroneously null when multiple relationships are defined on the same table / graphql object ([#8345](https://github.com/hasura/graphql-engine/issues/8345)) ### Long Changelog PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6420 GitOrigin-RevId: eb54462724b007f80b674dcf234adf6d9cfaaf79
2022-10-20 03:10:26 +03:00
Test.Regression.NullRemoteRelationship8345Spec
Test.Regression.NullsOrderParsing8780Spec
Test.Regression.ObjectRelationshipsLimit7936Spec
Test.Regression.RemoteRelationshipStringifyNum8387Spec
Test.Regression.StreamConflictSpec
Test.Regression.UsingTheSameFunctionForRootFieldAndComputedField8643Spec
Test.Regression.MultiplexQuerySpec
Test.Schema.ComputedFields.ScalarSpec
Test.Schema.ComputedFields.TableSpec
Test.Schema.ConflictsSpec
Test.Schema.CustomFieldNames.MutationSpec
Test.Schema.CustomFieldNames.QuerySpec
Test.Schema.CustomFieldsSpec
Test.Schema.DataValidations.Permissions.InsertSpec
Test.Schema.DataValidations.Permissions.SelectSpec
Test.Schema.DataValidations.Permissions.UpdateSpec
Test.Schema.DefaultValues.DefaultValuesSpec
Test.Schema.DefaultValues.OnConflictSpec
Test.Schema.EnumsSpec
Test.Schema.RemoteRelationships.FromRemoteSchemaSpec
Test.Schema.RemoteRelationships.MetadataAPI.ClearMetadataSpec
Test.Schema.RemoteRelationships.MetadataAPI.Common
Test.Schema.RemoteRelationships.MetadataAPI.DropSource.DBtoDBRelationshipSpec
Test.Schema.RemoteRelationships.MetadataAPI.DropSource.RSToDBRelationshipSpec
Test.Schema.RemoteRelationships.XToDBArrayRelationshipSpec
Test.Schema.RemoteRelationships.XToDBObjectRelationshipSpec
Test.Schema.RemoteRelationships.XToRemoteSchemaRelationshipSpec
Test.Schema.RemoteSchemaCustomizationSpec
Test.Schema.TableRelationships.ArrayRelationshipsSpec
Test.Schema.TableRelationships.ObjectRelationshipsSpec
Test.Schema.TableRelationships.PortedSpec
Test.Schema.ViewsSpec
Test.Subscriptions.DerivedDataSpec
Test.Subscriptions.RowUpdatesSpec
Test.Subscriptions.StreamingSubscriptionsSpec
server: use kriti template to generate query param from list ## Description ✍️ This PR adds support to generate query params directly using a kriti template which can be used to flatten a list of parameter arguments as well. ### Changes in the Metadata API Earlier the `query_params` key inside `request_transform` used to take in an object of key/value pairs where the `key` represents the query parameter name and `value` points to the value of the parameter or a kriti template which could be resolved to the value. With this PR, we provide the user with more freedom to generate the complete query string using kriti template. The `query_params` can now take in a string as well which will be a kriti template. This new change needs to be incorporated on the console and CLI metadata import/export as well. - [x] CLI: Compatible, no changes required - [ ] Console ## Changelog ✍️ __Component__ : server __Type__: feature __Product__: community-edition ### Short Changelog use kriti template to generate query param from list of arguments ### Related Issues ✍ https://hasurahq.atlassian.net/browse/GS-243 ### Solution and Design ✍ We use a kriti template to generate the complete query parameter string. | Query Template | Output | |---|---| | `{{ concat ([concat({{ range _, x := [\"apple\", \"banana\"] }} \"tags={{x}}&\" {{ end }}), \"flag=smthng\"]) }}`| `tags=apple&tags=banana&flag=smthng` | | `{{ concat ([\"tags=\", concat({{ range _, x := $body.input }} \"{{x}},\" {{ end }})]) }}` | `tags=apple%2Cbanana%2C` | ### Steps to test and verify ✍ - start HGE and make the following request to `http://localhost:8080/v1/metadata`: ```json { "type": "test_webhook_transform", "args": { "webhook_url": "http://localhost:3000", "body": { "action": { "name": "actionName" }, "input": ["apple", "banana"] }, "request_transform": { "version": 2, "url": "{{$base_url}}", "query_params": "{{ concat ([concat({{ range _, x := $body.input }} \"tags={{x}}&\" {{ end }}), \"flag=smthng\"]) }}", "template_engine": "Kriti" } } } ``` - you should receive the following as output: ```json { "body": { "action": { "name": "actionName" }, "input": [ "apple", "banana" ] }, "headers": [], "method": "GET", "webhook_url": "http://localhost:3000?tags=apple&tags=banana&flag=smthng" } ``` PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6961 Co-authored-by: Tirumarai Selvan <8663570+tirumaraiselvan@users.noreply.github.com> GitOrigin-RevId: 712ba038f03009edc3e8eb0435e723304943399a
2022-11-29 23:26:04 +03:00
Test.Webhook.WebhookTransformSpec
executable api-tests
build-depends:
Fix metadata defaults bug - Defaults serialised into metadata table - GDC-647 ## Description There is a bug in the metadata defaults code, see [the original PR](https://github.com/hasura/graphql-engine-mono/pull/6286). Steps to reproduce this issue: * Start a new HGE project * Start HGE with a defaults argument: `HASURA_GRAPHQL_LOG_LEVEL=debug cabal run exe:graphql-engine -- serve --enable-console --console-assets-dir=./console/static/dist --metadata-defaults='{"backend_configs": {"dataconnector": {"mongo": {"display_name": "BONGOBB", "uri": "http://localhost:8123"}}}}'` * Add a source (doesn't need to be related to the defaults) * Export metadata * See that the defaults are present in the exported metadata ## Related Issues * Github Issue: https://github.com/hasura/graphql-engine/issues/9237 * Jira: https://hasurahq.atlassian.net/browse/GDC-647 * Original PR: https://github.com/hasura/graphql-engine-mono/pull/6286 ## Solution * The test for if defaults should be included for metadata api operations has been extended to check for updates * Metadata inconsistencies have been hidden for `/capabilities` calls on startup ## TODO * [x] Fix bug * [x] Write tests * [x] OSS Metadata Migration to correct persisted data - `server/src-rsr/migrations/47_to_48.sql` * [x] Cloud Metadata Migration - `pro/server/res/cloud/migrations/6_to_7.sql` * [x] Bump Catalog Version - `server/src-rsr/catalog_version.txt` * [x] Update Catalog Versions - `server/src-rsr/catalog_versions.txt` (This will be done by Infra when creating a release) * [x] Log connection error as it occurs *(Already being logged. Requires `--enabled-log-types startup,webhook-log,websocket-log,http-log,data-connector-log`) * [x] Don't mark metadata inconsistencies for this call. ## Questions * [ ] Does the `pro/server/res/cloud/migrations/6_to_7.sql` cover the cloud scenarios? * [ ] Should we have `SET search_path` in migrations? * [x] What should be in `server/src-rsr/catalog_versions.txt`? ## Testing To test the solution locally run: > docker compose up -d and > cabal run -- exe:api-tests --skip BigQuery --skip SQLServer --skip '/Test.API.Explain/Postgres/' ## Solution In `runMetadataQuery` in `server/src-lib/Hasura/Server/API/Metadata.hs`: ```diff - if (exportsMetadata _rqlMetadata) + if (exportsMetadata _rqlMetadata || queryModifiesMetadata _rqlMetadata) ``` This ensures that defaults aren't present in operations that serialise metadata. Note: You might think that `X_add_source` would need the defaults to be present to add a source that references the defaults, but since the resolution occurs in the schema-cache building phase, the defaults can be excluded for the metadata modifications required for `X_add_source`. In addition to the code-change, a metadata migration has been introduced in order to clean up serialised defaults. The following scenarios need to be considered for both OSS and Cloud: * The user has not had defaults serialised * The user has had the defaults serialised and no other backends configured * The user has had the defaults serialised and has also configured other backends We want to remove as much of the metadata as possible without any user-specified data and this should be reflected in migration `server/src-rsr/migrations/47_to_48.sql`. ## Server checklist ### Catalog upgrade Does this PR change Hasura Catalog version? - ✅ Yes ### Metadata Does this PR add a new Metadata feature? - ✅ No ### GraphQL - ✅ No new GraphQL schema is generated ### Breaking changes - ✅ No Breaking changes ## Changelog __Component__ : server __Type__: bugfix __Product__: community-edition ### Short Changelog Fixes a metadata defaults serialization bug and introduces a metadata migration to correct data that has been persisted due to the bug. PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7034 GitOrigin-RevId: ad7d4f748397a1a607f2c0c886bf0fbbc3f873f2
2022-12-07 01:33:54 +03:00
, lens-aeson
, api-tests
, base
, hspec
-- Turning off optimizations is intentional; tests aren't
-- performance sensitive and waiting for compilation is a problem.
ghc-options:
-Wall
-Werror
-threaded
-rtsopts "-with-rtsopts=-N"
default-language: GHC2021
hs-source-dirs: test-runner
main-is: Main.hs
library feature-matrix
build-depends:
, aeson
, attoparsec
, base
, bytestring
, containers
, lucid2
, mtl
, raw-strings-qq
, text
default-language: GHC2021
default-extensions:
BlockArguments
DataKinds
DeriveGeneric
DerivingStrategies
ImportQualifiedPost
LambdaCase
MultiWayIf
NamedFieldPuns
NoImplicitPrelude
OverloadedStrings
PatternGuards
QuasiQuotes
RecordWildCards
ScopedTypeVariables
TypeApplications
TypeFamilies
hs-source-dirs: src-feature-matrix
exposed-modules:
Hasura.FeatureMatrix
ghc-options:
-Wall
-Werror
executable render-feature-matrix
build-depends:
, base
, feature-matrix
, bytestring
default-language: GHC2021
default-extensions:
BlockArguments
DataKinds
DeriveGeneric
DerivingStrategies
ImportQualifiedPost
LambdaCase
MultiWayIf
NamedFieldPuns
NoImplicitPrelude
OverloadedStrings
PatternGuards
RecordWildCards
ScopedTypeVariables
TypeApplications
TypeFamilies
hs-source-dirs: app-render-feature-matrix
-- Turning off optimizations is intentional; tests aren't
-- performance sensitive and waiting for compilation is a problem.
ghc-options:
-Wall
-Werror
-threaded
-rtsopts "-with-rtsopts=-N"
main-is: Main.hs
executable produce-feature-matrix
build-depends:
, api-tests
, base
, bytestring
, directory
, fast-logger
, feature-matrix
, filepath
, hasura-prelude
, hspec
, optparse-generic
, postgres-options
, stm
, test-harness
default-language: GHC2021
default-extensions:
BlockArguments
DataKinds
LambdaCase
NoImplicitPrelude
OverloadedStrings
ExplicitNamespaces
OverloadedRecordDot
hs-source-dirs: app-produce-feature-matrix
-- Turning off optimizations is intentional; tests aren't
-- performance sensitive and waiting for compilation is a problem.
ghc-options:
-O0
-Wall
-Werror
-threaded
-rtsopts "-with-rtsopts=-N4"
main-is: Main.hs