How to connect GitLab and Pantheon and optimize Drupal and WordPress workflows

Our guest, creator of Pantheon developer tools, tells how to automate WordPress deployments using GitLab CI / CD.

In Pantheon, I’m involved in developer relations, so I’m always looking for new ways to help WordPress and Drupal developers solve automation problems in their workflows. For this, I like to experiment with new tools and combine them with each other to work effectively.

I often see developers suffering with a single development server.

So it’s a pleasure to wait for your turn to use the server or to send a URL to your customers with the note: “Look here and not look here.”

The multidev environments - one of the coolest Pantheon tools - solve this problem, because with them you can create Git environments on demand. Each multidev environment has its own URL and database, so developers work calmly, check quality and get approval without stepping on each other’s heels.

But in Pantheon there are no tools for version control or continuous integration and deployment (CI / CD). But this is a flexible platform from which you can integrate any tools.

I also noticed that for the development team use some tools, and for assembly and deployment - others.

For example, they have different tools for version control and CI / CD. You have to mess around and switch between tools to edit the code and diagnose problems.

GitLab has a complete set of development tools: for version control, tickets, merge requests, best-in-class pipeline CI / CD, container registry and stuff like that. I have not come across any applications in which there would be so much to manage the development workflow.

I love automation, so I learned how to connect Pantheon to GitLab so that commits to the main branch on GitLab are deployed to the main development environment in Pantheon. And merge requests for GitLab can create and deploy code in multidev environments in Pantheon.

In this tutorial, I’ll show you how to set up a connection between GitLab and Pantheon and optimize WordPress and Drupal workflows.

You can, of course, mirror the GitLab repository , but we will all be doing pens to delve into GitLab CI and in the future use this tool not only for deployment.

Introduction

For this post you need to understand that Pantheon breaks each site into three elements: code, database and files.

The code includes CMS files, such as the core, plugins, and WordPress themes. These files are managed in the Git repository hosted by Pantheon, that is, we can deploy the code from GitLab to Pantheon from Git.
The files in Pantheon are media files, that is, pictures for the site. Usually they are loaded by users, and Git ignores them.

Create a free account , learn more about the Pantheon workflow, or sign up for the pantheon.io demo .

Assumptions

My project on Pantheon and GitLab is called pantheon-gitlab-blog-demo . The project name must be unique. Here we will work with the WordPress site. You can take and Drupal, but will need to change something.

I will use the Git command line , and you can work in the GUI if you want.

Create a project

To begin, create a project GitLab (to this we will come back).

Now create a WordPress site on Pantheon . Then install WordPress for the dashboard site.

If your hands itch to change something, for example, plug-ins to remove and add, be patient. The site is not yet connected to GitLab, and we want all code changes to go through GitLab.

When we install WordPress, we return to the Pantheon site dashboard and change the development mode to Git.

Initial commit on GitLab

Now you need to transfer the initial WordPress code from Pantheon to GitLab. To do this, we clone the code from the Git repository of the Pantheon site locally, and then send it to the GitLab repository.

To make it easier and safer, we will add an SSH key to Pantheon and will not enter the password every time we clone the Pantheon Git repository. At the same time we will add an SSH key to GitLab .

To do this, we clone the Pantheon site locally by copying the command from the Clone with Git field on the site's dashboard.

If you need help, read the Git Getting Started documentation for Pantheon .

Now we’ll change git remote origin to point to GitLab instead of Pantheon. This can be done git remote .

Let's go to the GitLab project and copy the repository URL from the Clone drop-down list on the project details page. Choose the option Clone with SSH, because we have already configured an SSH-key.

By default, git remote for the local copy of the code repository is origin . This can be changed with git remote set-url origin [URL GitLab] , where instead of brackets we enter the actual URL.

Finally, run git push origin master --force to send the WordPress code from Pantheon to GitLab.

The –force option is needed only once. Then in the git push commands on GitLab it will not be.

Configuring credentials and variables

Remember how we locally added an SSH key to log in to Pantheon and GitLab? SSH token can be used to authorize GitLab and Pantheon.

GitLab has excellent documentation. Let's take a look at the section on SSH keys when using the Docker executor in the document on using SSH keys with GitLab CI / CD .

Now we will perform the first two steps: create a new pair of SSH keys locally with ssh-keygen and add the private key as a variable to the project .

Then we set SSH_PRIVATE_KEY as a GitLab CI / CD environment variable in the project parameters.
In the third and fourth steps, create a .gitlab-ci.yml with the following contents:

 before_script: # See https://docs.gitlab.com/ee/ci/ssh_keys/README.html - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config" - git config --global user.email "$GITLAB_USER_EMAIL" - git config --global user.name "Gitlab CI" 

Until we commit the .gitlab-ci.yml , then we will need to add something else to it.

Now we perform the fifth step and add the public key, which was created in the first step, to the services to which you need access in the build environment .

In our case, we want to access Pantheon from GitLab. Follow the instructions in the Pantheon document for adding an SSH key to Pantheon and perform this step.

Remember: closed SSH - in GitLab, open - in Pantheon.

Set up some more environment variables. The first is called PANTHEON_SITE. Its meaning is the name of the site Pantheon on your car.

The name on the machine is listed at the end of the Clone with Git command. You have already cloned the site locally, so this will be the name of the local repository directory.

Next, set up the environment variable PANTHEON_GIT_URL . This is the Git repository URL for the Pantheon site that we already used.

We enter only the URL of the SSH repository, without git clone and the name of the site on the machine at the end.

Fuh. This is done, now we can finish our .gitlab-ci.yml .

Create deployment task

What we initially do with GitLab CI is very similar to what we did with Git repositories before. But this time we will add the Pantheon repository as the second remote source of Git, and then send the code from GitLab to Pantheon.

To do this, set up the deploy stage and the task deploy:dev , because we will deploy to the development environment on Pantheon. As a result, the .gitlab-ci.yml will look like this:

 stages: - deploy before_script: # See https://docs.gitlab.com/ee/ci/ssh_keys/README.html - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config" - git config --global user.email "$GITLAB_USER_EMAIL" - git config --global user.name "Gitlab CI" deploy:dev: stage: deploy environment: name: dev url: https://dev-$PANTHEON_SITE.pantheonsite.io/ script: - git remote add pantheon $PANTHEON_GIT_URL - git push pantheon master --force only: - master 

The variables SSH_PRIVATE_KEY, PANTHEON_SITE and PANTHEON_GIT_URL should look familiar - we set up these environment variables before. With these variables, we will be able to use the values ​​in the .gitlab-ci.yml many times and only need to be updated in one place.

Finally, add, commit and send the .gitlab-ci.yml to GitLab.

Check warm

If we did everything right, the task deploy:dev succeed in GitLab CI / CD and send the .gitlab-ci.yml to Pantheon. Let's get a look.

Send Merge Requests to Pantheon

Here we will use my favorite Pantheon feature - multidev , where you can create additional Pantheon environments for Git branches on demand.

Access to multidev is limited , so this section may not be performed. But if you have access, you can seriously increase your productivity by setting up automatic creation of multidev environments on Pantheon from GitLab requests.

First, make a new Git branch locally using git checkout -b multidev-support . Now again, let's change something in .gitlab-ci.yml .

I like to indicate the number of the merge-request in the name of the Pantheon environment. For example, the first merge requester is mr-1 , the second is mr-2 and so on.

The merge request changes, so we need to dynamically determine the names of the Pantheon branches. On GitLab, this is easy - you need to use predefined environment variables .

We can take $CI_MERGE_REQUEST_IID to indicate the number of the merge-request. Let's apply all this together with the global environment variables that we specified earlier, and add a new deploy task: multidev at the end of the .gitlab-ci.yml .

 deploy:multidev: stage: deploy environment: name: multidev/mr-$CI_MERGE_REQUEST_IID url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/ script: # Checkout the merge request source branch - git checkout $CI_COMMIT_REF_NAME # Add the Pantheon git repository as an additional remote - git remote add pantheon $PANTHEON_GIT_URL # Push the merge request source branch to Pantheon - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force only: - merge_requests 

It will be similar to our deploy:dev task, only the branch goes to Pantheon, not to master .

We have added and committed the updated .gitlab-ci.yml , and now we will send a new branch to GitLab with git push -u origin multidev-support .

Now we will create a new merge-request from the multidev-support branch by clicking Create merge request .

Having created a merge request, we look at how the CI / CD deploy:multidev .

See - a new branch has been sent to Pantheon. But if we move to the multidev section on the Pantheon site dashboard, we will not see a new environment there

Look at the Git Branches section.

As a result, our mr-1 branch reached Pantheon. Create an environment from the mr-1 branch.

We created a multidev environment, and now we’ll go back to GitLab and take a look at Operations> Environments . We will see entries for dev and mr-1 .

This is because we have added an environment entry with the name name and url to the CI / CD tasks. If you click the open environment icon, we will go to the multidev environment URL to Pantheon.

Automating the creation of multidev

In principle, you can stop at this and simply remember to create a multidev environment for each merge-request, but this process can be automated.

Pantheon has a Terminus command line tool where you can work with the platform automatically. In Terminus, you can create multidev environments from the command line — ideal for GitLab CI .

We need a new merge request to test it. Create a new branch using git checkout -b auto-multidev-creation .

To use Terminus in GitLab CI / CD tasks, you need a machine token for authentication with Terminus and an image of a container with Terminus.

Create a Pantheon machine token , save it in a safe place, and add it as a global environment variable in GitLab called PANTHEON_MACHINE_TOKEN .

If you forgot how to add GitLab environment variables, go back to where we defined PANTHEON_SITE .

Create a Dockerfile with Terminus

If you are not using Docker or do not like Dockerfile files, take my image to registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest and skip this section.

GitLab has a container registry where you can build and place a Dockerfile for our project. Let's create a Dockerfile file from Terminus to work with Pantheon.

Terminus is a PHP command line tool, so let's start with a PHP image. I install Terminus through Composer, so I will take the official image of Docker Composer as the basis. Create a Dockerfile in the local repository directory with the following contents:

 # Use the official Composer image as a parent image FROM composer:1.8 # Update/upgrade apk RUN apk update RUN apk upgrade # Make the Terminus directory RUN mkdir -p /usr/local/share/terminus # Install Terminus 2.x with Composer RUN /usr/bin/env COMPOSER_BIN_DIR=/usr/local/bin composer -n --working-dir=/usr/local/share/terminus require pantheon-systems/terminus:"^2" 

Follow the instructions for building and submitting images from the Build and push images section in the container registry documentation to build an image from the Dockerfile and send it to GitLab.

Open the Registry section in the GitLab project. If everything went according to plan, there will be our image. Write a link to the image tag - we need it for the .gitlab-ci.yml .

The script section in the deploy:multidev begins to grow, so let's move it to a separate file. Create a new private/multidev-deploy.sh:

 #!/bin/bash # Store the mr- environment name export PANTHEON_ENV=mr-$CI_MERGE_REQUEST_IID # Authenticate with Terminus terminus auth:login --machine-token=$PANTHEON_MACHINE_TOKEN # Checkout the merge request source branch git checkout $CI_COMMIT_REF_NAME # Add the Pantheon Git repository as an additional remote git remote add pantheon $PANTHEON_GIT_URL # Push the merge request source branch to Pantheon git push pantheon $CI_COMMIT_REF_NAME:$PANTHEON_ENV --force # Create a function for determining if a multidev exists TERMINUS_DOES_MULTIDEV_EXIST() { # Stash a list of Pantheon multidev environments PANTHEON_MULTIDEV_LIST="$(terminus multidev:list ${PANTHEON_SITE} --format=list --field=id)" while read -r multiDev; do if [[ "${multiDev}" == "$1" ]] then return 0; fi done <<< "$PANTHEON_MULTIDEV_LIST" return 1; } # If the mutltidev doesn't exist if ! TERMINUS_DOES_MULTIDEV_EXIST $PANTHEON_ENV then # Create it with Terminus echo "No multidev for $PANTHEON_ENV found, creating one..." terminus multidev:create $PANTHEON_SITE.dev $PANTHEON_ENV else echo "The multidev $PANTHEON_ENV already exists, skipping creating it..." fi 

The script is in a private directory and does not provide web access to Pantheon . We have a script for our multidev logic. Let's now update the deploy:multidev the .gitlab-ci.yml file to .gitlab-ci.yml this:

 deploy:multidev: stage: deploy environment: name: multidev/mr-$CI_MERGE_REQUEST_IID url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/ script: # Run the multidev deploy script - "/bin/bash ./private/multidev-deploy.sh" only: - merge_requests 

We need to make sure that our tasks are performed in the created custom image, so we add the image definition from the registry URL to .gitlab-ci.yml . As a result, we have such a .gitlab-ci.yml :

 image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest stages: - deploy before_script: # See https://docs.gitlab.com/ee/ci/ssh_keys/README.html - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config" - git config --global user.email "$GITLAB_USER_EMAIL" - git config --global user.name "Gitlab CI" deploy:dev: stage: deploy environment: name: dev url: https://dev-$PANTHEON_SITE.pantheonsite.io/ script: - git remote add pantheon $PANTHEON_GIT_URL - git push pantheon master --force only: - master deploy:multidev: stage: deploy environment: name: multidev/mr-$CI_MERGE_REQUEST_IID url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/ script: # Run the multidev deploy script - "/bin/bash ./private/multidev-deploy.sh" only: - merge_requests 

Add, commit and send private/multidev-deploy.sh and .gitlab-ci.yml . Now go back to GitLab and wait for the CI / CD task to complete. Be patient: multidev can take several minutes.

Then we go to watch the multidev list on Pantheon. Oh miracle! Wednesday multidev mr-2 is here.

Conclusion

My team earned much more fun when we began to open merge-requests and create environments automatically.

With the powerful tools GitLab and Pantheon, you can connect GitLab to Pantheon automatically.

Once we use GitLab CI / CD, our workflow will grow. Here are a couple of ideas to get started:

• Add an assembly step.
• Add automated testing.
• Add a task to ensure adherence to code standards.
• Add dynamic application security testing .

Write what you think about GitLab, Pantheon and automation.

PS Did you know that Terminus, the Pantheon command line tool, can be extended via plugins ?

We at Pantheon did a good job on version 2 of our plug-in for Terminus build tools with GitLab support. If you do not want to bother with the setting for each project, try this plugin and help us test the beta v2. For the Terminus build:project:create command, you only need the Pantheon token and the GitLab token. It will deploy one of the sample projects with Composer and automated testing, create a new project in GitLab, the new Pantheon site, and connect them with environment variables and SSH keys.

about the author

Andrew Taylor creates tools for developers in Pantheon .