Building Magento 2 with Jenkins
I often find myself needing a clean Magento 2 environment. The version required generally depends on what I’m doing and means I switch relatively often. I’m lazy and wanted something that just works by pushing a button or two. I had stood up a Jenkins instance the prior week and thought I’d use that for creating the build artifacts and eventually deploying. Here I will focus on the build and archive generation process.
Since I’m often switching between similar versions I want to avoid the build
process when deploying if possible. For example, if I’ve already built 2.4.0 and
2.3.5 I should not need to rebuild them when switching versions. I found a few
different approaches such as writing the archive to AWS S3 or Artifactory. I
wanted to use my existing infrastructure and decided on installing the
copyArtifacts Jenkins plugin.
We’ll be performing the build withing a docker container based on one of the
official PHP images
php:7.3-cli. You can view the Dockerfile on GitLab.
The final version is very basic. We install a few packages for meeting Magento’s
minimum requirements along with composer.
An oddity within the Dockerfile is copying a generic store configuration. I’m
performing the build from the Magento GitHub repository for running develop
branches between releases. This means I won’t have a complete
available at build time.
COPY files/store-config.php /var/store-config.php
will fill in the gaps for running
With the Dockerfile ready we’ll start writing the Jenkinsfile used for the build. Here’s the initial pipeline for preparing the workspace for build. The stage is configured for running inside the PHP Docker container.
- Build parameters for inputting the tag or branch and select letting the pipeline know if the input is a tag or branch.
- Add Magento composer auth from a Jenkins stored credential.
- Checkout the Magento source from GitHub using the provided reference.
We can now add our build commands into the stage. The build steps are basic:
composer installwith the
- Create a
config.phpby enabling all modules. You would not do this with a standard Magento project. Your
config.phpshould be commited to source control.
- A hack merging the new
config.phpwith a boilerplate store config. Again this is only needed because it isn’t a proper project.
.git. I don’t usually do this, but it adds 250MB of bloat to the build artifact. In this case it isn’t worth the overhead.
- Create an archive of the whole thing.
Here’s the end result
Finally, I need Jenkins to archive the artifact and define which jobs can access
copyArtifacts. Right after the last build step I add:
letting Jenkins know the location of the build artifact. Then adding the following to the pipeline configuration before the parameters:
That a job named
m2-demo-store/DeployDemoStore access to the build artifact.
I’ll work on the deploy job another day. You can see find the complete
Jenkinsfile on GitHub