mirror of
https://github.com/ent/ent.git
synced 2026-05-24 09:31:56 +03:00
97 lines
3.0 KiB
Plaintext
97 lines
3.0 KiB
Plaintext
---
|
|
id: ci
|
|
title: 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!
|
|
|
|
## EntCI
|
|
|
|
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](https://github.com/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'},
|
|
]}>
|
|
<TabItem value="gh">
|
|
Simply add a file named `.github/workflows/ent-ci.yaml` in your repository:
|
|
|
|
```yaml
|
|
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
|
|
```
|
|
|
|
</TabItem>
|
|
<TabItem value="bash">
|
|
|
|
```bash
|
|
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
|
|
```
|
|
|
|
</TabItem>
|
|
</Tabs>
|