 Cloud development with Drupal Pod. Let's jump in. I'm Stuart Clark. I am from Reality Loop in Victoria. We are a small shop that specializes in decoupled Drupal development, decoupled specifically with DruxJS, which is a project that I've been working on for the last few years. I've been a Drupal developer for about 15 years now, a view developer for about four years. And apart from working on DruxJS, I'm also currently contracting with Vic Uni as a front-end developer, a view developer. And yeah, today I'm going to be talking about, whoops, came in a second, Git Pod and Drupal Pod. So Git Pod. Git Pod is a development environment in the cloud. So you can head over to gitpod.io, and there's a whole bunch of information there. But what Git Pod is, is basically visual studio code in a browser that allows for you to spin up everything you need there. Composer, your docker images, et cetera. It allows for collaborative development. And yeah, it's a pretty awesome project. I'm going to probably do most of my talk as a live-ish demo. But I'll just go through some basics for getting started with Git Pod. So all you have to do to use Git Pod is if you have a GitHub repository, or there's a GitHub repository of a project you like out there, is just to stick gitpod.io hash in front of the URL for that GitHub repository. And that's it. That will spin up the pod for you. And if it's your first time, it'll request you to log in with accounts using, say, GitHub or GitLab, whatever your flavor of choice is. And you will have to sign up for a plan, but free is one of the options. And the free plan, I believe, gives you something like 50 hours of usage per month on Git Pod. The paid accounts allow some additional things. They also have some professional open source accounts, which you can use or you can apply for if you're a contributor to any open source projects at a certain level. They'll review your application. It's totally worth paying for, but I'm not really here to endorse it rather than to demonstrate how cool it is. The additional things that you can do is you can add a Git Pod YAML file to the repository that you're working with to do some basic configuration. And that can be things like setting up the Dockerfile that's used inside of that pod, adding in some tasks to do some things before it spins up while it's initializing and once it runs. So for instance, before maybe make sure that it's got all the Git branches it needs before it starts initializing. The initialization steps are usually going to be your build steps. So things like composer install, NPM install, download Docker images, anything heavy. And your commands are things that will run once the Git Pod has initialized. Additionally, you can enable pre-built. And what pre-builds are is they will take your initialization step, your init step and they will run that on a server and then they will cache the results of that in an image and store that in the cloud somewhere. So the next time that you come and spin up a pod for this particular environment, it will download that image that's already been built for you. So if your composer install process takes 10 minutes, you don't want to have to wait for that every single time you run a Git Pod. So the purpose of pre-builds are to speed you up with that. So I'm going to jump into a demo and I do have some pods already running here but they're probably timed out. That's okay. So the first one is, so I'm just go Git Pod hash, github.com, whoops, it disappeared. So that's the repository github.com, drux.js. In this case, there is already a running workspace but I'm going to go ahead and create a new workspace so that we can go through the actual process of what would happen. So this will go ahead and pull down the container image for this, which hopefully won't take too long. This is where I need some background music in my presentation that's royalty free, but instead I will just continue to hope that it doesn't take too long. Meet myself maybe. I'll talk about the benefits I think while we do this. So one of the biggest benefits of doing this is the fact that you, oh, there we go, start talking and it works. So this is loaded the pre-build and that's it. So it's now running a instance of visual studio code inside of a browser. You can see this here spits out saying the task ran as a workspace pre-build and I've saved three minutes. I think it's a bit more than that because I've actually got multiple different tasks in this particular instance. So each task, and let's bring up my Git Pod YAML and bump up the font size a little bit. I've got three tasks in this particular instance. One is to set up DDEV with Drupal, which downloads the DDEV images in the pre-build and runs a setup script. And you can see that this is the output of some of that, including the steps after the pre-build, which is to go through and make sure that my Drupal environment is configured specifically for this instance of Git Pod, this randomly generated URL and needs to update some of the configurations for that. This second one here is to run a docs site. So it will await the build of this third task, which installs and builds the code base and then sends out a message saying that it has done the build. That will await that. And after that, it'll go into a docs directory and run yarn and get all the dependencies installed. And then once it's actually up and running and DDEV is running as well, it will run the dev command to spin that up. And this last one here will go through and install the main project, build the code base and build the docs site. So what that gives me as a developer for this project is an environment inside of the cloud where I can start working on things. I can run yarn build and it's got all my dependencies and I'll just go through and build my code base, which is already done. But if I want to start developing, I can run yarn build watch and go through my code base and start working on it. And as I make changes to any code such as this, I don't know if that sticker console.log. Hello there. I save that and you can see that that's built. So as far as a development environment, it's up and running. And Drupal as well is running. So if I go across to the side here, we can see that I have a tab here called remote explorer. And the remote explorer tells me all of the ports that are currently open. There's an excessive amount at the moment because of the specific setup I've got of Ddev. But I can see ports 8080 is open here. So I can open that up inside of here, inside of a simple browser. And we can see that I've got a running copy of Drupal inside of this pod that I can access. So if I need to log into it, I can run Ddev drush ULI. And that'll spit me out a one-time login link. And I can log in to my site here and I can start messing about with things. So that's the basics of Gitpod. So I will jump back into the slides and talk about Drupal pod now. So Drupal pod is a bit of the current hotness in the Drupal realm for contributing to Drupal core and contributed projects. It got huge amounts of well-deserved love at this recent Drupal con. And it's a really good project by Ofer Shal. And what it allows you to do is go into any issue within Drupal.org and spin up an environment from that issue so that you can get into contributing. And the whole idea behind Drupal pod is that contributing to Drupal is something that a lot of us want to do, but it can often be a little bit harder to get started than it should be. I've been involved as a mentor at many Drupal cons now. And one of the sessions that's usually done at Drupal con is like getting mentees up and running to contribute. And that involves a whole bunch of mentors in a room trying to help people with their environment, installing things that they can get into it. And then you have to wait for everything to download over the conference network and hope that it all works. So this project by Shal is to sort of improve with that experience. So Drupal pod.com will send you to here, to this repository. I mean, I'm already there and now it's being slow, but trust me, Drupal pod.com will send you to this repository. All you need to do to get started with Drupal pod is to install a browser extension for either Chrome or Firefox and then head over to Drupal and find an issue that you want to get involved with to contribute to. So in this case, exposing the layout builder data to rest and Jason API. And once you're there, you can click on the browser extension and that'll give you a few options. So you can choose a branch that you want to work off if the issue happens to have a branch set up for contributing. You can choose the version of Drupal that you want to install against and you can choose a specific patch that you want to apply if any. So in this case, I'll go with this one here. Oh, and you can choose the install profile that you want pre-installed. So demo U-Mami is usually a good one to go with. And then it's just a case of opening dev. So this one will take a little bit longer, but that's okay. So it's going to pull the container image, which will take a little bit of time. But in the grand scheme of things, it's usually no more than like a minute or so, which isn't much unless you're presenting to a crowd of people and they're intently staring at the screen waiting for something to happen. And you have to provide some sort of filler entertainment. I'll just, you know, talk innately. So I'll bring that across to here. Hey Stuart. Yeah. I have a question. It's Alexar speaking. I followed the same step on a core issue. It didn't pick up the Drupal version that's been kind of labor for that issue. Is that by design or something that can be improved on? So it will, it should provide you with a list of available Drupal versions. It's not going to, I don't believe it's got any specific intelligence to determine the version that it should be against. Ideally it would pick the version on the issue. Is that right? Ideally. But I mean, from what I can see here, it's not doing that. And that's definitely a case where I'd recommend going over to Drupalpod.com and opening an issue. I think that's a really good idea. And it shouldn't be all that difficult to do because it's already pulling information from the page to show you what patches and what branch. So yeah, absolutely. It should. All right. So it's up and running now. And in this case, it's doing a bunch of things because while it does have a bunch of pre-build in place, it doesn't necessarily know which environment you're going to choose and which patch you're going to choose. So it has to apply that stuff now, but it doesn't take all that long and compared to, you know, setting up an environment for the very first time, especially if you're a new contributor. This is a lot faster. And it also provides you with all this useful information here. So wait until the terminal completes its operations, which is what is going on right now. And once that's done, it'll open up a panel on the side. So we can see down here that it has started the Drupalpod. Which is run by Ddev. And now it's just downloading some additional modules. And the main module itself, the code base that I wanted to contribute to. Well, actually, no, it's patching. Sorry, I should say because this is a core issue. So it's simply applying the patch or has applied the patch. And now it's installing. I mean, that looks like it applied the patch before it installed the code base, but whatever. Nearly done. All right, so it's going to install Drupal now with the Mami install profile. Once again, we'll only take a short amount of time and then it'll get it spun up and ready to contribute to. So while this is going on, I'll just walk through some of the benefits of Gitpod. So I think one of the main benefits is for Gitpod, I should say, not specifically just Drupalpod, but one of the main benefits of Gitpod is the ability to have projects where you can onboard people with no installations required with, you know, no, it doesn't work for me because everyone is working in the same realm. You can also run a Gitpod environment locally. So it'll run the environment in the cloud. But then there's a browser extension or a VS code extension, I should say, which will actually connect your local Visual Studio code to the running pod and allow you to run it locally but not, which, again, it helps with, you know, making people feel comfortable. I think that may also alleviate some of the issues with connectivity. I know there's another similar project to Gitpod by GitHub, which is GitHub Workspaces. I don't believe it's yet open to everyone yet. Last time I checked it was just for enterprise users and only a select few of them. And one of the features of that is the ability to run your pod images within a local environment because obviously not everyone always has full access to the internet. And that's definitely a downside. But I know both are working towards making that work everywhere. But one of the biggest benefits is the ability to share access to a running workspace, which means that if I would click this button right here, that I could then, why not, let's do it, paste this link into the chat and then anyone could click on that link and be in this same environment with me, which means if you work in a team and you have a developer who runs into an issue and they can't figure out how to do something, this allows you to work in the same environment. Anyone who happens to be in here now would be able to type commands in the terminal, which I would then see in my terminal as well. They can edit files in here that would also, there you go. So that can be very useful. It can also be terrible when doing live demonstrations, but I'm sure no one will troll at this point or they will. So kit pod is set up with a whole bunch of things. I'm using DDEV as I said, one of those things is X debug, sorry, Drupal pod versus kit pod. So if I run DDEV X debug, it will enable X debug within this code base. So then I can hopefully let's open up the code base, which is in repos. If I go into index.php and put a break point here and go over to this one, click this button. Then in theory, if I reload this page. No, let's do it in another window. Do that here and turn on X debug helper, debug, reload that. And in theory, I don't think it worked though. It's not going to work for me. In theory, you can. It does work. I've tried it before, but I didn't test it prior to the demo. So either way, you've now got this environment with a version of Drupal installed with the patch for the module that I wanted to contribute to already applied and you can just jump in. There's a bunch of other things here as well for actually contributing. So if you want to start, you know, if you want to commit back to Drupal once you've written your code, especially if you're working on a contrary module that you have access to. There is this interactive SSH setup script that you need to run, which will take you through how to add your key into this pod and then commit back. But yeah, it's pretty cool. It's pretty amazing stuff. So I'll jump back now into the presentation. And I have a demo there, but that's fine. I just ran through it. So lastly, Drupal pod for you, because Drupal pod as a project is about contributing back to the Drupal projects, core and contrary projects. But if you want to get your own instance of Drupal, your own website running, it's really relatively simple. To make a repository from scratch, it's really a case of composer create projects to get your Drupal code base, from scratch. You don't have to do this all from scratch. If you want to adopt an existing project, you can likely have that code base or that composer file. But from scratch, composer create project, Drupal recommended project, et cetera. After that, this uses DDEV. And the reason it uses DDEV is because OFA and Randy Faye have put a lot of work into making that work. I have looked into using Lando as an alternative, and it doesn't work. I know there was at least a working version at one stage, and even that working version no longer seems to work. Hopefully there will be more support for more development environments in the future. But DDEV is really good, and I'm most likely going to use it as my primary Drupal development environment from this stage on, especially as it works so well in Gitpod. Installing DDEV is relatively simple with brew install. There's a couple little pieces of configuration that are specific to Gitpod, and the bare minimum is on this slide here. So running that config global to admit containers, DDEV router, which I ran into yesterday completely forgot about, but it's actually a very essential step. So make sure you do that. Standard DDEV config will get everything mostly set up, and then the real main change that you have to make is to bind all interfaces to true in your config, and then it will run inside of Gitpod just by running DDEV start. But can't someone else do it? Absolutely. I have set up a couple starter kit repositories. There is the base one here, which gives you Drupal 9, DDEV, and Gitpod, and this slightly more interesting one, which is Drupal 9 plus Tome, plus DDEV, plus Gitpod, and I'm actually going to walk through that one. And of course, as my primary project at the moment is Drugs.js, there is a version for running a fully decoupled site within Gitpod as well. So that gives you Drupal 9 as a back end as well as Drugs.js as a front end, all pre-configured and ready to go. But I'll walk through this one because Tome is a really interesting project, and I definitely recommend having a look at it for this sort of thing. And this repository here, so github.com slash Drupal pod slash Drupal pod dash Tome dash starter kit is set up as a template. So if you want to get your own site up and running, all you have to do is click this button here, put in a repository name, and create your repository from that, and that will give you everything you need. I'm just going to demonstrate this one here because it's got pre-builds enabled, so that'll speed things up a little bit. If you do set it up, run the template version of it, you'll have to enable the Gitpod application to get pre-built. So I'll just run this now, and it is going to go ahead. So while this is doing its thing, I'll explain Tome. So the idea behind this particular starter kit is the ability to do your development entirely in the cloud. And the one thing missing from the other examples to this point is a database. Tome gets you around that. With Tome, you don't need a database at all, which means when you spin this up, you can start making your content changes and your configuration changes, and Tome will export all of that into the repository. So as long as you commit it, the next time you spin up the Gitpod, it will pull in your content from the file system, which is a pretty amazing thing. So we're nearly there up and running now. So in this directory structure, we have our config files here. Which you will be relatively used to with Drupal, but there is also a content directory here. And that is managed by Tome, as is the config directory. So with Tome installed and set up in this particular manner, you don't have to run config export as you make your changes. It manages all of that for you. So nearly there. All right, we're up and running. I will just pop into port. Actually, I need to. I'm just going to go data, drush, UPWD, admin, admin. And then I am going to jump in to the site. And I'll bring. We can see straight away there's been a change made to the configuration. So when I went to the content, I should say, when I did that, we've now changed that user at that particular point in time. So now I can log into my site and go admin, admin, log in. And I've got my site up and running with a very insecure password. And I can go into content and I can create some content. So article. Come on. Hello, Drupal Sydney. And let's stick in some lorem ipsum and save that. Great. Now we can see over here straight away that this is updated and added a new node that's owned by this specific user. We can go and have a look at our node and we can see that it's of type article and it has this title and it has this content. So at that point, if I'm happy with that, all I have to do is commit that code and push that back to GitHub. So next time I start up a Git pod from this particular repository, it will already have that content ready to go. Anyway, that's pretty much it. The last thing before I finish is just to give credit where credit is due. So Shal is the primary project lead for DrupalPod.com and he's put in a huge amount of work into the project and it's really great. And I think everyone should use the project in their Drupal contributions and open issues when you have them and help out where you can. And Randy Fay, who is I think the primary dev of DDev, who has also helped out with this project to make it so easy to use a development environment inside of Git pod.