CI-Only Gates (12–14)

These gates run only in GitLab CI. They are never triggered by plesty check locally: they need the project's CI credentials and a pipeline's view of the branch or tag being built.

Gate 12 — Docs Deploy

Builds the Sphinx documentation and pushes the output to the docs-build branch, which docs.plesty.net serves. A branch pipeline deploys the development docs (latest/); a tag deploys that release's docs. It never runs on a maintain/* branch.

Requirements:

• The CI_BOT_TOKEN variable, which the job uses to push. For a module under PLESTY's groups (plesty/hub, plesty/core, plesty/plesty-ai) it is a group CI/CD variable, inherited by every project — there is nothing to set up.
• The docs-build branch, created automatically on the first deploy.

Never create a per-project CI_BOT_TOKEN. It would shadow the group's, and expire on its own schedule — the symptom is a deploy-docs job failing with 403 while every other job is green.

The token needs the Maintainer role with read_repository + write_repository scopes: without Maintainer, git ls-remote returns 403 even with read_repository, and the job cannot tell whether docs-build exists.

Gate 13 — Secret Detection

Runs GitLab's secret detection to scan for accidentally committed credentials, API keys, and tokens.

It runs under the quantum standard, in merge-request pipelines and on the default branch, exp, maintain/* and tags. It fails the pipeline if a secret pattern is detected and does nothing else. No setup required — it is included in the plesty-standard-ci component.

Tip: If you accidentally commit a secret, rotate it immediately and then rewrite git history to remove the committed value. The pipeline will not pass until the secret is gone from the diff.

Gate 14 — Build & Release

Builds the Python wheel and uploads it to PyPI. This gate is conditional — it runs only in a tag pipeline. Release tags are named v<version> (e.g., v0.2.1).

Requirements:

• A PyPI trusted publisher for the project — the job then authenticates with no stored secret. Or a PYPI_TOKEN CI/CD variable, masked and protected, which the job uses instead when it is set. Publishing sets up either.
• plesty check --standard quantum must pass before tagging

Trigger:

git tag v0.2.1
git push origin v0.2.1

The pipeline runs all gates in sequence. Gate 14 only executes if all earlier gates pass. After Gate 14 succeeds, the package appears on PyPI under plesty-<module-name>==<version>.

The full CI pipeline

stages:
  - check
  - security
  - deploy
  - release

include:
  - component: $CI_SERVER_FQDN/plesty/plesty-ci/plesty-standard-ci@main
    inputs:
      standard: quantum
      extra_branch: exp
      access_token: $CI_BOT_TOKEN

Every input has a default, so none is required: standard (default nebula), extra_branch (a branch besides the default one whose pushes run the check and deploy jobs — exp for a published module), access_token (default $CI_JOB_TOKEN), pypi_token, and the stage names, image and artifact expiry. CI Pipeline has the full list.