Right now you need to run schema:publish <pointer-to-graphql-schema>, for every target.
As an alternative we are thinking about just having the option of promoting the schema version from one target to the schema version of another target.
e.g. hive schema:promote <id>.
This would have the benefit of not requiring access to the graphql schema when mirroring a stage in a multi-environment deployment. E.g. when progressing a docker image from one one stage to another and the flow is not 1:1 backed by a version control system such as Git.
We need to figure out whether the <id> is something a Hive users pass along as a hive schema:publish parameter that needs to be unique across all publishes within a project, or whether this is something we provide as an output when running schema:publish, that the Hive user needs to store to later on pass it as a parameter for hive schema:promote <id>.
Example:
Git Branch
Hive Target
main
development
staging
staging
production
production
New features are developed on a branch that targets the main branch. The hive schema:check
command is run against the development target. conditional breaking changes are configured on
staging and production targets.
When the feature is ready for QA, the branch is merged into main. The hive schema:publish
command is triggered by CD workflow, and the schema is published to the development target.
When the feature is ready for staging, the main branch is merged into staging. The
hive schema:promote command is triggered by the CD workflow, and the schema version is published to the
staging target.
When the feature is ready for production, the staging branch is merged into production. The
hive schema:promote command is triggered by the CD workflow, and the schema published to the
production target.
Hi, in lack of this functionality, is there any other way to copy over a schema from target to target? For example, when bootstrapping a new or temp environment it would be super useful to be able to clone a schema
Right now you need to run
schema:publish <pointer-to-graphql-schema>
, for every target. As an alternative we are thinking about just having the option of promoting the schema version from one target to the schema version of another target.e.g.
hive schema:promote <id>
.This would have the benefit of not requiring access to the graphql schema when mirroring a stage in a multi-environment deployment. E.g. when progressing a docker image from one one stage to another and the flow is not 1:1 backed by a version control system such as Git.
We need to figure out whether the
<id>
is something a Hive users pass along as ahive schema:publish
parameter that needs to be unique across all publishes within a project, or whether this is something we provide as an output when runningschema:publish
, that the Hive user needs to store to later on pass it as a parameter forhive schema:promote <id>
.Example:
New features are developed on a branch that targets the
main
branch. Thehive schema:check
command is run against thedevelopment
target. conditional breaking changes are configured onstaging
andproduction
targets.When the feature is ready for QA, the branch is merged into
main
. Thehive schema:publish
command is triggered by CD workflow, and the schema is published to thedevelopment
target.When the feature is ready for staging, the
main
branch is merged intostaging
. Thehive schema:promote
command is triggered by the CD workflow, and the schema version is published to thestaging
target.When the feature is ready for production, the
staging
branch is merged intoproduction
. Thehive schema:promote
command is triggered by the CD workflow, and the schema published to theproduction
target.