Acquia Developer Portal Logo

A Step by step guide for using Code Studio to trigger another project's build

  • Last updated
  • 2 minute read

Goal

Learn how to configure an Acquia’s Code Studio build process to trigger a build in another project. This would include pulling in a custom module, external library, distribution profile or an Acquia Site Factory External Theme. 

Prerequisites

  • Basic knowledge of Drupal development
  • Acquia’s Code Studio build process
  • Composer / Drupal-Scaffold
  • Acquia Cloud

Overview

Acquia’s comprehensive Drupal development toolchain is geared towards best practice Drupal DevOps, and empowers users to customize the DevOps process to fit their business and technology needs in order to scale as projects and teams evolve. 

In this tutorial, I want to show how to have one Code Studio project trigger another or many Code Studio projects to run builds and deploy to the Cloud. I can think of many use-cases where this would be handy. Here are a couple.

  • Custom Drupal Modules - Use Code Studio to host your custom module repositories and trigger builds to your Drupal sites and pull in the latest version of the Custom Module whenever a branch is merged into the primary branch.
  • External Component Libraries -  Similar to above, host your external component library in a Code Studio project and trigger the latest build to deploy to all your other Code Studio projects. This works great when using Acquia’s Site Studio and an external library. 
  • Drupal Distribution - Deploy a distribution to multiple Drupal sites, auto deploying Security and Code Updates.
  • Acquia Site Factory External Themes - ACSF has the ability to pull in external theme repositories. Use Code Studio to host and test the themes prior to getting merged into the site repository. This also gives you more flexibility to restrict the design team from accessing the Drupal repository.    

I was inspired by Dries Buytaert's recent blog ‘The evolution of Drupal's composability: from the command line to the browser’, I wanted to break down this statement “explore how Drupal's composability is evolving to empower ambitious site builders with modern, no-code development practices.” to find other ways to make my projects more composible.

Composability is a design principle that allows systems to be assembled from smaller, independent components. This makes it easier to create new systems by combining existing components.

Code Studio adds another layer to the concept of composability on Acquia’s full stack Drupal development platform. Based on Gitlab, Code Studio is a fully managed CI/CD pipeline optimized for Drupal that enables your teams to plan, build, test, review, and deploy from a single, customizable workflow that integrates with Acquia Cloud or Site Factory Platforms. Just by adding a .gitlab-ci.yml file and changing one setting to customize Acquia's out-of-the-box workflow / build-process. They make it easy to customize and add your own steps, jobs or tasks to your projects build process. 

Using this concept, you can separate all your projects into different Code Studio projects with their own git repositories / history, their own customized build process, running their own tests in the CI and then triggering a release. This should save time, give move flexibility on who has access to what and add major value to the overall DevOps architecture.

Steps

In this example, we’ll use a simple custom drupal module and the concept of adding an external module to your site or many sites.

The idea would be that when you update your Drupal custom module code, that should trigger any Drupal Code project you have defined to build, pull in the latest version of your module defined in your composer file and release the new version to the Cloud. 

  1. Start with a working project Drupal project using Code Studio

    First we need a working Code Studio project with Drupal installed and configured to deploy to the Acquia Cloud. If you have not yet, follow these instructions - How to set up a new project in Code Studio, using a Cloud IDE.

  2. Customize the build with your own .gitlab-ci.yml file

    In order to customize the build process, we will need to make a new .gitlab-ci.yml file and make one change in the settings. 

    Add the following to your .gitlab-ci.yml file

    include:
  - project: 'acquia/standard-template'
    file:
      - '/gitlab-ci/Auto-DevOps.acquia.gitlab-ci.yml'

stages:
   - Build Drupal
   - Test Drupal
   - Deploy Drupal
   - Automatic Updates

"Build Code":
  after_script:
    - printf "The Build Code stage is complete."

    In /-/settings/ci_cd, General Pipelines and CI/CD configuration file, change this to the name of your new file, ‘.gitlab-ci.yml ’

  3. Create a new project for your custom module and add your new .gitlab-ci.yml file

    Now that we have a working Drupal project in Code Studio, next we need to create a new Code Studio project for the Drupal custom module. For this project, we do not need to follow the normal process of setting up a Code Studio project above. You can just go to https://code.acquia.com/ and click the blue button that says ‘New Project’, and create a blank project. 

    Similar to above, add the new .gitlab-ci.yml file and change the settings to a point to the new file. Add the following to that file as an example of a basic build.

    stages:
  - build

build-job:
  stage: build
  artifacts:
    when: always
    expose_as: 'flux-custom-module'
    paths:
      - ./custom_module
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

     

  4. Add your files to the new repository

    We now want to pull the new project repo down and add our custom module codebase. For testing, we can even just add a couple simple files to prove the concept. 

     

  5. Add your custom module to your primary project composer file

    Add your module to the drupal composer.json file in two places

    The required section

    "thomas-scola/custom_module_example": "^1.0"

    And the repository section

    "thomas-scola/custom_module_example": {
  "type": "package",
  "package": {
      "name": "thomas-scola/custom_module_example",
      "type": "drupal-module-custom",
      "version": "1.0.2",
      "source": {
          "url": "https://code.acquia.com/thomas-scola/custom_module_example.git",
          "type": "git",
          "reference": "main"
      }
  }
},

    Test this locally by running ‘composer install’ and see if the custom module shows up in ‘docroot/modules/custom/NAMEOFMODULE’ and in your Drupal site at ‘/admin/modules’. If this works, move onto the next step, adding the trigger.

     

  6. Add the trigger stage to your CI file

    Once you have both your projects setup and running their own builds successfully, next we want to connect the accounts in order to enable the trigger. In your custom module CI file, add the new stage to top and the trigger stage to the bottom.

    trigger_flux423:
  stage: trigger_drupal_job
  trigger:
    project: flux423/flux423
    strategy: depend

    The whole should look like this

    stages:
  - build
  - trigger_drupal_job

build-job:
  stage: build
  artifacts:
    when: always
    expose_as: 'flux-custom-module'
    paths:
      - ./custom_module
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

trigger_flux423:
  stage: trigger_drupal_job
  trigger:
    project: flux423/flux423
    strategy: depend

     

  7. All set, now let's test the build

     Let's test the build by pushing one more change to the custom module 

Conclusion

Using the steps above as a concept, the sky's the limit. Replace the custom module with a component library, a whole drupal distribution or multiple Site Factory external themes.

If you find the provided resources aren't enough, remember, our Professional Services (PS) team is here to help. Reach out through your Customer Success Manager (CSM) or account team for further assistance. 

 

Additional Resources

Similar Tutorials