Indeni Knowledge Language Training 

Module 4d: Pull Request

 



   ← Previous Module  Next Module →

Indeni Knowledge Language Training Modules

Module 1: Introduction

Module 2: Interrogation & Monitoring

Module 3a: Basic JSON XML Parsing

Module 3b: Advanced JSON XML Parsing

Module 4a: Setting Up IKL Environment

Module 4b: Command Runner

Module 4c: Using SoureTree

Module 4d: Pull Request

 

Full Video Transcript:

Hey guys. For this session, we’re going to focus on knowing how to… now that you have pushed code into your GitHub repository, which is right here. I’ve provided the commit. We now want to see if we’re ready to start seeing if we can push it over to the actual Indeni Knowledge Repository, have someone review the code for you and determine if it’s ready for pushing into testing and QA. In order to do that, we want to do two things. The first thing we want to do is determine if we need any other changes that we need to consider. So, we’ll look at comparing your repository to the other one. We’re also going to look at… And then, after that, we’re going to do something that is called a pull request, which allows us to merge the code you have in your repository into the Indeni Knowledge testing repository, if that makes sense.

 

So, the first thing we’re going to want to do is click ‘+’. You’re going to want to compare branches or tags, and then you’re going to want to click ‘Compare’. Now, as you can see, the only difference from our source, which is our own Bitbucket repository versus the Indeni Bitbucket repository… You can see that the only difference is the commit or the code that you generated from your own ‘.ind’ script. If you click ‘Diff’, you’ll see exactly what changes were made. And, if you look at ‘Merged pull requests’, you’ll see which pull requests are currently active, based on your repository.

 

We’ll get to that point next, which is where we go ahead and click ‘Pull requests’. And, you go ahead and click ‘Create pull request’. And, you’re going to do it based on your master branch, which you don’t have to do any changes for. But, please make sure that you make a pull request to the ‘indeni/indeni-knowledge’ repository and you make sure you provide it into the staging branch.

 

The next thing that you’re going to want to do is make sure that you change the title and assign it to the IKP ticket. The way to assign it is simply make sure you invoke the name of the ticket number onto the title. So, the naming convention for that will be below. The naming convention will be IKP-914, which is a JIRAH ticket that we quickly generated for this purpose. We’ll provide a description: ‘added new code into script’, and we’ll go ahead and ‘Create pull request’. Do not worry about assigning a reviewer, because that will be automatically assigned to you.

 

Now that you’ve gone ahead and done that, make sure that only your commits are being added. Again: Look at the ‘Diff’ and confirm that these are the things that you want to make commitments to. Then, you go ahead and ‘Create pull request’, and that’s it. Now, it’s up for the reviewers at Indeni to determine if there is something that needs to be changed.

 

You’ll be assigned a reviewer here, which you’ll notice shortly. As you can see, somebody’s already looking at my pull request. So, let’s give it some time and determine if there’s been any changes. And, the way to do that is to go ahead and refresh the browser and see if anything’s been added. So, let’s go ahead and click ‘Refresh’. And, as you can see, I believe our reviewer has gone ahead and added a comment into one of our scripts. Let’s go ahead and take a look. By the way, if you want to know if you can get notified in any other way, you’ll be getting an email directly from our reviewer to determine if there’s been any changes that have been made or commends made on the code or any other commitment.

 

Now, let’s go ahead and scroll down to where exactly our code reviewer make any changes or make any comments. Oh, there it is. It looks like Ulrica wanted me to make sure that the value is not ‘1.0’, and that the value or the output should be ‘0.0’. That means I’m going to have to go back to the ‘.ind’ script, because this is the output file where it only generated or simulated using CommandRunner. So, I’m going to have to go to the ‘.ind’ script.

 

So, I’m going to go back to my Sublime Text, but before I do, I just noticed that I got another comment from Ulrica. In fact, it’ll tell me right here. Okay. It says right here that my title should also include the platform name. In this case, it would be ‘IKP-914 F5 <with a description>’. Okay. That’s fine. Let me go ahead and edit my pull request. Make sure I add the changes that she had requested. So, I will provide ‘F5 <Updating Weak SSL IND Script>’. I’m going to update my pull request.

 

Okay. Now that we’ve gone ahead, and we’ve updated the title, let’s go and change the appropriate values in the ‘.ind’ script that she wanted me to go over. So, I’m going to go over to my Bitbucket repository. I’m going to pull up the ‘.ind’ script. Let me see if I can quickly look for where we write the metric.

 

Okay, so, in other words, she’s going to want me to invert the logic that I have applied. So, in here, I had the logic that if the second value is equal to ‘enabled’ and the renegotiation size is less than or equal to ‘1000’, and ‘sweet32Cipher’ is equal to ‘true’, I want to assign the metric and the value of 1.0, which is right here. So, in order to change that, I’m just going to simply change this value here to ‘0’. I’m going to click ‘Save’. And, by the way, if you feel uncomfortable about any changes you made, you can quickly simulate that using CommandRunner to determine if the changes that you made will take properly.

 

Once you go ahead and validate that you can go back to SourceTree. And, you’ll see that under ‘File status’ that changes you made will be identified under the ‘Diffs’, and you’ll go ahead and click ‘Commit’. And then, I’ll put here: ‘updated writeDoubleMetric value to 0 instead of 1 for given case’. I’ll go ahead and click ‘Commit’. I’ll take the commit. I’ll go to my master branch in my local repository. I’ll click ‘Pull’. And then, I’m going to go ahead and click ‘Push’.

 

Now, I’ve made the commitment over to my master branch. I’m now pushing it to my Bitbucket repository. And, if I go back here, you will notice under ‘Commits’ that a new commit has already been added onto the pull request. And, that’s all you need to do. Every time the code reviewer adds any comments or changes and you make those required changes, and you provide commit, and you push; those commits will automatically be updated under your pull request. And, that’s all you have to do.

 

As you can imagine, there could be a lot of comments and a lot of things that we’ll be reviewing in the code. Don’t worry about how nitpicky it may seem. We just want to make sure that there’s a certain level of consistency across all that’s being contributed into our staging branch.

 

That’s it for today’s session. If you have any questions, please post on the forums. Thank you.