3 posts tagged with "Automation"

The Drupal community is gearing up for Drupal 12, anticipated for release in mid-2026. A critical part of this transition is the relaunch of the Deprecation Dashboard, a tool that provides a bird's-eye view of the readiness of contributed modules and core components.

One of the most significant changes in the Drupal 12 readiness strategy is a policy shift: most disruptive deprecations from Drupal 11.3 onwards will be deferred until Drupal 13. This move is designed to make the jump from Drupal 11 to 12 as smooth as possible, maintaining consistency in public APIs and allowing maintainers to adopt the new version earlier.

The New Deprecation Dashboard​

The relaunched dashboard, now hosted on docs.acquia.com, offers real-time insights into which modules are already compatible and which still have work to do. It leverages static analysis and automated testing to track progress across the entire ecosystem.

Key tools mentioned in the relaunch include:

• Upgrade Status Module: The go-to module for in-site assessment.
• drupal-check: A standalone CLI tool built on PHPStan.
• mglaman/phpstan-drupal: The engine behind most modern Drupal static analysis.

Building a Targeted Drupal 12 Readiness CLI​

To complement the existing tools, I've built a lightweight, targeted CLI tool: Drupal 12 Readiness CLI. While drupal-check is excellent for general deprecations, this tool is specifically configured to help developers identify the critical path for Drupal 12.

The tool wraps phpstan-drupal and phpstan-deprecation-rules into a single, zero-config command that you can run against any Drupal module or theme directory.

Key Features:​

• Automated Discovery: Automatically identifies Drupal core and dependencies in your project.
• Targeted Analysis: Focuses on level 1 analysis with full deprecation rule coverage.
• CI Ready: Designed to be integrated into GitHub Actions or GitLab CI.

View Code​

You can find the full source code and installation instructions on GitHub: victorstack-ai/drupal-12-readiness-cli

Example Usage​

# Install via Composer
composer require --dev victorstack-ai/drupal-12-readiness-cli

# Run the scan
./vendor/bin/drupal-12-readiness scan web/modules/custom/my_module

The tool will report any deprecated API calls that need attention before Drupal 12, giving you a clear roadmap for your upgrade path.

By staying ahead of the deprecation curve, we ensure that the Drupal ecosystem remains robust and ready for the next generation of digital experiences.

The release of Terminus 4.1.4 reminds us that the most critical part of our deployment pipeline isn't always the code we write, but the tools we use to ship it.

Why I Built This (Or rather, why I track it)​

I maintain several automation pipelines that rely heavily on the Pantheon CLI (Terminus) to manage environments, clear caches, and deploy code. When a tool like this gets a version bump, it’s not just "maintenance"—it's a signal to check our dependencies. Ignored CLI updates are a ticking time bomb in CI/CD; eventually, an API changes or a PHP version is deprecated, and your Friday deploy fails because your runner is using a two-year-old binary.

Terminus 4.1.4 targets stability and compatibility. In a world of flashy AI agents and complex orchestration, rock-solid platform CLIs are the unsung heroes that actually move the bits.

The Strategy: Managed CLI Updates​

Upgrading a CLI locally is easy (brew upgrade), but managing it in CI requires a strategy to balance stability with security. I've moved from "install latest" to a pinned-version approach with automated checks.

Here is a typical decision flow for adopting a new CLI release like 4.1.4:

Automation Patterns​

Updating your CI runners shouldn't be a manual task. Here is how I handle Terminus versions across different environments.

# A safer way to install Terminus in GHA
# Instead of pulling 'latest', we specify the version to avoid surprises
- name: Install Terminus 4.1.4
  run: |
    curl -O https://github.com/pantheon-systems/terminus/releases/download/4.1.4/terminus.phar
    chmod +x terminus.phar
    sudo mv terminus.phar /usr/local/bin/terminus
    terminus --version

{
  "require-dev": {
    "pantheon-systems/terminus": "^4.1.4"
  },
  "config": {
    "allow-plugins": {
      "pantheon-systems/terminus": true
    }
  }
}

The Code​

No separate repo—this is an operational update based on the Terminus 4.1.4 Release.

What I Learned​

• Release Notes Matter: Even minor versions (4.1.x) can introduce PHP compatibility changes. 4.1.4 likely solidifies support for newer PHP runtimes, which is essential as platforms deprecate PHP 8.1/8.2.
• Phar vs. Composer: For CI, I strictly prefer the PHAR (PHP Archive) installation. It isolates the CLI's dependencies from my project's dependencies, preventing "dependency hell" where the CLI requires guzzlehttp/guzzle version X but my project needs version Y.
• Silent Failures: I noticed that older versions of CLI tools sometimes fail silently on newer OS images. Keeping close to the latest stable release (like 4.1.4) mitigates the risk of OS-level incompatibilities (e.g., OpenSSL versions).

References​

• Terminus 4.1.4 Release

As AI agents become part of the Drupal workflow, we need infrastructure that makes automation traceable, predictable, and composable. I built four small Drupal modules that together form an MCP Toolkit for agent-driven site management.