So you can do:
```
$ HASURA_GRAPHQL_EE_LICENSE_KEY=... scripts/dev.sh graphql-engine-pro
```
along with the `--prof-*` modes etc.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8894
GitOrigin-RevId: 2257749b2936cbd3230beb23e774ac92989e2fbc
See this earlier iteration of this work for an example of the kind of report we're producing: #7664
And related work in this repo: github.com:hasura/graphql-bench-helper
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7923
GitOrigin-RevId: 99d2a55e2fb5b55f3f33e2570cfd0bc23e448e0c
`make run-oss-server` will now build the Console for OSS ("CE"), start PostgreSQL, and run a simply-configured server.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8652
GitOrigin-RevId: cada25e66fe216867ff331d597764e64aaf2dc19
I personally avoid having a checked-out `main` branch during development, so that I don't accidentally commit directly to it.
This change makes `nx` commands work without needing a local `main` branch, by referring directly to the origin's branch instead.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8516
GitOrigin-RevId: b81314709b967b3dadd397793b416d9e0b137c98
This adds linting and formatting of frontend code when running `make lint`, `make format`, or any of the variations.
I am adding this because I didn't know how to check the code and so I had to wait for CI to fail, which I found irritating.
In order to make this reasonable, I factored out `make` targets for building *frontend/node_modules*, so I could depend on them.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8463
GitOrigin-RevId: 71882ec90490efbf87d428d08eaec2ae849a0a36
We are seeing errors emitted from get-version.sh in some PRs, but it proceeds anyway, generating a nonsense version of "dev--".
Instead, let's fail fast so we can diagnose the issue.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8115
GitOrigin-RevId: bb8d25f0f56c807dbb9928b82e31c94d23d9d1f5
## Description
Adds `metadata.openapi.json` to version control. Adds a Buildkite job that verifies the spec is up-to-date on server changes, and fails the CI pipeline if not.
Adds scaffolding for a new Typescript project that consumes that OpenAPI spec, and produces Typescript types. This is adapted from the similar existing data connectors project in `dc-agents/dc-api-types/`. Generated code is *not* committed to version control. Instead there is a script to generate code on-demand at publishing time. There are plans to incorporate publishing the generated project to NPM using a forthcoming pipeline that the Console team is working on.
For the moment the Typescript project is under `metadata-api-types/typescript/`. The plan is to move the project in a future PR to the frontend sub-monorepo.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7525
GitOrigin-RevId: dc27a807e52af117636f3aa6c2c289a0be87ade1
Add some configurations for modern profiling modes, and integration into dev.sh
These require cabal 3.8 due to the use of `import`
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7671
GitOrigin-RevId: f793f64105cfd99fb51b247fa8bc050f6d4bd23e
The tests no longer need a fresh, clean database, so we don't need to spend the time spinning them up and shutting them down again.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7732
GitOrigin-RevId: f2b412f4a8c762ee6699bd1bec1eef89f7682712
We were previously using the Docker Compose file in the root directory
for manual testing _and_ the server API tests.
This splits them so we can e.g. add Yugabyte for easy manual testing.
In the future, this will also allow us to use ephemeral ports for API
test databases, while keeping the fixed ports for manual testing.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7524
GitOrigin-RevId: 7244e296b0ed0ace9782b6f44f321933a9d9a49d
On macOS, we use the `azure-sql-edge` image, which doesn't contain
`sqlcmd`. To work around this, we can use another container which _does_
contain the `sqlcmd` binary to verify that MS SQL Server is up.
This was also broken on Linux anyway.
This also updates the PostgreSQL image, in line with _databases.yaml_.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7204
GitOrigin-RevId: ad974cd353c348ec055a153cbba5cb39d85e0967
We currently have a fairly intricate way of running our PostgreSQL and MSSQL integration tests (not the API tests). By splitting them out, we can simplify this a lot. Most prominently, we can rely on Cabal to be our argument parser instead of writing our own.
We can also simplify how they're run in CI. They are currently (weirdly) run alongside the Python integration tests. This breaks them out into their own jobs for better visibility, and to avoid conflating the two.
The changes are as follows:
- The "unit" tests that rely on a running PostgreSQL database are extracted out to a new test directory so they can be run separately.
- Most of the `Main` module comes with them.
- We now refer to these as "integration" tests instead.
- Likewise for the "unit" tests that rely on a running MS SQL Server database. These are a little simpler and we can use `hspec-discover`, with a `SpecHook` to extract the connection string from an environment variable.
- Henceforth, these are the MS SQL Server integration tests.
- New CI jobs have been added for each of these.
- There wasn't actually a job for the MS SQL Server integration tests. It's pretty amazing they still run well.
- The "haskell-tests" CI job, which used to run the PostgreSQL integration tests, has been removed.
- The makefiles and contributing guide have been updated to run these.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6912
GitOrigin-RevId: 67bbe2941bba31793f63d04a9a693779d4463ee1
With the vague idea that we can eventually avoid publishing ports at all, at least in CI, while still having the flexibility to publish ports locally.
If we can get there, it should help with the issues we're seeing on CI, where ports are already allocated from previous runs and containers aren't properly cleaned up.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6836
GitOrigin-RevId: 1d636c73ae889e45e80ad52042c56daa1b9d5838
This regenerates _cabal.project.freeze_ using the new `--normalize` flag in _scripts/cabal-freeze-update.sh_. This flag simply skips the `cabal update` step.
I also added a section to preserve the liberal GHC version, as we currently run GHC v9.2.4.20220919 on CI, and most developers just run v9.2.4 locally. This can be removed once we upgrade to v9.2.5.
Finally, I have added a GitHub Action which ensures that the checked-in cabal.project.freeze file does not change upon re-normalization. As we don't run `cabal update`, this should be stable.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6815
GitOrigin-RevId: 8cd3b5f3bbe5c61d8d3f61dfcc93b9d7c278419f
This upgrades the version of Ormolu required by the HGE repository to v0.5.0.1, and reformats all code accordingly.
Ormolu v0.5 reformats code that uses infix operators. This is mostly useful, adding newlines and indentation to make it clear which operators are applied first, but in some cases, it's unpleasant. To make this easier on the eyes, I had to do the following:
* Add a few fixity declarations (search for `infix`)
* Add parentheses to make precedence clear, allowing Ormolu to keep everything on one line
* Rename `relevantEq` to `(==~)` in #6651 and set it to `infix 4`
* Add a few _.ormolu_ files (thanks to @hallettj for helping me get started), mostly for Autodocodec operators that don't have explicit fixity declarations
In general, I think these changes are quite reasonable. They mostly affect indentation.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6675
GitOrigin-RevId: cd47d87f1d089fb0bc9dcbbe7798dbceedcd7d83
This installs the ODBC Driver 18 for SQL Server in all our shipped Docker images, and update our tests and documentation accordingly.
This version supports arm64, and therefore can run natively (or via Docker) on macOS on aarch64.
`msodbcsql17` is still installed in production-targeted Docker images so that users do not _have_ to migrate to the new driver.
Nix expressions are packaged for the new driver, as it is not yet available in nixpkgs.
In this version, [the default encryption setting was changed from "no" to "yes"](https://techcommunity.microsoft.com/t5/sql-server-blog/odbc-driver-18-0-for-sql-server-released/ba-p/3169228). In addition, "mandatory" and "optional" were added as synonyms for "yes" and "no" respectively.
I have therefore modified all connection strings in tests to specify `Encrypt=optional` (and changed some from `Encrypt=no`). I chose "optional" rather than "no" because I feel it's more honest; these connection strings will work with or without an encrypted connection.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6241
GitOrigin-RevId: 959f88dd1f271ef06a3616bc46b358f364f6cdfd
This upgrades CI and anyone using Nix to HLint v3.4.1.
If you're not using Nix, this doesn't actually _do_ anything on your
local machine; it's just a suggestion.
It also applies a bunch of simple HLint refactors, using
`make lint-hs-fix`.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6324
GitOrigin-RevId: de8267e4909d6dcd3f83543188517f3aaeebc5f3
Now that we use the mssql-tools image for running `sqlcmd`, we no longer need this (or indeed use it very much).
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6152
GitOrigin-RevId: be8852a93889553c3ffd2ec00c0dda81b36c3d05
Improvements to the Nix configuration so that macOS is supported.
Microsoft SQL Server is still not supported (yet; I have something in mind there), but the rest works. You can still use Homebrew to install the SQL Server drivers.
I had to make the following changes:
* I updated nixpkgs, because it's been a while.
* I made `ODBCINSTINI` optional so that it's not loaded on macOS, as it depends on `msodbcsql17`, which is broken on macOS.
* I upgraded OpenSSL.
* I set `DYLD_LIBRARY_PATH` on macOS so GHC finds OpenSSL; otherwise, it uses the wrong version of `libcrypto`, and fails with a fun error:
> WARNING: ghc is loading libcrypto in an unsafe way
* I patched GHC to fix compilation on macOS (copied from https://github.com/NixOS/nixpkgs/pull/149942).
To test this out, you can run `nix develop` (or install [direnv][] and add `use flake` to _.envrc.local_), and then try building HGE in the shell provided.
Fair warning: GHC needs to be built, and takes _aaages_ the first time. If this becomes useful to others, we can set up a shared cache.
[direnv]: https://direnv.net/
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5989
GitOrigin-RevId: 7130738d47709c37778b31c134061758ce23e959
* Add `source=` directives.
* Quote variables.
* Don't export variables that can fail to assign; instead, export afterwards.
* Write HGE stderr to the log file.
* Fix warnings around the PIDs.
* Disable a couple of false positives.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6097
GitOrigin-RevId: ed1c696b8735cd5d63ba30b3105040a0a9eca63c
This makes a few changes to the test scripts and makefiles in order to make things simpler for the average Apple user.
First of all, we change the `wait_for_mysql` function to use "localhost", not "127.0.0.1", as this fixed an issue on my system when attempting to connect to the MySQL server.
Secondly, we split the SQL Server test image into two:
* The first is the server itself, which now automatically uses `azure-sql-edge` as the image if you are on an aarch64 chip and using the `make` commands.
* The second is the initialization script. Because `sqlcmd` is not available in the `azure-sql-edge` image on aarch64, we use a separate container based on `mssql-tools` to initialize the server.
The README has been updated.
Tested on both macOS/aarch64 (with other changes) and Linux/x86_64.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5986
GitOrigin-RevId: b16e079861dcbcc66773295c47d715e443b67eea
`spawn-dc-sqlite-agent` was incorrectly named, and the `start-dc-sqlite-agent` target was missing. In addition, we usually only make the `start-xyz` target public in `make help`, and so only that needs a comment.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5804
GitOrigin-RevId: 8064ce148d004ef73dbd8570ef30435423ede0a1
This means that if `remote_schemas/nodejs/package.json` changes, the
dependencies will be automatically reinstalled.
It also moves `package-lock.json` to the correct location (in the
directory in which we run `npm install`), and updates it.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5481
GitOrigin-RevId: f3fb431afd19de150f39ec2e4cb6572b896c870f
Making it easier to inject different ones later.
I also included a change to _.prettierignore_ so Visual Studio Code doesn't keep trying to reformat the JavaScript or YAML files in `server/tests-py`, as it can cause diffs to balloon for no obvious benefit.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5456
GitOrigin-RevId: bc6d548708160a328e1e61a00e19be8e124da025
It's about time.
To do this I had to check a few more boxes.
* I copied the flags from `graphql-engine.cabal` to the libraries in `server/lib`.
* I moved `Cacheable` instances of schema parser types beside the typeclass declaration.
* I removed imports of `Hasura.Prelude` from the tests, and rewrote them accordingly.
* I copied the `TestMonad` parse monad into `server/src-test/Hasura/GraphQL/Schema/RemoteTest.hs`, which was using it. I think this could be done with the real thing, but I tried replacing it with constraints and it messed with my head somewhat.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5311
GitOrigin-RevId: ebebcc50a16f2d517b7f730fe72410827ca3e86c
I'm trying to shore up the Python integration tests to make them more reliable. In doing so, I noticed this.
---
This ensures that the data directories are always in a mutable file system, and not going through overlayfs.
In my testing, this sped up PostgreSQL database initialization a lot. In particular, `CREATE DATABASE` commands went from > 5s to < 0.1s.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5248
GitOrigin-RevId: 5104aea32c92559c323803020d727bebfdafb8e6
I'm trying to shore up the Python integration tests to make them more reliable. In doing so, I noticed this.
---
Rather than hard-coding hostnames and ports, we can (and already do) inject these into the HGE process using environment variables.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5255
GitOrigin-RevId: 6bb593999ece42cedef6619f31f9d9b2e39f30ef
