 All right patches almost that that long leave merge requests That's what we're talking about today, but before that I wanted to acknowledge that we are streaming Recording on a Gadigal land. I would like to pay respect to the Traditional owners of this land. Hello. I'm Vladimir When I don't read books with random dogs, I do Drupal and It's time for a story so I spend the last year 12 months teaching in TAFE and Those are quite an eye-opening experience so I've seen quite a few different students for the reference TAFE with Australian College Government College where Basically which prepares Students within a year depending on the degree they are doing for the industry They do everything from nursing to IT and so on and so forth So the most interesting bit was that I finished uni in 2005 We didn't do much kid back then and Surprisingly enough. I realized that the IT industry doesn't teach kid now and With the TAFE we have an agreement to have kind of industry feedback and because I'm running the company I said I can give you a feedback and one of my first feedback was you have to teach kid because regardless of the technology regardless of the What are you gonna end up doing in IT? You need to know what version control is. Why do you need to use it and so on and so forth so So That as I said though that actually made me think we are doing patches AI people in other room I mean so I maintain quite a number of modules as well so I talk to developers in the issue queues and not only developers and Another outcome of those talks Again for the last 12 months was that have a comfort Comfortable with patches. Why do we need to do merge requests merge requests are tedious. We need to learn something new Again, not everyone said that but I heard that a lot which ultimately think hmm I was surprised because I'm using stuff like github and githlop on a daily basis I thought that was kind of given once you have a merge request why do we need to create patch in fact? I always hate patches and I'm gonna get into that in terms of like how Do we do that and I think the cherry on the cake was one of our clients that Basically quit git They use the hosting provider that is not git based hosting provider. I mean you can do it git but By default it's not git so it means you can modify the files Or you can send a creative click and update stuff on the production basically do all the fun stuff that makes your website go boom sometimes and Yeah, and they said look thanks for setting up the git and see I so nice But hey, I'm comfortable just SSH into production and do composer update. Oh, I go. It's not a very very good idea because of And I listed all the reasons why it's not a good idea, but in a day They quit git so that was the first time which basically was a prelude of saying okay. I need to talk more about why do we need git? Why do we need actually? Tell non-technical people that git is important Because it seems like the message is not getting delivered Especially the message does getting delivered where Drupal is not right or even some people who run Drupal. They think ah, it's fine I'll just update so target audience for this talk a Basically, I teach students anyone student here There you go one excellent welcome People who graduated people who didn't use git Clients as I mentioned before Who don't like it didn't use git who think this is something for developers Obviously developers who needs to deliver this message or could be convinced otherwise Or saying, you know like merge request. I'm comfortable with all the technology and that's fine So an agenda for today. So we're gonna talk about patches. What is patch in a nutshell? What are the merge request? How they differ into patches? What did git lab? bring to Drupal and How we can leverage that to our advantage? We're gonna look at git lab CI And pending we have time we might even do a little contribution So my talk finishes Doesn't even know what my time will talk finishes. That's fine. I have a schedule 1215 excellent Let's keep going Okay, so if you've been to such is the first time contributors workshop. That's pretty much Success this session would be a successor to her session I will try to post the video for the first time contributors workshop before tomorrow's print So other can watch it again, but if you're watching it online, obviously, yeah, that's something to watch it first. I Also, don't forget. There is a code sprint. Please contribute if you can tomorrow 9 o'clock Carrethane room just this one Right, that's a career And thanks to Bruce next for sponsoring the code sprint for the last many many many years Okay, let's look at the patch. So what is a patch to create a patch? We need a git. What is a git? Git is a revision control system. So you have a code. You have a change. You have another change That's how your system develops. So you need to save it somewhere, right? And the most common use of the git and the most popular one is a github Does anyone not having have an account on the github? So in Drupal world We actually once we set up all the git shenanigans and all that we just can go and pull the code This is an example of a very very little module called dynamic menu item And as you can see there is a version control tab once you logged in and set up your git There is a branch default branch So when you select that you can pull the code and start making changes, right? So that's the basic kind of the contribution. So once you get the code you can Change it and generate the patch The patch is the changes between the commits, right? And if you confuse with terminology Let's have a look at it because the best way to learn is a visual way So we have a branch branch usually main branch and this is where all your code contribution sits so someone comes and contribute the code and That's what the circles represent. So each circle. It's a commit which Basically gives a bit more functionality it takes it away or you know do some changes to the code and someone comes in adds a new commit to a code change and that's how software system develop. So if we'll look at the issue on Drupal.org In this case the issue was actually automatically created by a bot. So Drupal 11 is upon us this year so the bot started going around a couple of weeks ago and Check what needs to be done for the module to be compatible with Drupal 11 So if you scroll Straight after the issue description Now there are two sections. The first one you probably saw it the same thing happened three years ago for Drupal 10 So the first thing is the patch the file that actually shows the difference, right? And if you look at that file, it's a plain file unless you install the browser plug-in And oh does it says Throw out this line at this line. That's all your module should be compatible with Drupal 11 So how do we create patch? So find an issue as I said before We pull the code We did the code changes and We generated the patch right So if we look Can everyone see the His size fine. Can everyone see that? good, so if we do Git status in our system, I pulled exactly the same module dynamic menu There's no changes there. We go and do a suggested change right or 11 with a git Git status, you can see one file was modified. That's what Dread is for there. We do git diff and We can see something something very similar, right? So things comes out things come in relatively simple, but Again, that's a change and then we'll do the commit So let's talk about merge requests. How are they different to a patch? So already have a difference. Why do we need a merge request? The merge request is a proposal To incorporate the changes from the service branch as you can imagine Drupal At the single time. There's plenty of developers are working on the same thing, right? and different things so different features someone work on translation someone works on revisions So there is many many branch if we all start pushing stuff into the same branch Obviously, it's gonna be a mess That's why main branch of Drupal kind of seats there, but we create a separate branch and What we do is we do our commits. We add some code change some code Modified and I will create what called merge request. So once we think the functionality is complete What we do we go and say I want to send this code back Again, this is a simplified version whoever work with a merge request and branching knows that you have to do like Continue and pull in the code if you're working over multiple days and doing all this stuff, but In a nutshell, that's the reality and then once your code would go through approvals Maybe a bit more changes. You finally can push your code back and the main branch would be updated So that's what merge request is And again, if we look at this automated issue created by this Created by this board We can see that under the patch Now we have a section that actually contains a merge request now with Drupal it's not only when we create and we will go and create the branch It's not only creates the branch. It also creates a repository for this branch. The reason for that is That you actually can go and commit to it because you don't have access to a main branch of Drupal and most of the time You don't have an access to a main Branch and repository of the module because you're not a maintainer. You have to be a maintainer So to do that when you create a merge request. It actually creates a different repository pulls the code in and then you do merge request from one repository to the other but In a nutshell, if we'll go back to here, it would be the same. It would be just not only different branch It would be different repository and in the end you would say merge request and however has a right to merge back into the blue Circle and the main branch would actually do that Any questions? So here's another Merge request and I just wanted to point out so when you get a patch file when I get a patch file All you have a file right file with a difference. You don't know if you can merge it back You don't know there's too many variables with the file Although all you need to do is pull the code get a patch try to apply the patch if it works It's great. You start testing if it doesn't work You'll try to figure out why it doesn't work. Maybe patch needs update. Maybe there was a new version Maybe something else was there whereas with pull request. We already can say if Few extra things not only we can see play and if next to a green tick which Shows us exactly the same file. You know, we can also click on changes and have a visual representation of those changes It's gonna be next So I will see that in a few slides But we can also see the name of the branch the green tick actually means there is a Cei is running which we're gonna cover in the final section and it also says it's mergeable It means whatever you have there you can push it back without any conflicts now To when you create a new branch we'll see that when we create a new branch you have a set of commands How to so basically the first and the second section? It's adding the new remote just because we created a new repository right that we need to do a pull request from and Then we have a command how to check out our branch from this repository and the bottom bit is actually once you did the commits You will go and push them using this command right on the bottom Now actually commits commit message you have to scroll all the way to the bottom to get a commit message and It's fine when you have ten comments when you have 120 comments Sometimes it's a bit fun. You need to scroll all the way down copy the commit message all the way up copy the Push message on the bottom and do that. But yeah, it's just something you have to do at the moment So github github was introduced on a back of Drupal. So it's not github.com But yeah, I would recommend you to go and learn more about github because it's not just code repository There's many other things that are part of the system and that's the only code repository out of big three Which is a big bucket github and github that you can install community edition for free on your server For beat bucket enterprise and for github enterprise you actually need to pay And the community edition is fully open source. So here's our Drupal Thing to go and find out how github looks Any module including Drupal core Slide all the way to the bottom of the right column click on the source code And you will see the source code. So this is a Example of how github shows the difference. So two lines we changed In the patch file they look different in Github and actually visual and you can see the list of files that will change so Here's our Drupal code repository and on the left hand side whatever we learn about here's our list of commits Here's our list of branches. Here's our merge request So we can go And check them out and see do we have any merge request there. Do we have any What sort of branches do we have what sort of commits? So again Once we click on Changes instead of play and diff. So that will be our play and diff, right the file we saw before the changes We'll see the changes like this, which is nice and highlighted Here so Makes much more difference Github ci so ci continuous integration is a development practice Where code changes actually Run while we push them commit them and merge them the runs through a set of automated builds tests and different things So and if you use ci before the Drupal ci There was a message not that long ago that on july 1st 2024 which is this year first of july Drupal ci and all patch testing will be turned off So if you thought that patches are still fine one thing you won't be able to do Is you won't be actually from january 1st You won't be actually see any see a Drupal ci testing Which is an all type of testing where you need to go and manually tick which version of Drupal and the database You can use that's why it makes sense to actually move towards Github ci and this is a timeline It's in this tweet, but basically 1st of july non-drupal ci tests will be executed anymore That's all will go towards github and 1st of january no Drupal ci testing results will be kept beyond 1st of january 2025 Okay, so Github ci documentation is in progress Once you start learning ci, I do recommend you to go read it and contribute to it There is some things that needs to be added, but it's a movable thing So I would recommend you if you do in a sprint If you decide to do a ci file in your module or someone else's module Please read through documentation see what is missing. So how did I discover github ci? Last year I was really into eca that still is but I was looking through the code and I saw the Don't github ci completely miss the github ci announcements So I actually found it through the module went to the code again scroll on the bottom source code and I saw github ci file It changed over the last year, but the reality is you don't need much to enable the ci And there are three files that included that that you can see on a line five six and seven That will automatically kick off a bunch of scripts for you. It's going to check integrity of your composer It's gonna run es lint unless you switch it off phpcs and bunch of other stuff And that's the file you can copy and put in your repository. So again here the green tick Means that the oci passed on this particular merge request And you can actually drill down to the issue And see what's wrong. So you can see there are three stages First stage is ticked which is past the second stage have some warnings or it allowed some Um tests to fail and Third stage is all good So we have time. Let's try to do a contribution So here's our dynamic menu item Module which I told before version control. We pulled it back We did it there I'll copy the document Have it open There we go So they actually say in the documentation what they say you can actually go And if you read the documentation, there is a template and you can add template GitLab ci as a file To your branch. So you can do it through a template or you can just create a file and copy there Okay, so I'm gonna copy that I'm gonna go to my dynamic menu items I'm gonna go to my issues Create a new issue and we'll say make sure there is an issue if you're doing some contribution add Ci to this module based on Drupal Docs I'm gonna give me an error. So make sure you select that it's a feature request Latest branches. I use development branch and it's a part of the code Save now Yeah, we created a new Issue Now you can see there is a because I created this issue. It says create an issue fork What we're talking about? So it's gonna fork the repository And then do create a Separate branch the one we can commit to right I keep on clicking on this height. It just hides it visually From here, but show commands is Dangerously near it. So show commands is the button you need if you want to Contribute the code. Yeah, you need to follow those instructions Right alternatively you can click and go directly to git lab interface So this is our branch So it says it's forked from project dynamic menu item Do I see at the file? I don't So what I'm gonna do now I'm gonna follow the instructions and I'm gonna commit to Fresh this page make sure I get the instructions. So here go to my code first uh Making sure we know about the other repository that was created then We Check out the branch We need to contribute to Git branch to check that we're actually on a correct branch Right here Can create the file or copy it from another Repository for example, if I'll go to eca you have it somewhere here I can copy git lab ci here Okay Git status it says you have a I'm gonna remove this Change I did before So I have one file now if I'll do git status one file, so I'll do git add Dot git lab I'm gonna scroll the way to the bottom to the commit message Scroll back up to the push message Okay, we pushed our ci file And we'll see that's gonna be reflected very soon here Should be So if I'll click here Yep Ah, I'm not signed in That explained that explained that that's another thing that uh always gets me Don't forget to look up in the top corner and make sure you are signed in Uh, yeah, that's why I couldn't create the file from the drop-down menu either Okay, that makes sense. So now it will ask me. Yeah create a merge request when you create an merge request Check that if this is a correct branch sometimes default branch might be different and that happens from time to time I don't want let's say I don't want to close the issue for example While doing that create the pull request. So when we're creating the merge requests You can see That the now we have a pipeline And if we click on a pipeline it actually consists of two states for now And it actually quite dynamic so it can be two or three stages depending on what you edit and you can see in the first stage It does some composer test in the second stage. It validates. There's composer lint Spelling check PHP code standards for your Drupal code standards as stand. So while i'm finishing it I'll let it run and we'll see the result there But I already contributed and created the merge request so Let's finalize it and then have a look at our results So to conclude please use merge requests if you are contributing to Drupal if you're doing any contribution patches are still fine but there's obviously way more insights and especially Help reviewers to review your module to create merge request. I'm just saying it twice Learn git if you didn't or teach git which I think is another good point as well We all think we know git until we learn a new command That's that's the case been the case for me as well so Keep on using git keep on learning git and have a look at the git lab features That are available for you as a Drupal developer. There's plenty there to learn and again the system is massive so uh If you are going to genre session at three o'clock accessibility in whizzy we get it there She would talk more about insights about full request um And the changes she did for accessibility and ck editor specifically So if you're interested more check out her sessions It's mostly about accessibility, but there are some insights about the issues there as well Oh, I see it when it's Recorded so let's have a look at our pipeline So composer went through composer lint. I assume if it's gonna fail. Usually it's phpcs So you can click on the runner and see while it's going. So it's still running. So I would like to really Say big thank you to volunteers organizer sponsors And thank you for coming and do we have any questions? Yep, so if you go to the eca Uh, here's a eca git lab ci file as I said it changed recently now. It's a bit more clear So you can see here, um, you can see here that they actually, uh Showing what to allow failure And what to there there is an ability to switch off specific That the well false means if it will fail it will stop So most of the stuff I think by default most of the allow failure is true So it means you'll get a brown Exclamation mark and see I would continue running Where is it? That's right Yep Yep, and I'm still learning it because what I saw is if your module has Night watch test they say, whoa, ci would automatically Detect it and would add a night watch Uh container there So there is more to the ci that That that's that to the eye And uh, I would recommend to create the template and read stuff on the template and also go to the documentation Uh, if it's still open here go to the documentation. They do go Inside the pipeline and where to run it And uh some stuff there. It's not complete as I said needs to have more documentation But check the documentation and check the template file Any more questions? Yep Yep, so if we go back to the issue, thank you for that Go back to the issue There you go So here, yep, so you can add div or So there is a plain div Which basically says merge request dot for div That changes that and uh, you can do it and get This is Drupal specific, but you can do it in github and gitlab Using specific URL as well and we saw that We saw That our ci failed. So let's have a look at the results. Obviously it's php code standard And we just go and say oh the code standard is not up to date We can see why it's not up to date also, I found If you are referencing directly Do a prefer source because composer does caches it And if you don't use prefer source, it would actually the composer would download this div From some time and would use it until the composer caches clean and then it would download the newer version So there is a yeah both ways, but that's a good reference Yep, so So yeah, that's uh, usually the case for Version updates. So thanks where the composer changes. It's a good question So you actually in your Because I said when you do a merge request it creates a different repo So you can actually reference this repo and reference this particular branch So what you would do Let me see if I have I don't think I have So we have a section called repositories in our composer So very similar to how we reference for example the library, right you would reference you would say v Vcs I think and you would reference so If we'll go to our branch here So there you would add There you would add the This code repository And then you would reference the branch name Prefix in it with dev dash Then you can pull code directly from this repository and from this particular branch Yep Yep, yep So unless you are the contributor Don't do that, but I did that a lot when migrating clients to Drupal 10 and we couldn't get the Drupal 10 module Up to scratch that would be the only way there is a composer plugin that kind allows patches To turn into a newer version, but I found it didn't work all the time so Yep, yep the saving the file with your repository and documenting it and the commander that's the way One more No, we're good. Well have a good rest of your conference Thank you