I wrote last year about the open source contribution that anyone can make. I want to expand on that a little bit and talk about recent contributions I’ve been making to the BLT community.
I’ve talked a bit recently about some of the updates made to BLT for Drupal 9. Anytime there is a significant re-architecting of a project there’s a chance that something may be a little funky. That’s ok! That’s to be expected. And I am so thankful to Dane Powell and others in the BLT community (both in and outside of Acquia) who continue to keep the project running smoothly. But as a consumer of BLT, I feel I have a personal obligation to both report issues that I’m experiencing AND test (or contribute) solutions to those problems.
Let’s dig into a recent issue and how I found the solution for it.
The Problem
Not everyone who uses BLT uses Behat. So, as of BLT 12 the Behat functionality for BLT was split out into a separate plugin. Now, theoretically, this was a lift and shift of the Behat capabilities of BLT and everything should have worked exactly the same way in the new paradigm as it did in the old. HOWEVER that didn’t end up being the case.
The continuous integration process on the GovCon project started failing after upgrading to BLT Behat 1.1 and BLT 12.6.x with the following error:
[error] Alias (Acquia\BltBehat\Blt\Wizards\TestsWizard) is not being managed by the container Now, as someone who has a bit more experience with BLT than your average bear, I can tell you I’ve never seen ANYTHING in BLT that looked like this error (and that’s rare). So at this point, all I knew was that:
things had been working
i only updated my plugins (no tests or underlying logic changed)
things aren’t working now
^^^ this is highly suspicious and exactly why continuous integration and automated testing are so important. Something broke! We caught it! High five everyone. Let’s figure out what happened.
Chasing Down the Problem
The issue here was actually pretty easy to find thanks to the meticulous practices in place for the BLT repositories. There are two pull requests made recently related to Behat:
To save you a little bit of reading, the thing that I eventually found in the BLT PR was this change:
I still don’t really know what the container logic is at this point… but hey what do you know that is pretty related to the error I got. TestsWizard was in the container but as of the BLT PR it isn’t anymore. After carefully reviewing the PR on the blt-behat side I was able to determine that there wasn’t anything to re-add TestsWizard into the container on that side.
So! At this point, I’ve identified a problem. I’ve figured out why it’s a problem. I still don’t know what to do about it. But I’m definitely far enough to start laying down breadcrumbs so I opened an issue on the blt-behat issue queue to report it. This is a big enough deal I wanted to get the alert out ASAP because updating to blt-behat 1.1 would essentially break behat on a blt project (that’s bad).
The Solution
Given that I do know a bit about Robo and more than a bit about BLT I spent a bit of time Googling the container issue. I found some stuff in the Robo issue queue that wasn’t super helpful, but was interesting reading (e.g. https://github.com/consolidation/Robo/issues/670).
The thing I was really focused on was the question of how do I tell a BLT plugin (Robo plugin) to add something to the container. Ultimately the thing that saved the day was my IDE! Thanks autocomplete.
I realized that the initialize function would rie on all commands (good) and that there was already a container object inside of the $this object. So I took the code out of the BLT PR (that added TestsWizard into the container) and put it here in the initialize function. This took about 5 seconds to copy and paste.
$this->container->add(TestsWizard::class)->withArgument('executor');And it worked! It fixed the problem. So I opened a PR and we got it merged and cut a 1.1.1 release that fixed the issue at hand.
Takeaways
At the end of the day, I would say there were three broad classes of contribution here.
I identified a problem (broadly).
I did enough research to figure out why the problem was happening.
I proposed a fix for the problem.
If you’re reading this post thinking… well I never could have found a solution to the problem I cannot stress enough that that’s ok! You don’t have to find a solution to every problem yourself. If you fall into the first scenario and go… you know what, I think this is a problem and you go no farther to scenarios 2 and 3 as long as you report scenario 1… you are awesome! You are helping. You are making your open source community better and stronger. Ideally you would at least go onto step 2 because:
it might help you understand the technology a little better
you might stumble across a solution to the problem
you might help whoever ultimately goes on to the 3rd scenario and “solves” the problem do so a little faster
In my case, most of what I did for scenario 2 was just skim through pull requests for certain key words like TestsWizard and container. Remember, my fatal error told me super explicitly that there was a problem involving these things:
[error] Alias (Acquia\BltBehat\Blt\Wizards\TestsWizard) is not being managed by the container This takes very little brain power to look for ^^^ when you know there’s a PR and a bunch of recent refactoring. Even if you have no clue what a TestWizard is or what a container is. They’re just words and you can search for words even if you don’t fully understand their impact. In my case I was able to look at the BLT PR and go “hey look!” there’s some code coming out on this side that didn’t get re-added on that side. That’s probably related.
And even now, even standing on this side of scenario 3 where I found, researched, and ultimately fixed the problem… I still have absolutely not idea how the container in BLT / Robo works. I understand what a container is and how it is likely relevant. But beyond that, I have no idea. And that’s ok! Because in this case, despite the fact that the container is part of the solution i didn’t actually need to know anything about it to fix the problem.
I remember in school when we first started balancing equations in math. I didn’t always understand what I was doing… but I do remember some comfort in the click that if you make a change on one side you have to make the same change on the other.
“An equation is analogous to a scale into which weights are placed. When equal weights of something (e.g., grain) are placed into the two pans, the two weights cause the scale to be in balance and are said to be equal. If a quantity of grain is removed from one pan of the balance, an equal amount of grain must be removed from the other pan to keep the scale in balance. More generally, an equation remains in balance if the same operation is performed on its both sides.”
And yeah, no, I’m not at all suggesting that every single time something breaks on an open source project you should pull math out of your back pocket and go THIS IS GOING TO BE EASY. What I’m saying is that if you don’t dig into it a bit farther you’ll never figure out what’s wrong, and if you want someone else to help solve the problem, the more information you can give, the better the chance it’s going to get resolved.
Photo by Liam McKay from StockSnap
Related Content
Open source contribution can be intimidating. This post is all about getting started and finding opportunities to share your experience(s).