Using Bytebase Cloud for GitOps‑Based SQL Review: A Step‑by‑Step Guide

Register Bytebase Cloud

Visit https://www.bytebase.com/ and click the “Register Cloud Service” button in the upper‑right corner. You can sign up or log in with an email, Google, GitHub, or Microsoft account; the example uses GitHub login.

After logging in, you are redirected to the workspace page; click Create Workspace . Note that each account is allowed only one workspace. After a few minutes of provisioning, check your email for a login link, email, and password.

Configure Database GitOps

Navigate to Settings and select the GitOps option from the left‑hand menu. Choose GitLab for the demonstration, fill in the GitLab service URL, and click the Next button.

Create an OAuth application on the GitLab platform, copy the Application ID and Secret, and paste them into the Bytebase integration form.

After completing the integration, click Confirm and Add to finish the GitOps configuration. Then create a test project and enable the GitOps workflow.

Test GitOps

Select an existing test database in the cloud, choose the environment, enter a database name, and click Create .

Configure an SQL review policy by selecting the environment and enabling the review strategy.

In the remote repository, add a new SQL change file (ensure the file extension is .sql ). When the file is committed, Bytebase automatically creates a work ticket. Opening the ticket shows that any schema or data change triggers an automatic SQL review.

Click the SQL Review button to view the review results. If there are syntax errors or policy violations, the UI displays the corresponding error messages. Queries also undergo review if the environment’s SQL review policy is active.

GitOps SQL Review

Enable SQL review via GitLab CI by adding a CI job that calls Bytebase’s review API. Bytebase initializes a merge request that adds a gitlab-ci.yaml configuration file, which invokes the API to review SQL files on each merge request.

bytebase-sql-review:
  only:
    refs:
      - merge_requests
  image: docker:stable
  variables:
    API: "https://ovxlixlc.us-central1.bytebase.com/hook/sql-review/workspace_zytest-ujognaj-1682219285"
  before_script:
    - apk update && apk add curl
    - apk update && apk add jq
  script:
    - echo "Start request $API"
    - request_body=$(jq -n --arg repositoryId "$CI_PROJECT_ID" --arg pullRequestId $CI_MERGE_REQUEST_IID --arg webURL "$CI_SERVER_URL" '$ARGS.named')
    - response=$(curl -s --show-error -X POST "$API" -H "Content-type: application/json" -H "X-SQL-Review-Token: $SQL_REVIEW_API_SECRET" -d "$request_body")
    - echo $response
    - content=$(echo $response | jq -r '.content')
    - len=$(echo $content | jq '. | length')
    - if [ $len == 0 ]; then exit 0; fi
    - msg=$(echo $content | jq -r '.[0]')
    - echo $msg >> bytebase-sql-review.xml
    - status=$(echo $response | jq -r '.status')
    - if [ "$status" == "ERROR" ]; then exit 1; fi
  artifacts:
    when: always
    reports:
      junit:
        - bytebase-sql-review.xml

After creating a test branch and modifying the SQL file, open a merge request to see the SQL review results displayed in the pipeline.

Feedback & Questions

Q1: Is configuring SQL review convenient? The web UI configuration is straightforward. Integrating with GitLab CI requires careful handling of existing CI files to avoid merge conflicts.

Q2: Does it meet your use cases? The current setup applies SQL review at the environment level; enabling it for PROD affects all projects. More complex enterprise scenarios may need custom or selective review rules.

Q3: What is missing from the SQL review? Some enterprises use SonarQube for SQL scanning (e.g., https://rules.sonarsource.com/plsql) and could benefit from additional rule sets. Integration with Jenkins for CI/CD is also a common request.

Overall, the experience is very positive, and the GitOps‑based SQL review works well.