Default

Runs code quality checks applicable to any project: YAML linting and pre-commit hooks. It also includes the AI agent jobs, which appear once the project or its group has a Claude token.

Import

include:
  - project: hosstio/gitlab-pipelines
    file: pipelines/default.yaml

Jobs

precommit

Runs pre-commit hooks against all files. Only runs when a .pre-commit-config.yaml exists in the repository.

Variable	Default	Description
PRE_COMMIT_ARGS	--all-files --show-diff-on-failure --color always	Arguments passed to pre-commit run

pre-commit:autoupdate

Runs pre-commit autoupdate and fails if it rewrote .pre-commit-config.yaml, reporting that pinned hook revisions are behind upstream. Only runs on scheduled pipelines, and only when a .pre-commit-config.yaml exists.

The check belongs on a schedule rather than in the commit hooks: pre-commit autoupdate reaches out to every hook repository, so running it per commit makes commits slow and dependent on the network, and it cannot run as a local hook at all: pre-commit invoking itself fails.

The job reports the bump but does not commit it; GITLAB_AUTH_TOKEN defaults to $CI_JOB_TOKEN, which cannot push or open merge requests.

The job runs only once the project has a pipeline schedule. Create one under Build → Pipeline schedules → New schedule, or:

glab api --method POST "projects/<group>%2F<project>/pipeline_schedules" \
  --field description="pre-commit autoupdate" \
  --field ref=main \
  --field cron="0 6 * * 1"

Monday morning, weekly, is the suggested cadence for consuming projects: hook releases are rare, and a daily schedule turns every upstream release into a red pipeline until someone bumps it.

This project is the deliberate exception and runs daily (0 9 * * *): it owns the shared hook config, so it should hear about a hook release first.

Deploy and apply jobs skip scheduled pipelines, so a schedule on the default branch will not deploy anything. Read-only diff jobs (helm:staging, helm:production) still run.

One catch when adding a schedule to a project: a rules: block in the project's own .gitlab-ci.yml replaces the shared one rather than adding to it. A project that overrides .deploy:test or any other deploy job locally has to repeat $CI_PIPELINE_SOURCE != "schedule" in that block, or the guard does not apply to it.

yamllint

Lints all YAML files using yamllint. Runs on the default branch and git tags, or on merge requests and other branches when a .yaml or .yml file or .yamllint changes. Every project has a .gitlab-ci.yml, so the job runs in every project. Without a .yamllint in the project, yamllint uses its default config, which fails any line over 80 characters.

Variable	Default	Description
YAMLLINT_PATH	.	Path to lint
YAMLLINT_ARGS	--format colored	Arguments passed to yamllint

Workflow

Feature branches run merge request pipelines when a merge request is open, and branch pipelines otherwise; the duplicate branch pipeline is suppressed while an MR is open. The default branch always runs its branch pipeline. See When pipelines run for the full breakdown.