How to Automate Dependency Updates with GitHub Actions

Staying up to date with security patches and releases can be a daunting task for organizations and teams managing several projects. Previously, we wrote about two methods you can use to help automate the work for you, using Renovate and GitHub’s Dependabot:

• How to Automate Dependency Updates with Renovate
• How to Automate Dependency Updates with GitHub Dependabot

However, we started noticing that Dependabot was not always working correctly for us and others, causing it to fail. Apparently, dependency resolution may take too long to compute and cause the service to time out. There is no update on a fix yet from GitHub on when they will get Dependabot working again for Composer-based projects.

Fortunately, there is another way to do this, and it uses GitHub Actions. GitHub Actions is a feature of GitHub that lets you add runnable tasks to repositories when an event occurs – like pushing a branch or merging a branch. If you have used services like CircleCI, TravisCI or DroneCI, it is very similar and uses YAML based configuration files. GitHub Actions aren’t just for CI though and comes with a lot of advantages those services don’t have, which we will demonstrate in future posts.

You can automatically schedule GitHub Actions at specific intervals, like ‘run every morning at 5 AM’ or ‘every Friday.’ This is how we will approach checking for Drupal core updates, swapping out the Dependabot configuration we used to use.

GitHub Action Configuration

Our GitHub Action script is going to do the following:

• Check out the main branch
• Install the current list of packages with Composer
• Determine if there is a newer version of Drupal core available
• Create a Pull Request in GitHub of the updates

Our Action is going to run every day at 5 AM. GitHub Actions are executed in UTC time, so ‘10’ in the cron schedule value below is 5 AM EST for where we are located. Here is an example of how the workflow could work:

name: Drupal core updates 
on: 
  workflow_dispatch: 
  schedule: 
    - cron: '0 10 * * *' 
jobs: 
  core-updates: 
    runs-on: ubuntu-latest 
    steps: 
      - uses: actions/checkout@v3 
      - name: Install PHP 
        uses: shivammathur/setup-php@v2 
        with: 
          php-version: 8.1 
      - name: Composer install with dev dependencies 
        run: composer install -n --optimize-autoloader --ignore-platform-reqs 
      - name: Store current version for reference 
        run: | 
          echo "ORIGINAL_CORE_VERSION=$(composer show drupal/core-recommended | grep "versions : \* [0-9.]" | cut -d' ' -f 4 | xargs -n1 basename)" >> $GITHUB_ENV 
 
      - name: Check for Drupal core updates 
        run: | 
          composer update drupal/core-* -W 
      - name: Getting updated version, if applicable 
        run: | 
          echo "UPDATED_CORE_VERSION=$(composer show drupal/core-recommended | grep "versions : \* [0-9.]" | cut -d' ' -f 4 | xargs -n1 basename)" >> $GITHUB_ENV 
      - name: Get current date and time 
        run: | 
          echo "JOB_CURRENT_TIME=$(date +'%Y-%m-%d.%s')" >> $GITHUB_ENV 
      - name: Generate a pull request 
        if: ${{ env.ORIGINAL_CORE_VERSION != env.UPDATED_CORE_VERSION }} 
        uses: peter-evans/create-pull-request@v5 
        with: 
          token: ${{ secrets.ACCESS_TOKEN }} 
          commit-message: Update drupal/core-* packages to ${{ env.UPDATED_CORE_VERSION }} 
          title: Update drupal/core-* packages to ${{ env.UPDATED_CORE_VERSION }} 
          body: | 
            Update drupal/core-* packages to ${{ env.UPDATED_CORE_VERSION }} 
          branch: release/drupal-core-${{ env.UPDATED_CORE_VERSION }}-${{ env.JOB_CURRENT_TIME }} 
          delete-branch: true 

Essentially, we are processing the updates and evaluating the version. If we detect the version has been updated, then a Pull Request is opened in GitHub noting the version:

We are making use of the excellent create-pull-request action to take care of some of the heavy lifting to make that step as simple as possible. Do note that it requires using a fine-grained token in GitHub. The token requires the following permissions:

• Read access to actions and metadata
• Read and Write access to code, issues, pull requests, and workflows

Since a Pull Request was opened, it kicks off other GitHub Actions that we have in place that run checks and validations before allowing the merge. Like the outcome in our other posts, this does the work across all your projects to note all pending core updates that should be reviewed and deployed.

Overall, the action takes less than a minute and a half from start to finish. As an added step, you could set up the Pull Request to be automatically merged, ensuring security or minor updates go out unattended. That is best used in scenarios where you have lower environments for testing and automated tests for your custom module(s) to ensure they function correctly. This might be applicable if you want to stay updated immediately when security or core releases occur.

We will be writing more on using GitHub Actions this year detailing how those workflows operate and how you can use them to automate other housekeeping tasks.

Get the Drupal 10 Development Cookbook 

Drupal 9 is now the end of its life. Have you upgraded to Drupal 10 yet? Are you facing some difficulties? We have a great resource that can help you!

The "Drupal 10 Development Cookbook" is co-authored by Matt Glaman and me, Kevin Quillen. We cover a wide variety of topics with hands-on examples so you can get up and running with Drupal 10 in no time. These topics include running Drupal locally with Docker-based tools, content modeling, creating custom modules, how to do automated testing, and migrating data into Drupal from various data sources. The book will help you understand how to develop and build modules just like the ones we talk about often at Velir.  

What others are saying:

You can pick up the book on Amazon as a physical copy or for Kindle.