 So how many of you know what Simply Test Me is? How many of you use it? Okay, cool, cool. So we're going to talk today about Simply Test Me and, you know, all of you are our target audience because the whole goal is to lower the barrier to Drupal, contributions and the learning curve and that kind of thing. We did recently change the way our website works. So we're going to talk a little bit about the future of the project, what we're currently doing, and then a road map moving forward. There's three of us. There's Matt, there's Adam, there's me, Amy June, title, camel case, always one word. Amy June, please. No, not my first time. So I am a community person. I work on Drupal contributions, but I am not to be reductive. I am not a coder and I'm not a programmer. So when I got into Drupal in 2016, I worked for an agency where I audited modules and I did simple tests on the code and stuff like that, but I could never figure out how to get a local environment going and I discovered the Simply Test Me project. So I am passionate about the Simply Test Me project from a non-code or non-programmer point of view. Not only because, oh, well this is what we're going to talk about today. I'm going forward. You can see where new mission, the history, Drupal 9, our new framework tugboat, future directions, and then plenty of questions at the end. But going on about the vision and the mission is because I'm really excited about Simply Test Me because Drupal is hard and creating a local environment six years ago was even harder than it is today. So having this framework built where I didn't have to have an environment on my machine, I could have a browser-based URL that I could spin up in five minutes, test, make some configuration changes, share it with the team, it really helped me get into Drupal development. So the idea behind Simply Test Me is to create this browser-based environment not only to evaluate and install and test out these Drupal instances and modules and installations, but also it works in the issue queue. So you could spin up an issue or spin up a site, paste a patch, and be able to test a patch and know whether or not it worked within five minutes. And that's spectacular for someone who doesn't spin up local environments, you know? So the last thing I want to comment, and this isn't something that's maintained, there's a project called Dreadator, and you can use it sometimes in Firefox and sometimes in Chrome depending on the day of the week and how the internet is feeling, but you can download this extension and it injects some buttons into the issue queue. So if you don't have Simply Test Me or Dreadator installed, it looks a little bit different, but you can see that now we have the Simply Test Me button in our issue queue thanks to Dreadator. And this is a really nice thing because, you know, I mentor and I help people get involved in Drupal contributions, and they don't have a lot of time, you know, they have five minutes, they have a couple hours a month, that kind of thing. They go into the issue queue, they find something with a patch, they can hit this button and would five minutes be able to test it. It's like a really spectacular thing. The review button and the embed button are Dreadator-related things that don't have to do with Simply Test Me, but that button makes wonders. So, you know, Adam took over the project and he's going to talk a little bit about when you took over the project and how some of the values changed, but really it comes down to, and I say this a lot, lowering the barriers to entry. Drupal is hard. So, not only for contributions, but the learning curve, you know, to be able to spin up and understand how to use a contributed module, figure out some of the configuration in the admin UI on a throwaway site. So, it definitely, you know, the learning curve goes up and then the barrier, because some people don't have a machine that is capable of having a local Docker environment, you know, so there's all kinds of reasons why people can't have these local environments. So, it actually increases the inclusivity of people who can write code for Drupal, who can contribute code for Drupal. And then it's a community project, you know. So, we have this project that all of us in the community can use. We use it at Drupal cons. We use it at Contribution days. We have teams of marketers that can put together landing pages and show a URL across the world. And then, most importantly, you know, it's that tenet of being free, you know. It's open source. You can see the code. You can look at it. You can look at the framework if you want. You can do something new with it, you know. And I'm the contribution community person, so I want to talk a little bit about how we all can contribute, because it's very exciting, because you don't have to be a coder to contribute to SimplyTestMe. Anyone can contribute to SimplyTestMe. We have a community project on Drupal.org, where we give people community credits and incentivize the contribution process. We have a dedicated Slack channel in Drupal Slack, SimplyTest. We are in there every day. People report issues. People are, you know, we have an issue queue for issues, but sometimes they're just like, hey, is this really happening right now? So, there's a lot of conversations in there. We talk about what we're doing moving forward. In Contrib workshops, you know, we are promoting the get pod and the merge request stuff, but there's a lot of patching still going on. So, it's a tool we utilize when we mentor people, because again, first time contributor workshops, do we want to spend three hours setting people up with a local environment, or do we want to set them up for success and have a five minute spin up and test a patch? And then Google Summer of Code is something we've done in the past. Not sure if that's going to be something we work on in the future, but that was something that, you know, we helped elevate and we reached out and made sure that we had different sorts of people contributing to the project. And that's another really important lesson in our community is when we did this new framework, you know, we utilized the skills of marketers, designers, programmers, and people who use the product. And it's really that case use of everything in open source and Drupal that everyone has something to contribute and everyone has something to learn. So, we can talk more about that at the end, or you can like ping me and figure out how you can contribute more. But Adam and Matt are going to talk about the future and where we are and what's going to be next. Okay, so we're going to talk a little bit of a history lesson here. And it has been a long road for this project and we'll get into it, but I think we are in a really good place now. So, for some of you history buffs, at least some of you have been around in the community for a long time. This project really came to be very shortly after Drush was launched. Just to give you a kind of a, you know, a benchmark. And it dates back to 2012. I had to go to the Wayback machine to find the dates. You know, always love doing that. And we found some good gems like you could see a screenshot from you know, I think it was like late in 2012 when SimplyTest was launching. You could see it had a very minimal set of features. There was no patching. There was no anything like that. But it had its basic search capability and the ability to launch a sandbox. It was created by Patrick D, Patrick Drautloff. And to give you a kind of a benchmark also, it was released kind of between like the Drupal 6 and Drupal 7 days. So roughly in that space and time frame. And it was really kind of before a lot of like the DevOps movement started and automation and things like that. So in my opinion it was actually way ahead of its time when it was launched. It was a really valuable resource I think to help community members really hit some of the goals that Amy June was covering. So, this is a pretty technical slide but the flow kind of makes sense and when we look at the early architecture, again, there wasn't a lot of infrastructure as code. There wasn't any DevOps. There wasn't virtualization. There wasn't cloud computing. These were kind of really, really, really early days of when those things were kind of coming about, right? So, SimplyTest.me basically was a fully custom built system. And it had multiple servers. They were bare metal servers. One was for the web server and then we had what we called back end servers. We pulled information from Drupal.org from some of their APIs back when some of the XML feeds were created on Drupal.org as an example. Again, we're really dating ourselves here. But we had this web server front end that ran at Drupal's site. We had these worker servers that were on the back end. They were load balanced with this custom logic and this Nginx routing and all kinds of fun stuff. And we made use of it in the really early days before containers were really kind of taking off. SimplyTest.me actually used LXC, which was a precursor of Docker, and was routed with HA proxy. So again, when this was created this was very much ahead of its curve, okay? An extremely modern and extremely innovative. And it worked out really, I think it was great for the time. But times change. As the system went on, the technology and the community, cloud computing, virtualization, containers, Docker even came about, Docker Hub came about, all kinds of things changed and it evolved. The whole technology space that this played in evolved, including DevOps, right? So SimplyTest.me became very fragile and very dated by the time I took it over, basically. And when I took over the project Patrick was ready to move on. Systems hadn't been updated. New versions of Drupal hadn't been installed on SimplyTest.me. Lots of bugs, lots of problems going on with it. But it had an extremely heavy maintenance burden. When you're having bare metal servers that haven't been updated in several years, those systems were going down all the time. Logs were filling up. It was really crazy. And SimplyTest.me is not just an open source project. It's a service. So we had a very heavy footprint of actually running and maintaining that for the customer service, believe it or not, right? People would ping us and say like, hey, this is down or hey, this isn't working and this thing isn't going. And it was pretty chaotic. And there was lots of system administration and lots of updates. It wasn't keeping up with some of the newer Drupal versions and some of the newer tooling. So it was a little bit crazy. I love the image in this, by the way, because it was perfectly summarizing kind of like the state of my mental world at that point when I took over the project. It's like, hey, keep this system running but it needs to be fixed. And I'm like, no, I'll just keep fixing it. But I knew deep down that we needed to do something much more drastic and modernize it far more than it was. Another major limitation back then was we actually had no development servers. So anytime that we were changing stuff or building stuff, there was a very high likelihood we were taking down the systems as we were doing it, which is really wild. We also had no contributors in the whole ecosystem of SimplyTest.me except for me. And we had no money. So it was about the worst kind of circumstances that you can kind of take over. But we tried to make the most of it, right? So then a new maintainer came and that's me. And Patrick D decided, hey, it's my time to move on. I'm ready to do other things. But for me I talked to Patrick and I said, hey, I really want to preserve the community aspect of this. I want to make sure that it continues to be open source driven that it's maintained. I have a vision for where I want to go in the future with this. And in 2018 I took it over and my goal was to continue to honor what he set up at the beginning of the project and try to make it better and improve upon it. So I set on this course for, I call it revitalization, right? Like we will build a new, you know, chart a new course. And so I had a lot of goals. Like I wanted to make sure that it was easier to maintain, more actively maintained. Amy June came in and really started helping with marketing. I set up an open collective so that we could actually raise funds from the community and pay people to do work, which I believe in. Centaro actually paid for a whole new feature called OneClickDemos where you could click on a button right on the UI and it would automatically spin up a site right away. And the folks from Tugboat, which we'll talk a lot more about later, we set up our ability to completely remove all of our worker servers behind the scenes that were extremely fragile and replace it with an ephemeral container driven infrastructure, which was awesome. So that was the kind of initial scoping of this revitalization and even since then we've done significantly more. So this section I call our new Simply Test. I'll start with a few and then I'll pass it over to Matt who is going to get into all of the technical weeds. The great news here is I want to start by leading with this is about six to eight months ago I think. How long has it been now? Someone help me out. Last one. Okay, so I was wrong. All right. So it's been over a year we launched an entirely rebuilt Simply Test me from the ground up completely. And this was I remember the day that we felt it was ready enough to launch, right? And I like pushed the button to switch over the DNS from, you know, the old servers to the new one and it was like this huge sigh of relief. It was like, yes we did it. And so this image of like the ship it, I'm like, yes we shipped it. It was so cool. So some of the tenants though that we were looking at with where we went is we really wanted to kind of get more into the agile space and leverage a lot of the new and modern DevOps philosophies as part of this, right? So if you kind of look at what Simply Test is doing, it is kind of like a CI CD system, right? It's automating deployments. It's, you know, you define what you want it's using a lot of infrastructure as code. But it's very similar in practice and in principle to what a DevOps system is doing and it's using now a lot of ephemeral infrastructure with a tugboat and everything like that. And Matt really came in to help establish this like really good microservices architecture that helped kind of build a lot of interoperability between our front end and our back end systems. And so it was a really, really good fit as we were going forward. But the main goal that we set out to do whenever we built the new version was we wanted to completely eliminate all of the nonsense maintenance that we were doing because we believe we can add more value for the community if we only focus on the application, right? If we hit that and everything else is automated under the hood, all the maintenance all the, you know, systems, all the servers, etc. This would actually position us to focus only on adding value for the community through the Simply Test Me application, right? So this was our like mantle as we were going through this exercise. We had a lot of, and I know Anna Laura is here. I don't think she's in the room, but she's at Drupalcon. If you see her, give her a big thumbs up. She did a whole new design for us and specked out a whole refresh visually from where we were. And if you remember the screenshots early on, when you saw on the slide, this looks a lot different, right? And she really cleaned it up. She did an excellent job. She did like mobile mocks and everything like that. And kind of cleaned everything up in this. And we have a whole new design. An entirely new theme. Fresh look and feel. We actually added features even with the new theme. We did a usability test at mid-camp like years ago on this design. We added a couple things that we thought people wanted. And so major props go to Iris of Beckway. She works at Civic Actions. And Anna Laura, who is definitely you'll see her around the conference. And then what we did, so we do honor our open source roots. And we're doing that a lot through the application. All the code is open source and everything like that. But I think one thing that we always kind of juggle in our minds is like, well, we know that vendors and they're kind of offering things that we could benefit from as a service. And so we opened up an RFP to basically allow any community partner to bid on our pass web server. Because we didn't want to maintain the underlying servers, right? So we opened that up. We expected it to be a sponsored thing. We had a committee. We reviewed all the submissions from the people, the companies that submitted for that, right? And we chose AMAZEE, Lagoon. It hit all of our needs with CICD and a lot of the maintenance things. They also have a really cool edge layer and a good logging feature that we just are kind of gradually turning things on. So it's been a really nice thing for us to do because it allowed us to completely replace a legacy server that we were maintaining by hand. It offered some really good features for our own development to be able to spin things up in more of a rapid development approach. And then it also helps too because it's a standard, right? Like many people have used the system before. So it actually helps to kind of lower the barrier for anybody that might want to help us or configure us that part of the system. So it worked out really well. And we got things like SSL certificates and edge balancing and logging, which were major gaps of what we had to do manually before. And we kind of get it a little bit more for free with this type of an offering. So it was a good win for us. Even though, you know, again, we do try to focus a lot on open source, but this is an example where we felt pretty strongly, we didn't want to reinvent the wheel. Alright, I'm going to be turning things over to Matt. When we did a lot of this, we set up a Drupal 9 system. So I'm going to give it to Matt to take over here. And he's going to talk a lot more about the technical bit. Hey everybody, I also wanted to mention about Lagoon. What's cool is they are now, I believe, Amazes Lagoon is part of the CNCF, the cloud network, whatever, whatever that is. It's like the cloud foundation, which is really cool. So it's like about Drupal 9 in the new front end. It drastically reduced the architecture because we could use OOP in Drupal 9. And we also decoupled the logic for the form into React. I don't know if anybody has ever gone down the rabbit hole of nested forms. My work with Drupal Commerce and Checkout, I have been to the seventh layer of Form API. And being able to move that logic out of Drupal's Form API into a JavaScript framework, which is reactive, it helps improve that. We could write just a back end code there. And also leveraging tugboat. So one thing I want to mention, like with tugboat, honestly, simply test at its core isn't that hard of a piece of software on paper. Take inputs, build, run file, push it to service that runs it. And if anybody here has used Kubernetes or cloud run with like modern DevOps, right, Docker file, boom, runs it. But as you start going down and down and down, running that is quite hard. Okay, so the Drupal 9. So let's go into the more technical bits and I'll expand on some of that. So I said Form API is very verbose. It has limits. I said with like the address module. I don't know if many, most people have experienced working with the address module. But right, you pick a country and then you get the address format and all that. Now imagine that form three layers deep and Drupal Ajax has certain limitations that you just cannot bypass. For instance a select list in Ajax can refresh your form but does not update form state it must be triggered by a button otherwise Drupal forgets itself it has a little bit of amnesia and your form breaks. So to be able to build a form that lets you pick your main project additional projects apply patches what version of Drupal core is the umami demo supported because before it wasn't an 8.5. And what if you want to patch your additional projects and then we need to add merge requests. That's a lot that we have to manage. So being an abstract that into a JavaScript application just made it more well it's still hard to manage but it's separated from Drupal's form API which has its own complexities. So it allows it to have that robust form with all the nested options and just the business logic. So if somebody is a JavaScript like expert well they're just managing state right this form needs to build this object and send it to an API request. That's the contract. And then the PHP site says I receive this and I transform that into a run file in this case it's a tugboat QA build form and I mean it could be like a Docker file it could be anything but the front end doesn't care it just knows it needs to build this payload. So that has made it more maintainable. Having a reactive front end was critical for this project because of the experience it offers you know all of our customers right. So if you pick Drupal 10 you don't want to see things that are not related to Drupal 10. You don't want to be able to select options that aren't there. You don't want to be able to pick projects that aren't supported. That's one thing we reinvented Composer. Well we didn't reinvent Composer but the front end if you pick a module that doesn't have support for Drupal 10 you can't pick Drupal 10 as a version. If there's a module like let's go back a year that didn't support Drupal 9 this let us have an endpoint that said given project in this branch what compatible versions of Drupal core can I run with. So we have that additional projects too there might be a bug but technically you shouldn't be able to add an additional project if it does not have a compatible version with the version of Drupal core you've picked. So we have all that kind of semantic versioning resolving in our APIs as well which the JavaScript made a lot easier to handle. Benefits of the company. So this is the cool part too. So launching the sandbox is now just a data definition contract so I don't know who here knows about the type data API in Drupal core. Who likes to play with it and has gone down deep and used it beyond the entity API. Alright I know you have. So I'm a big nerd about the low level APIs in Drupal it's pretty amazing and essentially just the type data API if you use the REST module you might have seen it. So this lets you say this is the schema of an object or of an item. Think of it how like we have primitive types of string. You can have a string data definition and that allows you to attach constraints to it such as the symphony validation or symphony validator package that says hey this string is actually a URL and it must come from HTTPS Drupal.org or Drupal code.org so we can have a validation on patch URLs to make sure they come from a trusted source. And that we don't have to write custom code well it's custom code but we don't have giant if statements that say if this payload is here we build it in the data definition and we let Drupal just roll with it. So that has streamlined the validation. The original code before I jumped in so I was wrong about a year and four months ago is when I jumped in and we launched it about six months ago it was in the fall I think. So when I jumped in like there was some port for the D8 code but it was a lot of if this I'll stat. So moving it to a data definition reduced the whole incoming payload to just take the JSON request decoded to JSON pass it to the type data manager validate it if there's an error tell the front end hey 400 bad request if not send it to tugboat and complete the request. So type data is pretty cool if you're ever interested in it talk to me I'm a type data nut. It's a very low level API that does power everything in Drupal and it's one of the unique parts of it. Here's an example of that so hopefully simply test me as an open project can help show you use cases of these more obscure parts of Drupal core. So here this creates a property definition for the payload. So we have the project which is actually a project info definition the Drupal version which is a string the install profile manual install and additional projects which is actually a list of project value so you can get really nitty gritty in here like I have issues that say Drupal version should also check our database of Drupal versions to make sure that you didn't pass in like fake values same with like the install profile is your Drupal core version one that supports umami those are still some hard coded pieces of logic that we have in JavaScript in the back end because it was just printed but eventually I'd like to consolidate or you can help contribute to consolidate I should say and then this is the response so we get to decode we pass it to the type data manager we validate it and if there's issues we kick it back so it's if you are writing APIs in Drupal please use this as an example like let's say JSON API is not working need something custom use this as a reference like that's one reason I was really excited to write this as there isn't much of this in the wild so optimizing and refactoring so tugboat had some really great when Adam took it over and set up tugboat tugboat reads from a repo and that repo has to have a commit that pushes so in the back end there's a github repo that had 450,000 branches that I've finally proven down to 79,000 so it would make a branch it had the github SDK and it would go call the github API to make it a branch the commit of the file that would trigger tugboat and like all these extra steps but tugboat had API improvements that we're able to leverage we don't need to do that anymore we can say here's our base ref here's our config in the API request send it we don't have to make a commit on github anymore that was like thousand lines of code removed it was like one of those happy pull requests like we deleted a lot of stuff and there's even more that we haven't taken advantage of we use base previews think of it if you're used to docker how there's like a base image that has the cache of all the things those still needed a branch to exist that would be based off of in github now we can actually make a request for that so this hidden repo that you all don't have access to to contribute these base can now live in simply test so like hey the base images need to have zip this is actually an issue right now we don't have the zip extension so we can merge request that says all base previews should have the zip extension and on the next cron run once it's deployed we'll update our base images and it'll be all good to go so what the heck is tugboat so tugboat is a pre-production infrastructures code IAC it's a CI CD tool so you make a commit it builds it and then you have you have an ephemeral environment develops for all sorts of projects as a personal plug for I did a year on my own and every client I included this with their project because I don't believe in merging code until it's been signed off like you should have feature branches and this way I can send it to the customer and be like hey how does this look they give thumbs up QA boom production on Friday and have a have a mind time so to learn more you could say you could email them at hello at tugboat.qa or Jeremy's at James at the Lullabot booth right so Lullabot booth you can talk to him about tugboat tugboat was created at Lullabot and then is his own MST the tugboat preview configuration so I mentioned like docker files it's not like writing docker files it's more like writing like your github actions workflow yet manifest or circle CI, Travis CI it's like writing that you have steps to install things so we are working to standardize the generation into like a config generator right now to make it easier to maintain it's a giant array of random commands that get kind of squashed together I want to find ways to make that experience easier so that way it's easier to contribute to that build step as well so little little hairy but it's slowly getting there and one of the good things is it helps unifies custom builds and the one click demos because they were very separated before so now the one click demos are actually plugins in the back end and I want all builds to be based on plugins that just override the setup commands or the install commands so we are able to just use the same infrastructure the same build steps for those so the new tugboat API capabilities I did go ahead of the sense so we can create the API we can create previews over the API without making commits remove the whole bunch of code like I said now our base previews can be generated that way and one thing that is neat and something that Amy June brought up is technically tugbo it's not open source so the project is open source but integrates with the closed source project with how this is being built let's say a company wanted to run it internally you could write it's not there yet but it could be made to swap the back end that runs the preview environments that says hey launch manager or we created our preview or rather like hey launch manager I invoke this submission you could write your own code that says oh hey here's to build the docker file and launch it in my kubernetes cluster so the work with tugboat helped decouple a lot of that from the legacy application so that way you could write your own back end host if you wanted to improve build process tracking oh who hit this 113% weird error whenever something failed because it went on for a while so what happened is the old system would actually ping back to simply test me and create like an entry in a log table of the status of what was going on and in tugboat that was happening but when something went really weird it would like spam pings and end up at 113% because there's more records in the database so now what we've changed is we only have it at four steps so it's less granular but we actually just output data to the log and then read the log as it comes in so as it's building we try to give you a live preview of what's being returned from tugboat it doesn't track yet it's got improvements to go but it reads for our markers and then updates the status bar like oh are we at the installing step are we at the downloading or patching all that so the logs are streamed from tugboat and again if you're interested in this your that our api keys actually aren't exposed over that because we proxy it through Drupal and combine two api requests and like the responses into one so it's kind of like acts as an api gateway to tugboat in that regard um little relatable code base I said so work to be done it's working to become more relatable we have this weird dance where it's an install profile so it's on Drupal.org but we need a website composer template that's on github um so that's where it's still a little weird to contribute to but it's Drupal 9 it's oop it's javascript it should be somewhat familiar and we're working on improving that contributor experience and then the future with Adam again alright thanks Matt always good to dive into the technical bits he cleaned up a lot of the stuff that I was working on so I'm very grateful for him so one really cool thing is before DrupalCon we wanted to put on our best face for all of you we did a pretty big sprint in the last couple weeks right and we launched a whole bunch of new features and cleaned some things up so that it would be ready for all of your contribution here at DrupalCon we fixed a whole number of bugs that were open some project import things some UI things that weren't quite clicking we now offer Drupal 10 support which is awesome and that can be ready for you all to get Drupal 10 ready and core and everything like that we now have more projects so we can actually see a lot easier when things are not going well on SimplyTest so we can get some insights and start to prioritize things a little bit better based on what we're seeing in the logs and the error messages and we're pretty close to launching I think or getting close to it working towards it some better theming support where you can more readily install themes and have them kind of work more naturally on SimplyTest modules kind of work and themes have a lot more challenges behind it it's not quite as straightforward as a module but we're actually working to get better about that and I would expect that fairly soon and what do we want to do kind of looking for well Matt hit on a few with like the config generation stuff we want to work to get more like base preview support better cleanup better automation better abstractions to make the code a little easier to contribute to we also have a lot of cleanup we want to do I mean we really jammed on trying to get it kind of going but we want to refactor it to actually make it a little bit cleaner a little simpler better documentation in the code and that's stuff we're kind of doing very iteratively as we go but one thing that I also want to do is I want to start being able to report out analytics from SimplyTest me where anybody in the community could see how many projects are installed if it's you know if people are installing Drupal 7, Drupal 8, Drupal 9, Drupal 10 and also like be able to say okay these are the top projects these are the top patches in these projects etc and kind of report out like all of the information that is being used by SimplyTest which I think would be really cool for people to see like oh wow like this thing is this project is the number one project used on SimplyTest right it's good to submit things like hey you know in an idea queue you could say well maybe this module should be in court because it's like the number one module that's used in SimplyTest right so I want to expose that information same with patching because I think you know when you have a patch if it's not merged in yet it could give you some good insights of like what SimplyTest is seeing in terms of what people are trying to test and as I mentioned we do want to have some more automated management with base previews because we want to make everything more efficient we want to store as much as possible and then have that drive most of the logic of what happens behind the scenes with the infrastructure and a lot of that will be really helpful for ongoing automation things like you know new versions of Apache comes out a new version of PHP comes out we can run our tests we can do all of our automatic deployment you know break if things break we fix it we can clean it up so we have all of that in place basically and so it should be a much more streamlined and kind of automated system moving forward cool I want to thank all of you for coming that was basically what we prepared and if you have any questions I'd be happy to take them we all would yeah that's our yeah this business is being recorded I'll reiterate the question is about issue merge requests issue forks and merge requests so right now we don't have a native way to say oh given this issue select what merge requests are available but what you can do is go to the merge request in the URL type dot diff and that will create a generated patch for you that you can then copy paste into the simply test UI it is on the list there's just you know that's a decent work around it's not documented so take that knowledge with you and share until we get it documented but it's one of we need to decide like what is the interaction is it you paste an issue and then you select for the merge request or do we just let you copy a merge request URL and we'll slap a dot diff on it for you but for right now just go to the merge request type dot diff get the generated patch that comes in paste on the simply test and it'll should work so maybe that could be a good thing to test right now it does work when you do that I think one other thing that and props to the DA for you know adopting GitLab and things like that right we actually have a lot of APIs that we have metadata we can pull from which is great because like if we do want to make that experience a little bit better moving forward we have the ability to get the data that we might want right it's a little bit tricky as Matt said like there's kind of like nuance to it and so we're kind of trying to iron that out and it's very much in like an idea phase but we would love to talk to people to see if there's ways we can bring that home good question really good question I love that idea what other questions do you have yeah so it's extremely extensible right it's Matt kind of used the analogy of like a GitHub action right where you could basically run anything that you can on a standard terminal at certain events or certain times right and simply test me the whole system the Drupal application basically just writes out what it is intended to do like if a user selects a project or a version or a patch it writes the commands into that tugboat file that it produces its definition right and we have pretty much full control over it you know we have like base images kind of like the Docker construct right we pull from that and then we script those on an individual basis outside of that so in my opinion and I don't know if this directly answers your question but it's highly configurable we can basically write anything that we want into that okay yeah so we don't have this right now but let's say you're testing the Redis module we this would be hard coded I think we'd have to hard code this but say you picked Redis add a Redis service and install that extension for you say with memcached or solar so we by default only run in my SQL service but we could say hey have solar in it like I said my clients that I had before I had the tugboat run solar in my SQL and Redis so we could see production so we don't have that yet I don't even think there's an issue for it yet but technically we could even do that given these you know service integration modules Redis is the proper extension so that way when you install it you can verify that works I'm going to open that issue right now okay I think it would be a little hard to support everything you know and like from from me being the pragmatist and all of this I was like we could write any service we want yeah technically we can but it's one thing that to also support it and I'm a little bit leery of that but we can we can debate it I think some room to improve upon that and one very relatable you know thing that we struggle with perpetually is distributions okay that's why we created the one-click demo feature inside of simply test because it has its own definitions right and every distribution kind of has its own ways and means of doing things right like some use different parts of composers some don't like it's a little bit of the wild west honestly so it's there's no way for us to like universally support a feature like that in Drupal right so we made the one-click demos which actually can also imply to the core install profiles like umami and things like that so that's the construct that we use to implement that but there's many things that are kind of like you know more complexities inside of some of these things like the modules or the themes like we don't have to give an example right we don't have like native npm support to compile a theme right so we're actually like looking into some of that type of stuff to make the theming experience a little bit easier but it might only like if we launch it at first it might only support a few set of frameworks that are more predictable like hey we're gonna install npm and just look for certain heuristics like a package json file and run that right so like there's ways we're trying to ideate on making that a little bit smoother but no we're not like our goal is not to hit every edge case we want to make sure we're getting the big ones we want to make sure that we're hitting the most popular cases but it is extremely hard to get every single thing because Drupal is highly configurable the theming the modules you know the libraries etc and it can be a little bit of the Wild West but it's something that we're trying to just make sure we get a lot of the basics down right but this is we're defining this as a library so that I don't even know whether it's going to match up with a module but we're going to add some javascripts library and it's going to run up to the composer's kind of build the composer in the library that is that is native to some of Drupal's module like composer json type stuff as well right especially for Drupal 8, 9 and 10 so like we respect that like if you go and load the module right using composer like composer require Drupal slash whatever it can go and pull down all of its code libraries and dependencies and we're not doing anything that's off the reservation in that so if it's using those conventions it works fine now there are other things that I think are less common cases that no simply test me is not like looking for some more bespoke features in that regard that would make a make file that then simply test me can pick up on and pull everything into if you guys have a standard way that you're doing through the composer or something go to a module doing the module and say hey if you put this in your composer file then it will work and we do have that yeah so for 8, 9 and 10 yeah everything that's composer supported is usually fairly good and it can be not just Drupal dependencies it can be libraries or you know third party libraries Drupal make or drush make was also what we looked for foundation for Drupal 7 especially when we were trying to do distribution support in Drupal 7 a little bit easier in 7 than it was for 8, 9 and 10 but we did have some support for that as well if you go back and look at some of our old code from our old system you can see a lot of like these conditions looking for like the Drupal.org make and like the project.make file like there was all these like conventions that were wired in but we're really trying to move away from you know kind of supporting that in a legacy construct but you know I would say like the Composer Avenue covers many of those edge cases that drush make was intended to do before but is doing it really for you know more of the Drupal 8, 9 and 10 stuff hopefully that answers your question what other questions do y'all have? well thank you so much we will be here today, tomorrow so thank you for coming and have a great day