Skip to content

Latest commit

 

History

History
288 lines (262 loc) · 8.75 KB

ci.mdx

File metadata and controls

288 lines (262 loc) · 8.75 KB
Raw
id title
ci
Continuous Integration

import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';

To ensure the quality of their software, teams often apply Continuous Integration workflows, commonly known as CI. With CI, teams continuously run a suite of automated verifications against every change to the code-base. During CI, teams may run many kinds of verifications:

  • Compilation or build of the most recent version to make sure it isn't broken.
  • Linting to enforce any accepted code-style standards.
  • Unit tests that verify individual components work as expected and that changes to the codebase do not cause regressions in other areas.
  • Security scans to make sure no known vulnerabilities are introduced to the codebase.
  • And much more!

From our discussions with the Ent community, we have learned that many teams using Ent already use CI and would like to enforce some Ent-specific verifications into their workflows.

To support the community with this effort we have started this guide which documents common best practices to verify in CI and introduces ent/contrib/ci a GitHub Action we maintain that codifies them.

Verify all generated files are checked in

Ent heavily relies on code generation. In our experience, generated code should always be checked into source control. This is done for two reasons:

  • If generated code is checked into source control, it can be read along with the main application code. Having generated code present when the code is reviewed or when a repository is browsed is essential to get a complete picture of how things work.
  • Differences in development environments between team members can easily be spotted and remedied. This further reduces the chance of "it works on my machine" type issues since everyone is running the same code.

If you're using GitHub for source control, it's easy to verify that all generated files are checked in with the ent/contrib/ci GitHub Action. Otherwise, we supply a simple bash script that you can integrate in your existing CI flow.

<Tabs defaultValue="gh" values={[ {label: 'GitHub Action', value: 'gh'}, {label: 'Bash', value: 'bash'}, ]}> Simply add a file named .github/workflows/ent-ci.yaml in your repository:

name: EntCI
on:
  push:
  # Run whenever code is changed in the master.
    branches:
      - master
  # Run on PRs where something changed under the `ent/` directory.
  pull_request:
    paths:
      - 'ent/*'
jobs:
  ent:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3.0.1
      - uses: actions/setup-go@v3
        with:
          go-version: 1.18
      - uses: ent/contrib/ci@master
go generate ./...
status=$(git status --porcelain)
if [ -n "$status" ]; then
    echo "you need to run 'go generate ./...' and commit the changes"
    echo "$status"
    exit 1
fi

Lint migration files

Changes to your project's Ent schema almost always result in a modification of your database. If you are using Versioned Migrations to manage changes to your database schema, you can run migration linting as part of your continuous integration flow. This is done for multiple reasons:

  • Linting replays your migration directory on a database container to make sure all SQL statements are valid and in the correct order.
  • Migration directory integrity is enforced - ensuring that history wasn't accidentally changed and that migrations that are planned in parallel are unified to a clean linear history.
  • Destructive changes are detected notifying you of any potential data loss that may be caused by your migrations way before they reach your production database.
  • Linting detects data-dependant changes that may fail upon deployment and require more careful review from your side.

If you're using GitHub, you can use the Official Atlas Action to run migration linting during CI.

Add .github/workflows/atlas-ci.yaml to your repo with the following contents: <Tabs defaultValue="mysql" values={[ {label: 'MySQL', value: 'mysql'}, {label: 'MariaDB', value: 'maria'}, {label: 'PostgreSQL', value: 'postgres'}, {label: 'SQLite', value: 'sqlite'}, ]}> 

name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    services:
      # Spin up a mysql:8.0.29 container to be used as the dev-database for analysis.
      mysql:
        image: mysql:8.0.29
        env:
          MYSQL_ROOT_PASSWORD: pass
          MYSQL_DATABASE: test
        ports:
          - 3306:3306
        options: >-
          --health-cmd "mysqladmin ping -ppass"
          --health-interval 10s
          --health-start-period 10s
          --health-timeout 5s
          --health-retries 10
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3.0.1
        with:
          fetch-depth: 0 # Mandatory unless "latest" is set below.
      - uses: ariga/atlas-action@v0
        with:
          dir: ent/migrate/migrations
          dir-format: golang-migrate # Or: atlas, goose, dbmate
          dev-url: mysql://root:pass@localhost:3306/test
name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    services:
      # Spin up a maria:10.7 container to be used as the dev-database for analysis.
      maria:
        image: mariadb:10.7
        env:
          MYSQL_DATABASE: test
          MYSQL_ROOT_PASSWORD: pass
        ports:
          - 3306:3306
        options: >-
          --health-cmd "mysqladmin ping -ppass"
          --health-interval 10s
          --health-start-period 10s
          --health-timeout 5s
          --health-retries 10
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3.0.1
        with:
          fetch-depth: 0 # Mandatory unless "latest" is set below.
      - uses: ariga/atlas-action@v0
        with:
          dir: ent/migrate/migrations
          dir-format: golang-migrate # Or: atlas, goose, dbmate
          dev-url: maria://root:pass@localhost:3306/test
name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    services:
      # Spin up a postgres:10 container to be used as the dev-database for analysis.
      postgres:
        image: postgres:10
        env:
          POSTGRES_DB: test
          POSTGRES_PASSWORD: pass
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3.0.1
        with:
          fetch-depth: 0 # Mandatory unless "latest" is set below.
      - uses: ariga/atlas-action@v0
        with:
          dir: ent/migrate/migrations
          dir-format: golang-migrate # Or: atlas, goose, dbmate
          dev-url: postgres://postgres:pass@localhost:5432/test?sslmode=disable
name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3.0.1
        with:
          fetch-depth: 0 # Mandatory unless "latest" is set below.
      - uses: ariga/atlas-action@v0
        with:
          dir: ent/migrate/migrations
          dir-format: golang-migrate # Or: atlas, goose, dbmate
          dev-url: sqlite://./dev.db?_fk=1

Notice that running atlas migrate lint requires a clean dev-database which is provided by the services block in the example code above.