GitHub Deployment¶

Automatic Deployment Mode¶

With the Automatic deployment mode, Hasura Cloud automatically triggers a deployment for every commit pushed to the GitHub repository from the given branch and directory.

The Automatic deployment mode also has the Deploy Now button which allows the user to retry deploying the latest commit.

Manual Deployment Mode¶

With Manual deployment mode, Hasura Cloud does not automatically deploy the commits pushed to the configured branch. The deployment of the latest commit in that branch can be triggered manually by clicking the Deploy Now button.

Link GitHub account to a Hasura Cloud project¶

To link a GitHub account, click on the Sign in with GitHub button in the Git Deployment section of the project details.

When you link a new GitHub account, Hasura Cloud installs the Hasura Cloud GitHub App on your GitHub account. While authenticating, you can choose to grant access to all repositories or to specific repositories only.

The permissions requested by Hasura Cloud can be viewed in the GitHub app settings once you install the app.

Once linked, the GitHub account with the granted scope becomes available to all the admins on the project as the session is used to manage the GitHub integration from the UI.

Integrate GitHub repo with a Hasura Cloud project¶

Specify the GitHub repository, branch and the hasura-project directory in the form as shown below.

If the repository that you’re looking for doesn’t show up in the repository list, click Configure Hasura Cloud on GitHub to grant access to the required repository.

Clicking on the Setup Git Deployment button integrates the specified GitHub repository, branch and directory with the Hasura Cloud project. The details for the integration can be viewed in the Git Deployment section of project details.

Deployment sub-tasks¶

The following is a task wise breakdown of the commit deployment job.

Each task in the deployment has realtime logs and can be viewed by clicking on the Logs option for each successful/failed step.

Error parsing metadata¶

• Nothing has been modified on your project yet so there will be no service impact.
• Typically happens due to some issue with the metadata directory structure or the format of the metadata files.
• Check the reported error message and fix the issues in the metadata. See metadata format.
• Push the fix to GitHub to redeploy.

Error parsing migrations¶

• Nothing has been modified on your project yet so there will be no service impact.
• Typically happens due to some issue with the migration directory structure or the format of the migration files.
• Check the reported error message and fix the issues in the migrations. See migrations format.
• Push the fix to GitHub to redeploy.

Error applying metadata¶

• Nothing has been modified on your project yet so there will be no service impact.
• Typically happens due to some invalid metadata (e.g. due to type mismatches, missing required keys, etc.) trying to be applied.
• Check the reported error message and fix the issues in the metadata. See metadata format.
• Push the fix to GitHub to redeploy.

Error applying migrations¶

• As your metadata has already been applied but applying your migrations has failed, your project might be in an unhealthy state. If your migrations and metadata had only incremental changes, i.e. no existing objects were modified, you likely won’t have any service impact because existing parts of your metadata are likely to be still valid and your existing functionality will be working as it were.

• Look at the underlying database error. Make the appropriate fix depending on the error and redeploy.

• Some common errors:

  • source with name “default” is inconsistent

    In this situation, most likely either the target project doesn’t have the required database connected or the ENV VARS or the database name used to connect the database is not matching in your source and target projects.

    To fix this, use the same ENV VARS and connect the database with the same name in both your projects.

  • “relation “<some-object>” already exists”

    In such situations when you get errors of tables or other objects already existing, this might be because the migration might have been already applied on the database and the project was not yet aware of it.

    To fix this, use the Hasura CLI command hasura migrate apply --skip-execution --version <migration_version> --endpoint "<cloud_project_endpoint>" to mark the migration as already applied on the project. Then redeploy the failed commit to continue with further steps.

Inconsistent metadata after finalizing update¶

• It is possible your project might be in an unhealthy state depending on which metadata objects are inconsistent and what migrations were applied. If your metadata and migrations had only incremental changes, i.e. no existing objects were modified, you likely won’t have any service impact because existing parts of your metadata are likely to be still valid and your existing functionality will be working as it were.
• Check the logs under Applying Migrations and Finalizing Update.
• In the situation that the applied metadata applied was indeed incorrect, fix the metadata and push a new commit to redeploy.
• If objects depending on upstream services are inconsistent, e.g. remote schemas, the upstream service might be unavailable or inconsistent. In this case please fix them and redeploy the commit.
• If database objects are inconsistent with errors such as Inconsistent object: no such table/view exists in source: “<table-name>“, it could be because:
  • a migration might have been skipped as the project believes its already been applied though its not the case. To fix it, mark the migration as unapplied using the following Hasura CLI command hasura migrate delete --version <migration_version> --server --database-name <database-name> --endpoint <cloud_project_endpoint> and redeploy the commit.
  • a migration to create the database objects might be missing completely. To fix this create a new migration for creation of the missing objects and push a new commit to redeploy.
• A rollback can be done to the previous functioning state of metadata by reverting your metadata changes on your branch and then pushing to redeploy.