Predefined pipeline
If you have a look at .gitlab-ci.yml you notice a high-order pipeline configuration with a specific amount of other yml includes. Due to the fact that the boilerplate is built modular, the GitLab CI configuration should be, too.
A CI/CD configuration itself (not matter what you are using) can be very huge. You will not understand the configuration while read through first. Do not worry, you can just start developing plugins and do not need to adjust the CI/CD configuration at the beginning.
Why GitLab?
It provides one of the best documentation - it's very clear and extensive.
The documentation is very easy to understand - even for beginners.
It has a very good market position.
CI/CD system is directly integrated in your Git repository and directly triggered for merge requests.
It's free (unlimited if you use your own runner)!
Disadvantages
If you choose to use the Shared Runners coming out-of-the-box with GitLab CI/CD you will notice, some of our defined pipeline jobs will not be triggered due to the following fact: Shared Runners does not allow you to run additional docker containers.
E2E tests requires to use own started docker containers so the test itself can run on a clean installation.
Review applications requires to start persistent docker containers running a specific time (until the branch is merged) so you can directly view changes in a clean installation of your plugins.
Use own runnerPipeline stages
The predefined pipeline coming with WP ReactJS Starter is defined in multiple yml files and included in the root .gitlab-ci.yml file. If you create a new plugin with create-wp-react-app create-plugin you do not need to modify .gitlab-ci.yml yourself because this is done automatically by the command (it adds a new include).
Containerize
Job definitions in: devops/.gitlab/stage-containerize.yml
Build docker images from devops/docker/ and push to Gitlab Container Registry. Currently there is one docker images built: gitlab-ci for the GitLab CI itself (each job gets its own container with that image).
Install
Job definitions in: devops/.gitlab/stage-install.yml
The first step of our pipeline starts installing / bootstrapping the complete plugin environment. This job must be defined only once because it is responsible for all your packages - due to the fact we are using a multi-package repository with lerna. The complete installation files (dependencies of composer and yarn) are put into a cache so further jobs can fetch that cache and do not need to reinstall again.
Per plugin an additional job for license checker is added. As we use lerna we need a way to bootstrap a single package.
You need to add .install to all your jobs' extends which require all dependencies installed. Learn more here.
Validate
Job definitions in:
Bump versions and generate a CHANGELOG.md for all packages (lerna version). The bumped version is used for release candidate .zip's of the built plugins.
Additionally license checks are done, learn more here.
Build
Job definitions in:
After validation succeeds the usual build process starts. Linting, technical docs and the build process itself are parts of this stage. For packages, only linting is done because they are directly consumed in the plugins' build process.
As artifact you will get the technical docs (as .zip) and the installable plugin files.
There is one job related to the root: Lint common files.
Test
Job definitions in:
The plugins are built now. Let's make some tests. Currently, E2E tests are executed (only own runner) and unit tests / Snapshot tests with Jest and PHPUnit. Another important job at this stage is to collect all build files and put them in a single artifact for further usage in Review applications.
Release
Job definitions in: devops/.gitlab/stage-validate.yml
The release stage contains two different "release jobs". The release job is only executed in master branch. It prepares further deployment in the next stage build-production and releases non-private packages to npmjs.com directly with lerna publish.
The other job docker review start is only executed in non-master branches (and requires own runner). It starts a complete new docker container environment and provides an URL where the reviewer can access it.
Build production
Job definitions in: plugins/*/devops/.gitlab/stage-build-production.yml
This stage is meant to only run on master branch. It builds your plugins again and prepares it for upload on wordpress.org. It stores the installable plugin .zip file as artifact - upload it for example to your live site or a license server.
Deploy
Job definitions in: plugins/*/devops/.gitlab/stage-deploy.yml
This stage is meant to only run on master branch. It has an example job definition you can extend, to upload the artifact files (technical docs and the installable plugin) to your server with wput.
It comes also with a predefined job uploading the new plugin to the wordpress.org SVN repository automatically (requires configuration).
Last updated