Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add GitLab CI configuration example to continuous integration g… #1731

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions src/content/docs/recipes/continuous-integration.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -54,3 +54,34 @@ jobs:
github_token: ${{ secrets.github_token }}
reporter: github-pr-review
```

## GitLab CI

Below is an example configuration:

```yaml title=".gitlab-ci.yml"
# Define pipeline stages
stages:
- quality

# Lint job configuration: runs code quality checks using Biome
lint:
image:
name: ghcr.io/biomejs/biome:latest # Use the latest Biome Docker image
entrypoint: [""] # This is required for the image to work in GitLab CI
stage: quality # Run in the quality stage
script:
- biome ci src --reporter=gitlab --colors=off --log-level=none --diagnostic-level=error > code-quality.json # Execute Biome on the 'src' directory
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- biome ci src --reporter=gitlab --colors=off --log-level=none --diagnostic-level=error > code-quality.json # Execute Biome on the 'src' directory
- biome ci --reporter=gitlab > code-quality.json

Perhaps the example should be less opinionated unless these additional params have been added so that exporting code-quality.json works as expected. You probably have tested this better than I have, so I'll trust your jugement on this.

Regardless, we probably don't want to refer to src, because there may be supported files somewhere else in the project

artifacts:
paths:
- code-quality.json # Collect the code quality report as an artifact
needs: [] # No dependent jobs needed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
needs: [] # No dependent jobs needed

If not required perhaps we could do without it in the example

rules:
- if: $CI_COMMIT_BRANCH # Run job for commits on branches
- if: $CI_MERGE_REQUEST_ID # Run job for merge requests
allow_failure: true # Allow the job to fail (adjust as needed)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
allow_failure: true # Allow the job to fail (adjust as needed)

Perhaps we remove this one too. I expect people who use GitLab CI on a daily basis to know about this option. It keeps the example leaner. What do you think ?

```

:::note
If your project's source code is located in another directory, replace `src` with that directory's path in the command.
:::
Loading