(Work here originally done by awjchen, rebased and fixed up for merge by
jberryman)
This is part of a merge train towards GHC 9.2 compatibility. The main
issue is the use of the new abstract `KeyMap` in 2.0. See:
https://hackage.haskell.org/package/aeson-2.0.3.0/changelog
Alex's original work is here:
#4305
BEHAVIOR CHANGE NOTE: This change causes a different arbitrary ordering
of serialized Json, for example during metadata export. CLI users care
about this in particular, and so we need to call it out as a _behavior
change_ as we did in v2.5.0. The good news though is that after this
change ordering should be more stable (alphabetical key order).
See: https://hasurahq.slack.com/archives/C01M20G1YRW/p1654012632634389
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4611
Co-authored-by: awjchen <13142944+awjchen@users.noreply.github.com>
GitOrigin-RevId: 700265162c782739b2bb88300ee3cda3819b2e87
#### Issue: https://github.com/hasura/graphql-engine-mono/issues/2179
### Problem:
1. There are few warnings when tests are executed with cli if it is built with `race` flag
It is because of a race condition between stdin in migrate_delete for the prompt and stdout for other commands.
2. The integration test of the console used to behave as follows:
```
- Initially there won't be any wg.adds in wait-group so the second go-routine created in console-test (integration-test)
- It will send the interrupt signal to the channel before the server has been started
- So practically the server won't start
```
3. The read and write for consoleopts.WG has been happening in different go-routines without control or lock system(reading and writing into same memory location without lock system). So there is a chance of data-race(warning for data-race while integration tests are executed)
4. Data-race errors from `promptui` package
### Solution:
1. Use `--force` flag to avoid getting the input from the prompt in `migrate_delete_test.go`
2. Introduced two fields in server and console opts to let know other go-routines whether the server has been started or not
3. To avoid data-race above which are shared b/w go-routines to know the status of servers has been operated atomically.
4. using new package https://github.com/AlecAivazis/surveyhttps://github.com/hasura/graphql-engine-mono/pull/2231
GitOrigin-RevId: 387eb1be74f24dda34bb3588314b5a909adac227
>
### Description
Update `go.mod` to allow other packages to import [v2.0.0 versions](https://blog.golang.org/v2-go-modules).
### Changelog
- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR. If no changelog is required, then add the `no-changelog-required` label.
### Affected components
- [x] CLI
https://github.com/hasura/graphql-engine-mono/pull/1584
GitOrigin-RevId: a5d17ad20289d1cd7217763f56ef3ba6552d69c4
- modified the `dry-run` flag of metadata apply command.
- added new flag `o` which takes "json" or "yaml" as parameters for metadata apply command.
- added new flag `o` which takes "json" or "yaml" as parameters for metadata export command. It outputs the metadata from server to stdout in form of json or yaml and won't change the project's metadata.
- added deprecation warnings for `--from-file` flag
- added info message for describing change of behavior of `--dry-run` flag
- v3 metadata objects like `rest_endpoints` was also added to list of metadata objects in config v2 (fix)
- the order in which metadata objects are appended to metadata objects list matter when using `--dry-run` flag, refactored this order to match server metadata.
- `metadata apply` command can now accept json/yaml metadata from io pipe
- config v3 `metadata apply` didn't show any information to user when applied metadata is inconsistent, this is addressed.
- removed `github.com/ghodss/yaml` dependency from repo
- version metadata object was added twice during intialization (fix)
Co-authored-by: Aravind K P <8335904+scriptonist@users.noreply.github.com>
GitOrigin-RevId: 2316f519eb40645efd86ffee2a85d3c90543ec17
