This repository provides useful templates for reusable GitLab-CI jobs in move:elevator projects. It is not meant to be used anywhere else.
See .gitlab-ci.yml.dist for an example GitLab-CI configuration.
Use include to reference template files:
include:
- 'https://raw.githubusercontent.com/move-elevator/gitlab-ci-templates/main/.base.yml'
- 'https://raw.githubusercontent.com/move-elevator/gitlab-ci-templates/main/build/build-php.yml'
- ...Extend and override configuration variables, see .base.yaml for predefined variables.
variables:
BUILD_NODE_VERSION: "22"Extend and override further ci jobs.
.base.yml: Base configuration, including common variables and stages, required for all projects.
Build the project and its assets.
Includes:
build/build-php.ymlbuild/build-node.yaml
Analyze code quality and static analysis.
Includes:
analyze/analyze-composer-lint.yamlanalyze/analyze-content-blocks-lint.yamlanalyze/analyze-editorconfig.yamlanalyze/analyze-fluid-lint.yamlanalyze/analyze-js-lint.yamlanalyze/analyze-php-cs-fixer.yamlanalyze/analyze-php-rector.yamlanalyze/analyze-php-stan.yamlanalyze/analyze-style-lint.yamlanalyze/analyze-typoscript-lint.yamlanalyze/analyze-xml-lint.yamlanalyze/analyze-yaml-lint.yaml
Note
The analyze jobs have changes triggers for the respective files, so they only run when relevant files are changed.
Deploy feature branches to a dedicated environment.
The deployment uses deployer and deployer-tools as deployment base.
Includes:
deploy/deploy-feature.yamldeploy/deploy-feature-rollback.yamldeploy/deploy-feature-cleanup.yamldeploy/deploy-feature-cleanup-downstream.yaml
Note
The cleanup of a feature branch is a little bit tricky. It may happen that the branch has been deleted, triggering the deploy:feature:cleanup job. However, since the application code in the branch is no longer available at this point and the cleanup logic and configuration are therefore no longer present, the cleanup is delegated to another branch (usually the main branch) via the downstream pipeline.
Deployment to production environment.
The deployment uses deployer and deployer-tools as deployment base.
Includes:
deploy/deploy-prod.yamldeploy/deploy-prod-rollback.yaml
Important
Production deployments are restricted to semver-tagged versions only (e.g. v1.2.3 or 1.2.3).
Deployment to staging environment.
The deployment uses deployer and deployer-tools as deployment base.
Includes:
deploy/deploy-stage.yaml
Note
Use this template if the project wants a simple stage deployment and doesn't need an advanced feature branch deployment.
Create a GitLab release with release notes.
Includes:
build/build-release-notes.yamlrelease/release.yaml
The release notes come from one of two mutually exclusive templates — include exactly one:
build/build-release-notes.yaml: fetches them from GitLab's changelog API.build/build-release-notes-changelog.yaml: extracts the section for the current tag fromCHANGELOG.md. Use this one for projects whose changelog is generated from conventional commits, which the GitLab API does not understand.
The asset link on the release page defaults to the project's container image and is overridden
with RELEASE_ASSET_LINK_NAME and RELEASE_ASSET_LINK_URL.
Includes:
release/release-prepare.yamlbuild/build-release-notes-changelog.yamlrelease/release.yaml
release:prepare is a manual job on the default branch that bumps the version, generates
CHANGELOG.md, folds both into one chore(release): version X.Y.Z commit authored by whoever
pressed the button, and pushes the commit (with ci.skip) and the tag. The tag pipeline then
builds the release notes, publishes the GitLab Release and deploys to production.
It needs version-bumper with a
version-bumper.yaml, an npm script changelog, and a masked, protected RELEASE_TOKEN
variable holding a token with write_repository scope.
Important
Only users who may push to a protected branch can run manual jobs on it. Protect the default branch and set "Allowed to push and merge" to the people who may release — that, and not the job definition, is what restricts who can cut a release.
Note
Set RELEASE_DRY_RUN to any value when starting the job to rehearse a release: everything
runs, but both pushes become git push --dry-run. With it set the job is also offered on
non-default branches.
Run acceptance tests using Codeception.
Includes:
test/test-feature-codeception.yamltest/test-prod-codeception.yaml
Warm up the cache after deployment using EXT:typo3-warming.
Includes:
cache/cache-feature-warmup.yamlcache/cache-prod-warmup.yaml
Run security checks using audit tools.
Includes:
security/security-composer-check-scheduled.yamlsecurity/security-npm-check-scheduled.yaml
Note
The *:scheduled jobs above need to be scheduled in GitLab-CI.
Important
A pipeline schedule needs to have set the variable SCHEDULE_TASK_NAME to the desired task, e.g. security:composer:check:scheduled or security:npm:check:scheduled.
This is a workaround (see according rules) to address specific jobs in a scheduled pipeline.
Generate a CycloneDX SBOM (Software Bill of Materials) of all locked composer and npm dependencies using syft. The SBOM is stored as job artifact and published to the project's Generic Package Registry, which serves as technical documentation in terms of the Cyber Resilience Act (CRA).
Includes:
security/security-sbom.yaml
Runs on semantic version tags only, matching the prod deployment. Published as packages/generic/sbom/<version>/sbom.cdx.json, where <version> is the tag without a leading v. Dev dependencies are excluded, so the SBOM describes the shipped application rather than the build toolchain.
Important
Technical documentation has to be kept for the declared support period. Make sure the project has no cleanup policy that removes generic packages.
This project is licensed under GNU General Public License 3.0 (or later).