 Hello everyone. Good afternoon. My name is Kapil and I work with, I work with region as a Drupal developer. I love to work with open source technologies and Drupal is one of them. So for today my topic is integration of Drupal coding standards with Github. Yeah. So Github said go. So what are Github's? Github's are strips that get executes before or after events such as commit, push and receive. Github's are built in feature, no need to download anything. They are just run locally. So this is just a technical definition. In layman I would say Github's are gatekeepers. Like they checks you, your ID and let you come in the building. The same thing Github does for us. Yeah. Okay. So why Github's? These are just advantages. So you can say them a good habit. You can enforce something on an event to follow set of rules and regulations so that you can follow proper standards or anything on the commit. It's up to you. So first is auto debug. It will debug your code automatically using phpcs or php lint or set of rules you provide into the hook. Next is auto deploy. It can help you for displaying your code on master using post hooks. Notifications. You can get notified when your code is updated via Slack, Gmail, Outlook, whatever you want to integrate. Cross language. It is language independent. You can use any language, Python, Ruby, PHP, Bash. It's up to you. Drupal coding standards. Coding standards are set of rules, set of program. Coding standards are set of rules for programmers that lay out best practices for formatting and various other rules. It tells us how to format what we write so that everyone is using the same convention and has the same expectation when they go to look at a new piece of code. So this is just a definition, just a set of rules and regulations you have to follow while writing the code. Who decided that Drupal standards? It is decided by community and it is based on the php standards or peer standards. And even you can contribute. If you are not liking something, just create an issue on the queue. That is php standards. The quality of your code is not just in its execution but also in its appearance. Yes, a very nice line. It is not restricted to follow the style but it shouldn't be hard for you also if you see your code after one year or two years. Why coding standards? Readability. It shouldn't be hard to read or understand by the third person who is looking at a code. It can be maintainable. Maintainable code. It should be easily extendable so that we can add more functionality to it or we can reuse that code after a while also. We can extend that functionality also. Spot error more easily. Obviously if your code is properly linted. So you can easily spot the human errors like syntax errors or just missing of comma or the semicolon. You can easily track them. Encourages collective ownership. If you follow your team will also encourage to follow such practices and if it's your responsibility then. So how do they work? Every Git repository has a .git hooks directory with a script for each hook you can bind to. You are free to change update these hooks as necessary and Git will execute them when those events occur. Go to Git directory, select your hooks, write your stuff, make them executable and it's ready. Just make sure that you remove the .sample extension while executing the script or any piece of code you are running in the file. So type of Git hooks. So there are two types of hooks. Client side hooks and server side hooks. So client side hooks, they just run on your local machine. Pre-commit, prepare commit message, commit message, post commit, post checkout, pre-rebase and post merge. The first four hooks let you plug into the entire commit life cycle and the final three let you perform some extra actions or safety checks for Git checkout or while re-facing the branch. Next are server side hooks. Pre-receive, update or post receive. Pre-receive you can enforce some dev policies. Update, it works pretty same as pre-receive and it is still called before anything updated. It has three parameters, reference, new object and old object. And after that post receive. So you can use that for notifying people via Gmail, Outlook or Slack. It's up to you. So as you can see this picture, so you can differentiate between client side and server side. All the pre-hooks run the check styles, protect master and the post one is it safe to the branch and notify chat room. And when it hooks, this is the entire commit cycle till the local one and after that the remote one, the client side one. So changes to commit, pre-commit, prepare commit message, commit message, post commit, pre-receive, update, post receive and then re-base checkout and merge. So pre-commit, you can mention the PHP standards or using code sniffers. You can add them in pre-commit. Prepare commit message just allow you to just alter the basic template of the commit message. In commit message you can just follow the restriction that you can just as an example I would say that enforce user to add the JIRA ID in the ticket. As we not follow in the commit, most of the commits, so you can restrict that in commit message. Yeah, that's a live demo. Okay, so before going to the demo, so PHP code sniffer, it's less than or equal to 2.9. So right now I guess the latest version is 3.2.5, but there is a known issue in the community. And I'm following up on the same. So it is currently working with PHP code sniffer 2.9 or less than that. Get and the coder module. You can download that from Drupal 8 website. Yeah, so I have this file. Yeah, so just create some errors. So just try to commit some message. So it will be notified that it has the file has an error. So first you need to correct that. Yeah, so there is an error. Please append the JIRA ticket number. And even you can notify the user as a you can say that every time developer just forgot to log their time after the code. So even you can remember you can just give them a warning that please log your time as well. Or in the worst case, you can just open a browser window also so that they can force free log the time. So in my case, in my script, in my case, this is the pattern. Now you can commit the file. And now you can push that. So I'll just show you the directory structure. So these are the hooks, apply patch message, commit message, pre-apply, pre-commit, pre-push, update, commit, post update, pre-commit, prepare commit and pre-rebase. You just need to remove the dot sample extension and just make them executable. And you are ready to go. So for the PHP CS and the linter one, I have just altered the file of my pre-commit file. I have added these a piece of code in this file. And for the restriction of the commit message, I have added this. I'm not good at bash, but I still tried something. So you can find n number of examples and alter according to your needs. So I have added one video. First take a look and then just I can relate this. Yeah. So what happened? Anyone? Yeah. So I can relate this in such a manner that my knowledge transfer is done of a product. And when I dive into the coding part and I see that the non-documented code and even if I ask someone, so how he or she can decide that what is going on. So it should be a good practice that we follow the standards to just maintain the integrity of the code and even for the product. Even if you go, the project has been transferred to someone. So even they are just by the documentation, they can go and just give it a shot. So thank you so much, guys. Questions? Which two hooks? Yeah. So the prepare commit message just give you the alter of the specified template. So there is a default template that you should follow. So prepare commit message and commit message. So they have a difference on commit message. You can check the restriction in the prepare commit message. You can define the template of the commit message. Yeah. With a race. No, no, no, no. You can just it's just a language independent so you can write in the on the local machine. You can run the server hooks, but on if you say on the server side. So on the you can use web hooks. So Bitbucket gives you but GitHub does have a plugin with the Jenkins so that you can check. You can create a job in the Jenkins and just write the code, the piece of code there. So on the GitHub, you can just take the whether it is following the standards or not. So with composer, I guess it's not possible. No. Yeah, sure. And even who is interested setting this up on his local machine. I have created a well documented step by step doc so that you can just set up it locally in just 10 to 20 minutes. So I figured I'd use the mic. I just had a question if, if all the get hooks are local. Is there a way to enforce a certain set of scripts for like a distributed company? What's the is there a good practice to transmitting that to each developer on their local machine? Ideally, we have a way that we can sim link on the local machines. We can create a sim link and distribute among all. But but if you want to integrate the server side, so it might be a hectic because you have to even some of the contributed modules also does not follow proper standards. So that should be a case that you have to set up this on the local system. Yeah, make sense. Thank you. It's already there on the GitHub. If you if you are using get it, it is already there. You just have to use them. You have to write the piece of code. What what do you want from the? What do you want from get hooks? What do you want to implement? You have to write the code. Yeah, that's what I'm saying that there is a way to sim link the get hooks so that you can use the same hook on the different repositories. I had a question about just you showed the pre commit hook and then the commit message hook. What is like a good practice on what steps of hooks to use in a project? I've used post receive to apply code onto a server after pushing or after committing to a branch and then pushing those changes to that specific branch on the server to change the code. But I guess it totally depends upon your requirement. So you have to decide that what hook you are using and what you want to implement on the repository. So that's the decision you make while implementing the project. Okay. So you showed pre commit. Are there good practices to use when you're using hooks locally and then on a server where you're pushing those changes and yeah. Could you maybe go more specific on how you would use post receive to maybe if you push changed and you want to go back a commit or take back your last commit that you might have pushed. That you can enforce on pre receive so that it could not be merged to master on post receive only you get the notifications because it runs after the master has been updated. Okay. So it's kind of a matter of just you have to decide what you want to implement. That's it. Okay. That makes sense. Thanks. Thank you so much guys.