_(This PR is on top of #3352.)_
## Description
This PR overhauls our documentation CI steps to push all generated server documentation to the `gh-pages` branch of the OSS repo. The goal of this PR is to arrive in the situation where `https://hasura.github.io/graphql-engine/server/` is automatically populated to contain the following:
- all the markdown files from `server/documentation`, copied verbatim, no transformation applied
- all the notes, collected from the code by the `extract-notes.sh` script, in `server/notes`
- the generated haddock documentation for each major release or branch in `server/haddock`.
To do so, this PR does the following:
- it includes the script to extract notes from #3352,
- it rewrites the documentation checking CI step, to generate the notes and publish the resulting "server/documentation" folder,
- it includes a new CI step to deploy the documentation to the `gh-pages` branch
Of note:
- we will generate a different haddock folder for each main branch and release; in practice, that means the _main_, _stable_, _alpha_, _beta_ branches, and every build tagged with a version number
- the step that builds the haddock documentation checks that ALL projects in the repo build, including pro, but the deploy only deploys the graphql-engine documentation, as it pushes it to a publicly-accessible place
## Required work
**DO NOT MERGE THIS PR IT IS NOT READY**. Some work needs to go into this PR before it is ready.
First of all: the `gh-pages` branch of the OSS repo does NOT yet contain the documentation scaffolding that this new process assumes. At the bare minimum, it should be a orphan branch that contains a top-level README.md file, and a _server_ folder. An example of the bare minimum required can be previewed [on my fork](https://nicuveo.github.io/graphql-engine/server/).
The content of the `server/documentation` folder needs to be adjusted to reflect this; at the very least, a `README.md` file needs to be added to do the indexing (again, see the placeholder [on my fork](https://nicuveo.github.io/graphql-engine/server/) for an example).
This way of publishing documentation must be validated against [proposed changes to the documentation](https://github.com/hasura/graphql-engine-mono/pull/3294). @marionschleifer what do you think?
~~The buildkite code in this branch is currently untested, and I am not sure how to test it.~~
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3380
GitOrigin-RevId: b24f6759c64ae29886c1f1b481b172febc512032
### Description
The GraphQL spec has to conflicting requirements:
1. an object must contain at least one field: the schema may not contain empty objects
2. the _query_root_ must always be present
Given _1_, the schema generation code removes from the schema all fields that would result in empty objects, such as a table for which a user does not have select permissions. But, as a result, our code also potentially removes _query_root_ if it is empty, breaking _2_.
This PR introduces a dummy "placeholder" field in the query root if it's empty, to ensure we never remove it from the schema.
### Remaining work
- [x] changelog entry
- [x] tests
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/148
GitOrigin-RevId: bfd6bfcc2f3de92900b6ba566012f093399ca037
### Description
This PR is the result of a discussion in #3363. Namely, we would like to remove all uses of `unsafeMkName`, or at the very least document every single one of them, to avoid similar issues. To do so, this PR does the following:
- it adds a hlint suggestion not to use that function:
- suggestions don't mark the PR as failed, but will be shown at review time
- it is possible to disable that hint with `{- HLINT ignore myFunction "unsafe" -}`
- wherever possible, it removes uses of `unsafeMkName` in favour of `mkName`
- it adds a comment with a tracking issue for the two remaining uses:
- #3478
- #3479
### Remaining work
- discuss whether this hint should make the linter step fail, since the linter step isn't required to merge anyway, and there is a way to disable the hint wherever we think the use of that function is acceptable
- check that none of those uses were load-bearing and result in errors now
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3480
GitOrigin-RevId: 0a7e3e9d1a48185764c04ab61e34b58273af347c
## Description
When setting up a remote relationship to a remote schema, values coming from the left-hand side are given as _arguments_ to the targeted field of the remote schema. In turn, that means we need to adjust the arguments to that remote field; in the case of input objects, it means creating a brand new input object in which the relevant fields have been removed.
To both avoid conflicts, and be explicit, we give a pretty verbose name to such an input object: its original name, followed by "remote_rel", followed by the full name of the field (table name + relationship name). The bug there was introduced when working on extending remote relationships to other backends: we changed the code that translates the table name to a graphql identifier to be generic, and use the table's `ToTxt` instance instead. However, when a table is not in the default schema, the character used by that instance is `.`, which is not a valid GraphQL name.
This PR fixes it, by doing two things:
- it defines a safe function to translate LHS identifiers to graphql names (by replacing all invalid characters by `_`)
- it doesn't use `unsafeMkName` anymore, and checks at validation time that the type name is correct
## Further work
On this PR:
- [x] add a test
- [x] write a Changelog entry
Beyond this PR, we might want to:
- prioritize #1747
- analyze all calls to `unsafeMkName` and remove as many as possible
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3363
GitOrigin-RevId: fe98eb1d34157b2c8323af453f5c369de616af38
- I've made some stylistic changes to `Harness.Quoter.Yaml` so that the exposed API will appear at the top
- I've added a new expectation `shouldReturnOneOfYaml`, which can be helpful in testing non-deterministic results (by specifying all the possible valid results). Can be useful for https://github.com/hasura/graphql-engine-mono/issues/3458
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3492
GitOrigin-RevId: 71c1fe490f8a0717f2729efa2750d5d0034cec86
## Description
This PR adds a `defaultSourceMetadata` expression to each backend's harness file, and introduces `setSource` and `setSources` to factor out all the calls to `replace_metadata` in the tests.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3425
GitOrigin-RevId: 5eacb156ffa198123262759eb2bbdebe8ab09fd7
## Description
This PR adds a basic README file to `server/documentation`, in order to get something somewhat decent when we run the first automatic sync.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3468
GitOrigin-RevId: 10c3afc1ea02ee3eb914009e3b9ad22065c1db50
There's two major parts to this change:
1. cut down on environment variables needed to run the tests:
- lux parameters that don't change are now in code
- most remaining parameters have reasonable defaults
- the only variable that is still required to be set is HASURA_MULTITENANT_SPEC_DB_URL
- env.sh is no longer needed
2. find a better work-around for the problems running graphql-engine-multitenant
via cabal run (https://github.com/haskell/cabal/issues/7914), by adding a shell
script that implements a more correct version of cabal run.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3461
GitOrigin-RevId: 0939a79cc45cd3c1c103719552b12099678850dd
`test-server.sh` is largely concerned with running the python test suite in `server/tests-py`.
However, there are two odd test sets in there which don't belong, and make `test-server.sh`
awkward to work with.
One is `haskell-tests` (the "postgres" part of server unit tests), which we're not touching here.
The other is `test-server-flags`, which runs some shell script based tests against the command
line interface.
This commit moves `test-server-flags` out of `test-server.sh`, and into a separate buildkite step.
Reasons are largely:
- it doesn't belong with the python tests
- it doesn't need to run against various backends
The larger scope within which I'd place this change is that we
should aim to move the logic that's in test-server.sh to live closer
to server/tests-py and be shared between the local dev setup and
CI. There shouldn't be this much logic in CI scripts at all
(choosing with what flags to run graphql-engine, choosing which
arguments to pass to pytest, etc.).
This change hardly gets us there, but the way that test-server.sh
mixes concerns is one obstacle in ever getting away from the
current state.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3300
GitOrigin-RevId: a15300a1dd276fa9f0cc29ddbf4ba7497919a6ec
- call stop_services on exit
- update stop_services to wait for child PIDs the same way
kill_hge_servers already does
- update stop_services to also kill GQL_SERVER_PID, which
had been missed before
The important part is that we wait for graphql-engine children to exit
and finish writing their logs, even if a test case bailed out before
making it to kill_hge_servers.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3333
GitOrigin-RevId: 046bc0f424889a5de0a730fbde626ea6dcda8e1c
So far we've only used `hlint` to lint the OSS code. This moves some things around to lint the Pro code as well.
Note that the CI action only runs `hlint` on Haskell files that are _changed_ by a PR, relative to its merge-base (usually `main`).
As a reminder, you can use the `ignore-server-hlint-checks` label to prevent this from blocking a merge.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3383
GitOrigin-RevId: d5779c63d780f526a1d58ae4107f0d5262a23ec1
This coverage-related functionality has been inactive for a while, so
chances are it's rotted by now anyway. Removing in order to make
things a little bit simpler.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3299
GitOrigin-RevId: 1ac4d4e101fecca1931a099bdcb7ed4dce675575
