Golems GABB: Drupal Automation with CI/CD Pipelines

Drupal Automation with CI/CD Pipelines Editor Mon, 09/23/2024 - 17:02

Welcome to the magical world of Drupal development! It can be not only innovative but also efficient by employing continuous integration and continuous delivery (CI/CD) pipelines.
CI/CD Pipelines are like magical tools for automating the integration, testing, and delivery of Drupal projects, thus making it easier for developers to concentrate on creating flawless digital experiences.
Let's take a look at how CI/CD Pipelines work with Drupal. Let’s learn how they maintain consistency in everything and reduce risks during development. This guide will give you everything you need to know about Drupal Automation with CI/CD Pipelines, whether you are a seasoned Drupal developer or a marketer who wishes to improve digital projects.

Oliver Davies' daily list: The two ways of writing PHP code

Something that came up in my discussion with Dave Liddament for the Beyond Blocks podcast was that there seem to be two ways of writing PHP code.

One is writing strict code by enabling strict typing, using parameter and return types, and leveraging tools like PHPStan at a high level to analyze code.

The other is no not use types and to use a more "duck typing" approach.

The term "visual debt" came from a video discussing the pros and cons of these approaches.

The same can be said for JavaScript and TypeScript, but PHP can do both and gives the Developer the choice of how they write their code.

I prefer writing strict code and for my code to be as explicit as possible, but I appreciate not everyone does and I like that PHP caters for both.

How do you write your PHP code?

Oliver Davies' daily list: De-jargoning Drupal

This week, I learned there is a Drupalisms Working Group - a group focused on de-jargoning Drupal and making it easier for newcomers to Drupal by removing some of the Drupal-specific language.

From the introductory blog post:

If you’re familiar with Drupal, you will have learned its language. You will be familiar with words like Views, Blocks and Paragraphs, and you will appreciate their respective features and functions. But for those new to Drupal, getting to grips with what words mean can mean a steep learning curve.

Drupalisms is something I've discussed on a few episodes of Beyond Blocks, including the most recent episode and the seonc with Eirik Morland.

I didn't realise there were BoF sessions about this at DrupalCon Lille last year, so I'm hoping there will be more next week in Barcelona.

Anything that helps Drupal easier to use and adopt is a good thing.

Wim Leers: XB week 18: DriesNote deadline

With DrupalCon Barcelona 2024 only two weeks later, the focus this week is on tying up loose ends. That already started last week, but of the milestone 0.1.0 priorities that product lead Lauri identified, 15 are still left after last week: we need to fix 1.5/day to get to zero.

Major loose ends

I titled last week’s update drag and drop party because there were so many improvements on that front. But one critical piece was still missing: it was painful to drag components into locations that are difficult to visualize: top and bottom of slots, even more so for adjacent slots. Bálint “balintbrews” Kléri brought one additional improvement:

Your browser does not support playing videos. You can download it instead.

Drag a component and drop it into truly any location.
Issue #3471169, video by Bálint.

Beautiful isn’t it?! I couldn’t say it better than Jesse “jessebaker” Baker in his review: This is such a marked improvement and honestly it’s already better than I dared hope it would be, especially this early. Excellent work.

Ben “bnjmnm” Mullins finished the highest-impact loose end: he ensured all single-value field types work correctly.

Quick recap: the back end and front end were developed independently, with the back end focusing on reusing Drupal concepts (i.e. field types + field widgets), the front end on the ideal UX, and then Ben having bridged the gap between the two by lifting a subset of the JSX Theme Engine. Ben had gotten the foundations in place in week 10 and then brought basic Redux integration for live updates of the preview in week 11. We knew there were lots of loose ends, but we had no choice but to move on to higher priorities.

This week, Ben finally had the chance to introduce sorely needed end-to-end (E2E) test coverage, which ensures that a whole range of field widgets work as expected not only in the original field widget sense (focus on server side), but also the live update sense (focus on client side): the Redux integration must be aware of when the values the user is typing is valid. More work remains to be done there, but the introduction of the prop-types.cy.js E2E Cypress test marks a significant milestone! 1 Next steps will be tracked in the corresponding meta/plan issue.

Lots of usability bugs squashed

Jesse coordinated the squashing of many usability bugs — not really broken things, but things that should happen to not have a clunky UX:

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Back-end improvements

Image removed. Initial UI that shows the reason why an SDC is not available in XB.”
Issue #3469684, image by me.

Unfortunately, during the week, Lauri prioritized several more issues, so we ended this week with … 12 — only 3 fewer than we started with :/ That means we’ll need to land >2/day in the next week to get to zero. Fortunately, most of those twelve are already pretty far along.

Who of you have ever been able to chill towards a deadline, and how did you do that? :D

Week 18 was September 9–15, 2024.

  1. It is not comprehensive yet, but then again, nor does Drupal core have field types that can populate all of the possible prop shapes that Single Directory Components’ JSON schema are able to express. Next steps here are growing the test coverage to reach full confidence for the prop shapes that we do have field types + widgets for. ↩︎

  2. And as Ben pointed out: this is very cacheable by design, so it’s not a case of premature optimization. ↩︎

  3. I think it’d be good to have each area in the CODEOWNERS file correspond to an issue queue component. Thoughts? Let me know! ↩︎

The Drop Times: 'Local Association Stand' at DrupalCon Barcelona 2024

For the first time, fifteen European local Drupal associations are joining forces to create the 'Local Association Stand' at DrupalCon Barcelona 2024. This collaborative space will serve as a hub for discussion, networking, and support for event organizers and community members. With a cosy seating area, the stand aims to connect visitors with local initiators and strengthen the bonds within the Drupal community. Key sessions include insights into setting up local association sites, organizing Drupal events, and the future of in-person DrupalCamps in the post-COVID era.

eiriksm.dev: - I think I said “wait that’s all?” out loud!

From time to time I get some really good and motivating feedback on the product I have built, violinist.io. And I want to start this post, which will also have a huge feature announcement, by mentioning a couple of them:

It was wonderfully painless (...) I don’t think I’ve ever experienced a faster setup of a CI tool — I think I said “wait that’s all?” out loud!

overall did the trick of what I was looking for and was very very fast

In other words, easy to set up, and fast results.

Well, today I want to share another product update that will make it theoretically even faster to set up and get results. But first allow me to provide a bit of background on why this new feature came to be.

One recurring question we get is regarding two avenues of a similar aspect:

  • Does our code have to make its way to violinist.io infrastructure for us to be able to use the service?
  • Can violinist.io access our Self Hosted GitLab which is locked down with a required VPN connection

They might differ a bit in wording or actual focus, but they usually boil down to one of these. And from time to time we find a compromise to both of these questions together, and the person contacting us turn into happy customers. But from time to time these questions also become the actual blocker for them to start using violinist.io. But now, at least, we have an alternative that covers both of these use cases: Self hosting violinist.io runners!

And here is why I am mentioning the feedback regarding quick onboarding in the context of this product announcement. You can literally start an update check with one docker command:

docker run \   --pull=always \   -e "LICENCE_KEY=my_key" \   -e "PROJECT_URL=https://github.com/user/repo" \   -e "USER_TOKEN=ghp_jYgGb_1npvkiHTdnM" \   ghcr.io/violinist-dev/update-check-runner:8.3-multi-composer-2

This will run the same update job as if it were running on violinist.io, only using your own computer!

Of course, this in itself is not super useful. Avoiding running commands on your computer is the whole point of using an automatic update service like violinist.io, but now you can do cool stuff like:

  • Run the same update jobs as violinist.io without any code entering any third party infrastructure
  • Run jobs your CI infrastructure of choice. GitHub Actions, CircleCI, Bitbucket pipelines, Self Hosted GitLab, your totally locked down VPN protected GitLab instance that has a totally locked down Jenkins server. And so on
  • Decide your own intervals for running them, probably inside said CI infrastructure. Daily jobs? Weekly jobs? Hourly jobs? Not a problem.
  • Compose CI workflows that can do all your repositories in a matrix, all on the same schedule, if useful?
  • Expose a webhook to trigger jobs, and run them when new items appear in the Drupal Security Announcements  RSS feed
  • And a million other things probably? You decide!

If this sounds useful to you, or your organization, please don’t hesitate to reach out for a free trial. In fact, in the name of smooth onboarding, here is an absolutely free trial for you already without reaching out (as long as you are reading and using this within 2 months of this blog post): A totally free license key, valid for all repositories for 2 months from today (valid until 2024-11-19T19:20:19+01:00):

hc1NTsMwFATgHqXyCZ6f_-2V_RyvkLgAmzRYYLVqqiaqQKhSz9CrIA6T2xAWbGE50nwz9-Vr-Xz0Ajy7tPHQjm2anx7aUI9Dpdc67H8D8-g_Ji-sZ5u_m5v6dmrndxaa50YgSJDchZXq_-lzP_cs9J7_fPEV1HZu-2m7O4wv29M4zSzsPA_X63LLWKJb1w1SykKlRJgFoXRFR25AaZ6M48KgJKFJAdlM0kEU2bpkEYwCRBdBpqisQuIl6yyh01QKqNIZqUvXRcgchS0KxWohko3JKecgfQM

Now all you need is a repository and a PAT (Personal Access Token), and you are off on your new automatic update adventure. For a bit more documentation than this sparse promotional blog post, please visit the container repository.

Lastly, there are so much more I want to share and address about this. For example the aspect of open source in all of this, the differences between this and violinist.io (the SaaS), the licencing and pricing aspect. But those are all blog posts on their own. For now, I hope you will try it out if it’s useful, and that you want to connect should you have any questions or concerns. Here in the comments, or by reaching out.

Let’s close up this blog post with an animated gif of "runners".
 

Oliver Davies' daily list: Experimenting with the Default Content module

I recently sent a database to a client whose new Drupal website I'm building.

I'd populated it with some default users, nodes and menu links that they'd be able to review after they import the database into their hosting.

That worked well, but I've also recently been using the Default Content module which exports entities into YAML and saves them as code alongside the configuration.

Now I can install the website from scratch using the exported configuration to re-add the content types, block types, etc, and by enabling a custom module, all the default content will also be recreated.

I can tear the site down now and rebuild it as often as I like and avoid contaminating my environment with any rogue configuration or content changes.

Everything is reproducible.

I also wouldn't have needed to send the database to the client. They could have installed Drupal and followed the same steps I would do locally and got exactly the same result.

I like this approach and can see me using it more on future projects.

Subscribe to