Andrew Haines
Andrew Haines
My workflow has a bot user that approves a related pull request in another repo when the tests in this repo pass, and the first step of the workflow is...
Oh right - I see now that it also affects the existing `event_store_events_in_streams` table. I'll have a look at creating a PR!
I think the check here needs to be updated to account for the possibility of `*bool` fields (otherwise you can't make a `*bool` field negatable): https://github.com/alecthomas/kong/blob/556f8b773b24e22c5dcb05a1a740567c19d1ef99/tag.go#L174 Also here: https://github.com/alecthomas/kong/blob/deebf0b09b7bdda61ec299ab90aaaa341436dd4b/model.go#L311
@scottwis could you please check if you can use the `negatable:""` tag with `*bool` fields (might be worth adding a test case for it)?
We should also update examples etc to encourage the use of `cerbos.yaml` as the config filename, then we can detect and apply the schema automatically.
This would be particularly helpful in light of https://github.com/grpc-ecosystem/grpc-gateway/issues/2718 (our OpenAPI schemas are currently incorrect!).
Another case where a warning would be useful is deprecating CEL functions (https://github.com/cerbos/cerbos/issues/669).
If we can do this, it'd be great to then alter the output format to be more like other compilers. `pretty` might give a Clang-style format, and `plain` something like...
Perhaps it would be possible to have a `prepublishOnly` script that strips the `dev` dependencies from npm-shrinkwrap.json as a workaround?
>Would be nice if it was fixed to work correctly with go modules versioning I agree - isn't this just a case of tagging releases as `v0.16.0` rather than `0.16.0`?...