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 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 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
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
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
Docker Compose is now a plugin for Docker, bundled by default in Docker Desktop and many Linux distribution packages. The standalone `docker-compose` binary has been deprecated since Docker Compose v2.
Using the new version directly allows us to write development scripts that do not require `docker-compose` to be installed.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5185
GitOrigin-RevId: c8542b8b2405d1aa32288991688c6fde4af96383
We currently use `hpack` to generate the Cabal files from _package.yaml_
files for the two small libraries in _server/lib_. While this is more
convenient, we also check the Cabal files into the repository to avoid
needing an extra step upon pulling changes.
In order to ensure that the Cabal files do not get out of sync with the
hpack files, this introduces a few improvements:
1. Makefile targets to automatically generate the Cabal files without
needing to know the correct incantation. These targets are a
dependency of all build targets, so you can simply run
`make build-all` and it will work.
2. An extra comment at the top of all generated Cabal files that
explains how to regenerate it.
3. A `lint-hpack` Makefile target that verifies that the Cabal files
are up-to-date.
4. A CI job that runs `make lint-hpack`, to stop inconsistencies
getting merged into trunk.
Most of these changes are ported from #4794.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5217
GitOrigin-RevId: d3dfbe19ec00528368d357b6d0215a7ba4062f68
* Fix `make start-sqlserver` so it can find `sqlcmd`.
* Start the DC reference agent when testing all backends.
* Start backends in parallel so it doesn't take so long to spin them up. This is achieved by splitting all `start-*` tasks into `spawn-*` and `wait-for-*`.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5176
GitOrigin-RevId: ea483a755daa3fa6a8701f9d3dd0f393bc56510f
Rather than a homebrewed approach, we can use `make` to figure out when
it's necessary to regenerate our venv.
This Makefile will regenerate _requirements.txt_ from
_requirements-top-level.txt_ when the latter is changed.
It will also regenerate the venv when _requirements.txt_ is changed
(i.e. changes are pulled, or it's regenerated as described above).
`make` uses file/directory timestamps to figure out what to rebuild.
This is probably more reliable than expecting people to update a version
number whenever they change a file.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5152
GitOrigin-RevId: 24b27d49bf6c4ba1d57ac38ea38ae278216c6d66
