fidzu : Drupal

How Drupal contributed modules do CI today?

Let's give some more details about how did we get here.

The past

In summer 2023, only 2 and a half years from today, we enabled the usage of GitLab CI for the Drupal ecosystem, which includes all contrib modules and Drupal core. We announced and promoted it at DrupalCon Lille 2023.

This new system would replace entirely the DrupalCI, the custom testing solution that Drupal core and projects used for nearly 10 years prior to enabling GitLab CI.

Core tests went from taking nearly 1h to taking 10 minutes. Adoption for contrib modules was as easy as adding a six-line file to their project.

The present

Core continued to evolve at its own pace, and the CI runs are now down to 5 minutes. They've been able to leverage concurrency, caching, and many other features available on GitLab CI.

Contrib modules also saw significant changes to improve their quality. Adoption was continuously growing, and the standard templates really took off, adding many new features.

As of today, we have more than 2000 contrib projects using GitLab CI.

Jobs

We offer, without writing a single line of code, the same type of tests and checks that core does.

These are: Composer lint, PHPCS, CSpell, PHPStan, ESLint, Stylelint, Nightwatch, PHPUnit, Test-only.

In addition to those, we also have: Upgrade status, Drupal CMS, GitLab Pages.

You can see that having things like "Upgrade status" or "Drupal CMS" compatibility are key for our contrib modules, and it's available out of the box.

Also, the GitLab Pages job allows for modules to publish a full documentation site based on their markdown files. If the files are there, the documentation site will be published. An example of this is our own documentation site for the shared CI templates: https://project.pages.drupalcode.org/gitlab_templates.

Most of these jobs will offer artifacts that can be downloaded by maintainers to fix the issues reported.

Customizations

Most of the above jobs can be disabled, if they are not wanted, with only a few lines of code (turn variables to 0).

We can also test multiple versions of Drupal, like the next or previous minors or majors, again with a few lines of code (turn variables to 1).

We achieved this by extending base jobs that can be configured via variables, like this:

composer:
  extends: .composer-base
  variables:
    DRUPAL_CORE: $CORE_STABLE
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

composer (max PHP version):
  extends: .composer-base
  rules:
    - *opt-in-max-php-rule
    - *check-max-php-version-rule
    - when: always
  variables:
    PHP_VERSION: $CORE_PHP_MAX
    DRUPAL_CORE: $CORE_STABLE
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

composer (previous minor):
  extends: .composer-base
  rules:
    - *opt-in-previous-minor-rule
    - when: always
  variables:
    DRUPAL_CORE: $CORE_PREVIOUS_MINOR
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

We always keep up with the latest core releases, so maintainers don't need to change anything to test the latest core versions. But if they want to "fix" the versions tested so these don't change, they can pin the version of the templates that they are using with just one line of code.

They can choose with PHP version or database engine to run tests with.

External integrations

The contrib templates can be used in external instances. This is actually a five-line file (similar to the one mentioned above), but the integration remains the same. We have several community members using the templates in their own GitLab instances with their own company projects, and everything works the same.

The future

Ever since we made the switch, we have positively shaped the contribution to Drupal. Module standards are very much aligned with core standards. We get really quick in-browser feedback about what to fix; we no longer need to upload extra (test-only) patches, etc.

The possibilities are endless, and we continue looking at the future as well. We are always open to hearing about improvements. For example, only recently, thanks to suggestions from the community, we added Drupal CMS compatibility check and support for recipes.

We are also checking if we can convert some of the jobs to reusable GitLab CI components (they weren't stable when we launched the templates).

All in all, the future looks bright, and we are really glad that we made this move as part of our broader GitLab initiative.

How other open source projects can adopt a similar solution (aka "implementation details")

Whether you have an open source project and want to do something similar, or you are just curious, here are some of the details about how we implemented this for the Drupal Ecosystem.

We had several goals in mind, some of them as must-haves, some of them as nice-to-haves. The must-haves were that it needed to be easy to adopt, and that it should allow the same functionality as the previous system. The nice-to-haves were that it would be easy to iterate and push changes to all projects using it, without project interaction, and that we could easily add new features and turn them on/off from a central place.

At the time, GitLab components were still in the works and didn't have a timeline to be stable, so we needed to think which other options were available. GitLab has the include functionality, that allows including external YAML files in a project's CI configuration. This was our starting point.

Template inheritance

We control the templates centrally at the GitLab Templates project. In there, you can see a folder called "includes", and those are the files that projects include. That's it! To make this easier, we provide a default template that gets prepopulated in GitLab and that containsthe right "includes" in the right places. The six-line template is here.

You can create a ".gitlab-ci.yml" file in the repo and add these:

include:
  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF
    file:
      - '/includes/include.drupalci.main.yml'
      - '/includes/include.drupalci.variables.yml'
      - '/includes/include.drupalci.workflows.yml'

From that moment on, the project "inherits" all the templates (that we control centrally) and will start running the above CI jobs automatically.

You can see that there are three main files: one with variables, one with global workflow rules, and one containing all the jobs.

That is just the base. Each project can deviate, configure, or override any part of the template as desired, giving them flexibility that we might not be able to accommodate centrally.

We created extensive documentation and generated a GitLab Pages site to help with this: https://project.pages.drupalcode.org/gitlab_templates.

Should you want to include this in any other external GitLab instance, you just need to adapt the above to be fully qualified links as explained in our documentation page here.

As mentioned before, we can push a change (eg: bug fix, new feature) centrally, and as long as the projects make reference to our files, they will automatically receive the changes. This gives us great flexibility and extendibility, and best of all, maintainers don't need to worry about it as it is automatic for their projects.

We define variables that control the Drupal versions to tests against, the workflow rules that determine which jobs run and under which conditions, and most important of all, the logic for all the jobs ran in the pipelines.

We did it this way because it was the solution that would allow us to get all the must-haves and all the nice-to-haves. It allows literally thousands of projects to benefit instantly from shared CI checks and integration without barely writing code.

Versioning

We don't need a complex system for this, as the code is relatively small and straightforward compared to other projects, but we realised early that we needed a system because pushing the "latest" to everybody was risky, should a bug or unplanned issue arise.

We document our versioning system in the "Templates version" page. We use semver tagging, but we only maintain one branch. Depending on the changes introduced since the last tag, we increment X.Y.Z (X for breaking changes, Y for new features, Z for bug fixes), and we also generate a set of tags that will allow maintainers to pin specific versions, or moving-tags within the same major or minor. You can see the tagging script we use here.

Excerpt:

# Compute tags.
TAG="$1"
IFS=. read major minor micro <<<"${TAG}"
MINOR_TAG="${major}.${minor}.x-latest"
MAJOR_TAG="${major}.x-latest"

...
echo "Setting tag: $TAG"
git tag $TAG
git push origin $TAG

...
echo "Setting latest minor tag: $MINOR_TAG"
git tag -d $MINOR_TAG || TRUE
git push origin --delete $MINOR_TAG || TRUE
git tag $MINOR_TAG
git push origin $MINOR_TAG

...
echo "Setting latest major tag: $MAJOR_TAG"
git tag -d $MAJOR_TAG || TRUE
git push origin --delete $MAJOR_TAG || TRUE
git tag $MAJOR_TAG
git push origin $MAJOR_TAG

This process has been working well for us for around 2 years already.

Pushing changes to all contributed projects

Once the above versioning system was implemented, it was easier and quicker to iterate, and it also gave maintainers a chance to pin things. We normally push changes to the "main" branch, so all users wanting the latest changes can both benefit from them and also help us discover any possible regressions.

Once we are happy with the set of changes from the last tag, we can create new tags that maintainers can reference. Also, once we are happy that a tag is stable enough, we have a special tag named "default-ref" and all we need to do is change that tag to point to the specific stable version we want. Once we do it, that tag will automatically be pushed to all the contributed projects using the default setup.

The script that we use to set the default tag can be seen here.

Excerpt:

TAG="$1"
DEFAULT_TAG="default-ref"

echo "Setting default tag to be the same as: $TAG"

# Checkout the tag.
git checkout $TAG

# Override the default one.
git tag -d $DEFAULT_TAG || TRUE
git push origin --delete $DEFAULT_TAG || TRUE
git tag $DEFAULT_TAG
git push origin $DEFAULT_TAG

# Back to the main branch.
git checkout main

Implement it in your project

In the spirit of open source, we've documented the overarching strategy we used so that other teams fostering open source projects can adopt similar principles. We wanted to share how we did it, in case it helps any other project.

The key is to have a central place where you can control the default setup, and from there on, let projects decide what's best for their needs. They can stick to the default and recommended setup, but they could deviate from it should they need to.

On December 9th, 2025, the Drupal community gathered in Paris for a special AI summit.

As part of the larger apidays / FOST conference, we held the inaugural Drupal AI Summit designed specifically for end customers. Despite a compressed four-week organization window and a marketing campaign that ran for only three weeks, the event was oversubscribed with 170+ registered attendees.

We saw a standing-room-only crowd, peaking at around 120 people, with a sustained audience of 80-90 highly engaged delegates throughout the day. Crucially, many attendees spilled in from the wider conference, people who hadn't considered Drupal before but were drawn in by the energy and the promise of our open ecosystem.

Watch the highlights reel here! (Credit: Dan Lemon, Amazee.io)

Why the World is Watching Drupal AI

The summit attracted a diverse mix of end users, agencies, and AI specialists from the UK, Switzerland, Germany, the Netherlands, Italy, and beyond. We saw heavy representation from Higher Education, Government, Manufacturing, and Enterprise sectors.

Why the sudden surge in interest? Because the Drupal AI Initiative is moving at incredible speed and momentum, leading to attracting many developers back into the community.

Want to be notified when the next Drupal AI events are coming? Follow us on LinkedIn.

One moment captured this velocity perfectly: a slide presented during the opening remarks claimed Drupal AI supported 50 AI providers, which was already outdated a week later, with another few providers being added to the list. This is the power of the open web.

While proprietary systems lock you in, the Drupal AI ecosystem expands daily, offering sovereignty, flexibility, and rapid innovation that closed platforms simply cannot match.

Showcasing the Ecosystem

The day featured eleven leading experts who demonstrated that Drupal is the most robust platform for building AI-driven digital experiences. The sessions proved that whether you need autonomous agents, secure enterprise data handling, or next-generation search, Drupal is ready today.

The Architecture of the Future

We explored the foundational power of Drupal as an orchestration layer. Alex Moreno (Pantheon) showcased how our modular architecture makes Drupal the ideal bridge between content, data, and intelligence. Giorgi Jibladze (Omedia) took this further by demonstrating Drupal as a Model Context Protocol (MCP) server, integrating seamlessly with tools like ChatGPT for interactive UI components.

Agents and Automation

The Summit highlighted that we are moving beyond simple chatbots. Marcus Johansson (FreelyGive) and Jamie Abrahams (FreelyGive) were standout voices here. Jamie introduced the Drupal AI Agent Framework, showing how we can build autonomous agents that create complex pages while keeping humans in the loop.

Marcus demonstrated the power of AI Automators, proving that complex, chained AI workflows can be built without writing a single line of code. Andrew Mallis (Kalamuna) showed how these agents can even revolutionize our workflows, using AI to "chat" with the migration process to speed up complex site upgrades.

Trust, Sovereignty, and UX

For our Enterprise and Government attendees, security was paramount. Dan Lemon (amazee.io) presented a privacy-first AI assistant that ensures data sovereignty when interacting with internal documents. Moritz Arendt (Open Social) discussed the ethics of AI in community platforms, focusing on maintaining trust. Emma Horrell (University of Edinburgh) proved that the success of these tools relies on people, sharing research on how AI-assisted editorial guidance can reshape web publishing in Higher Education.

Optimization and Search

We also looked at how content is consumed by machines. Christoph Breidert (1xINTERNET) introduced the concept of AIO (Artificial Intelligence Optimisation), teaching us how to prepare Drupal content for AI-generated search results. Artem Dmitriiev (1xINTERNET) showed how to build intelligent, semantic search tools without writing code, and Kristof Van Tomme (PRONOVIX) highlighted how AI automates documentation and "answer engine" optimization.

A Community Like No Other

This event was a huge success, not just in numbers, but in the connections made. It was a powerful way to promote Drupal to a non-Drupal audience, proving that our open-source ecosystem is the safest and most powerful bet for the future of AI.

After a day of high-speed innovation, we reconnected with our roots - human connection. We wrapped up the summit at the Paris Christmas market, sharing ideas over glühwein. It was a fitting end to a day about the future: high-tech solutions grounded in a warm, collaborative community.

Here's to wishing we all get an upgraded Drupal site with AI for Christmas!

Want to be notified when the next Drupal AI events are coming? Follow us on LinkedIn.

DrupalCon Nara brought together the Drupal community in beautiful Japan a couple of weeks back, and the AI track delivered something valuable: practical sessions showing how teams are using AI to solve real problems right now. This post by Witze Van der Straeten highlights seven presentations well worth watching.

Photo: Karl Hepworth

If you're selling or managing: Stop losing deals to "AI-Powered" competitors

"Selling Drupal in the AI Age" with Niels Aers

You know the scenario: a client gets excited about some "AI-powered" platform, and suddenly your Drupal proposal seems old-fashioned. Or worse, they ask "doesn't AI make CMSs obsolete?"

Niels from Dropsolid flips this conversation with one simple truth: AI needs good data to work, and Drupal is exceptional at organizing data. While many platforms just store messy text and images, Drupal has always structured everything properly. Think of it like the difference between throwing papers in a drawer versus filing them in organized folders with labels. When AI needs to find information, organized folders win every time.

He shares a great example from a Belgian water company. They added AI search to help their customer service team answer questions faster. The team loved it so much, it saved them so much time, that the company decided to invest in AI across the whole organization. One small win created momentum for everything else.

The session gives you the actual words and examples you need when talking to clients or leadership. It shows real cost comparisons and explains why Drupal's approach is actually more reliable and affordable than those flashy alternatives.

Watch this if: You're tired of losing deals to buzzwords, or you need to convince someone that Drupal isn't outdated.

Watch Selling Drupal in the AI Age on YouTube

If you're managing a team: How to actually get people using AI

"Lessons from Integrating AI Into Real Marketing Teams" with Akansha Saxena

Akanksha tells it straight: after six months of trying to get her marketing team at Acquaia to use AI, she learned that nobody really knows what they're doing yet, and that's okay.

Here's the disconnect: you see headlines saying "88% of marketers already use AI!" But then Massachusetts Institute of Technology publishes a study showing 95% of AI projects fail. Akanksha lived in that gap and figured out what actually works.

Photo: Karl Hepworth

She discovered four real problems. First, people aren't scared of AI. They're confused by it. Her solution? "Marketing AI Office Hours" every two weeks where the team could learn together and ask questions without feeling stupid.

Second problem: everyone's too busy to learn complicated new tools. Her solution? Start so small it feels silly. They added one button to their image library that says "Generate with AI" for creating image descriptions. That's it. One button. But it solved a real annoyance, and suddenly people trusted that AI could actually help.

Third problem: AI-generated content often sounds robotic. Her solution? Mix different tools and always have humans review the final result. Never just publish what AI creates without checking it.

The best part? She shows the money. Translating 100,000 words used to cost $6,000 with traditional services. With AI translation: $2.70. That's not a typo. That's a 99.95% cost savings.

Drupal AI brought 99.95% cost savings when compared with traditional services.

She also demonstrates a workflow she built in 15 minutes that automatically creates social media posts when you publish content, sends them to Slack for approval, then publishes them. No more copying and pasting between ten different tabs.

Watch this if: You've tried getting your team to use AI and it didn't stick. Her playbook shows how to make it work without forcing people into tools they hate.

Watch Lessons from Integrating AI Into Real Marketing Teams on YouTube.

Worried about security: Building AI that respects permissions

"Smart Search, Safe Search: How Drupal + AI Work Together" with Sachiko Nitta

Here's a problem most companies building AI features ignore: what happens when different people should see different information?

Satanita demonstrates this beautifully with "Pillow Street," a fake company's internal website. When someone from the finance team asks the AI chatbot "What's our Q3 revenue?", the AI answers with the actual numbers. When a regular employee asks the same question, the AI says "I cannot access that information."

This works because Drupal's permission system filters what information reaches the AI before it generates any response. The AI never sees data the person asking isn't allowed to access. It's Drupal doing what it already does well, controlling who can see what, but now protecting your AI features too.

Most companies building AI chatbots or search features don't think about this until it's too late. Then someone uses a clever question to trick the AI into revealing confidential information. Satanita shows how to build it right from the start.

He walks through the actual setup using tools available today. It's not overly complicated. He built the demo in a reasonable amount of time using standard Drupal modules.

Watch this if: You're building any kind of AI feature where not everyone should see everything. This shows you how to do it without expensive custom security layers.

Watch Smart Search, Safe Search: How Drupal + AI Work Together on YouTube.

Want AI to actually do things: From simple tasks to complex workflows?

"AI Agents in Drupal CMS - Create your own agent" with Vincenzo Gambino

Most AI demos show it generating text. Vincenzo shows AI making decisions and taking actions across multiple systems. His demo builds an event manager. You tell it "Create an event for DrupalCon Rome on November 25th." The AI figures out it needs to do two things: create an event post on your Drupal site AND add an entry to Google Calendar. It extracts the information from your sentence, converts the date to the right format, creates both items, then tells you it's done.

The key word is "figures out." You didn't tell it to do both those steps. It understood what an event means and what tools it has available, then decided what to do.

Vincenzo explains the difference between two approaches. Workflows are like recipes: step 1, step 2, step 3. Agents are like giving someone a goal and letting them figure out how to reach it. Workflows are more predictable. Agents are more flexible. Each has its place.

Workflows are more predictable. Agents are more flexible. Each has its place.

He also mentions something fascinating that nobody talks about: if you're building AI features in multiple languages, Japanese text costs 40% more to process than English. French costs 15% more. These aren't tiny differences. They're real budget impacts if you're serving global audiences.

Watch this if: You want AI to do more than write text. This shows how to build systems where AI coordinates multiple actions across different tools.

Watch AI Agents in Drupal CMS - Create your own agent on Youtube

If you need proof: Real companies using Drupal AI today

"Epic things you built with Drupal AI" with Michael Schmid

If you're skeptical whether this AI stuff actually works in the real world, Michael rapid-fires through ten companies already using it in production.

• World Cancer Day uses AI to automatically filter spam from story submissions.
• A French telecom built an image search that verifies whether they own the rights to use photos (99% accuracy).
• A UK council converted over 2,000 old PDF documents into accessible websites 240 times faster than doing it manually.
• A shipping company reduced problem resolution from weeks to minutes.
• A European train company processes 20,000 delay compensation claims per hour and actually improved customer satisfaction with the faster service.

The pattern? Most of these aren't flashy public features. They're internal tools that make teams more efficient. That's where AI has the biggest impact right now. Not replacing people, but giving them superpowers to handle volume they couldn't before.

Michael also announced that if you've built something with Drupal AI, even just an experiment, you can get help publishing a case study quickly by contacting the Drupal AI Initiative Marketing Team. They're actively collecting stories to show what's possible.

Watch this if: You need to convince someone this is real and not just hype. These are actual companies solving actual problems today.

Watch Epic things you built with Drupal AI on YouTube.

If you work globally: Respecting culture while moving fast

"The Future of Workflow Optimization with AI & Drupal Canvas" with Maggie Schroeder and Shumpei Kishi

This session includes a demo that's both entertaining and brilliant. The scenario: DrupalCon starts in two days, you need a Japanese landing page, leadership wants it today.

They use Drupal Canvas with AI to build a complete page with custom features in three minutes. But here's where it gets interesting. When they try to publish, someone says "Wait. This is for Japan. We need to do Nemawashi first."

Nemawashi is a Japanese business practice of informing key people before making announcements. Not asking permission, but showing respect by not surprising them. Normally this takes an hour: write an email summary, translate it to Japanese, figure out who should receive it, send it out.

Instead, they prompt the automation system with Drupal's ECA module: "Build a workflow when an article is published. Summarize the content in English and Japanese. Email the summary to the user named 'stakeholders'." The AI builds this workflow automatically. They publish the content, and the system handles the cultural protocol without manual work.

This demonstrates something important: AI can respect organizational and cultural requirements while still moving fast. It's not about eliminating processes. It's about automating the parts that slow you down.

The demo also shows Acquia Source Writing Assistant, which is trained specifically to write content that other AIs will cite and reference. It's not just about search engines anymore. It's about making sure ChatGPT and Claude mention your content when people ask questions.

Watch this if: You manage international teams or need to balance speed with proper organizational process.

Watch The Future of Workflow Optimization with AI & Drupal Canvas on YouTube.

If you're planning Drupal's future: Understanding the Strategic Vision

"Next steps for Drupal Canvas" with Lauri Timmanee

Most Canvas presentations show you how to build pages. Lauri shows you why Canvas exists and where it's going. Essential context if you're making strategic decisions about Drupal.

The mission is clear: make Drupal the gold standard for no-code website building. But AI has fundamentally changed what "gold standard" means. Three years ago, "easy but takes weeks" was acceptable. In 2025, when tools like Lovable can build functional prototypes in minutes, Drupal needs a different approach.

Lauri demonstrates this with a live comparison: building a tour listing page in Canvas takes about 7 minutes. The AI understands your existing components, content model, and field structure, then generates a working page using your design system. Not generic output that you have to rebuild. Actual production-ready components.

Here's what makes Canvas different from pure AI builders: it's built for scale. AI tools can create one page fast, but what happens when you have 1,000 pages and need to update the navigation? Canvas combines AI speed with CMS structure. The same reason CMSs replaced Dreamweaver 15 years ago.

AI tools can create one page fast, but what happens when you have 1,000 pages and need to update the navigation? Canvas combines AI speed with CMS structure.

The roadmap for 2026 includes features that directly address AI-era needs: integrated AI context control (so AI knows your brand voice), external AI tool support (use Cursor or PHPStorm with Drupal), translation support, and the ability to edit content directly inside Canvas layouts.

But the most interesting part? Lauri's honest about what they're still figuring out. How do you enable vertical markets? If Drupal wanted to dominate healthcare next year, what modules and improvements would make that happen? These questions are still open, which means this is the right time to influence the direction.

Watch this if: You're making long-term decisions about Drupal adoption, or you want to understand how Drupal is positioning itself against pure AI site builders.

Watch Next steps for Drupal Canvas on YouTube.

Why these sessions are different

Most AI presentations either promise magic that doesn't exist or show toy examples that don't translate to real work. DrupalCon Nara's sessions were different because they addressed real problems.

A pattern emerged across multiple sessions: AI gets you 80% of the way there, humans do the final 20%. This explains why so many AI projects fail. They aim for 100% automation when 80/20 is the sustainable approach. Keep humans involved for review, refinement, and final decisions.

Another theme: Drupal's permission system becomes your AI's security system. Whether it's search, content generation, or workflow automation, Drupal makes sure AI respects who should see what. Most AI vendors either skip this entirely or charge extra to build it custom.

Finally: everything is moving toward components. Think of components like LEGO blocks. Standardized pieces that fit together in predictable ways. AI is much better at understanding and using structured components than random layouts. Drupal is all-in on this approach.

The Bottom Line

The real story from DrupalCon Nara isn't about fancy features. It's about how Drupal is positioning itself for the AI era. Not by bolting on AI features, but by being the platform that combines AI's speed with the reliability, security, and structure that real organizations need.

Tools like Lovable can build things fast, but they can't manage thousands of pages, respect permissions, or handle complex organizational workflows. Traditional systems have those capabilities but can't match AI's speed. Drupal is finding the middle ground: fast enough to compete with AI tools, robust enough to actually run a business on.

These sessions are now live on the Drupal Association YouTube channel. Watch them because they show solutions to problems you're probably dealing with right now. Whether you're losing deals to trendier-sounding competitors, trying to get your team on board with AI, building systems that handle sensitive data, or just trying to automate the boring parts of your job, someone at DrupalCon Nara showed how they solved it.

And that's what makes these sessions valuable.