Open Source Project: Lab2 (Pull Request)

-

 Introduction

In this lab, I practiced contributing and submitting pull requests to other repositories I don't own. Following the lab instruction, the things I plan to practice are the following:

  • forking and cloning other projects
  • creating branches to work on new features and fix bugs
  • working on code I didn't write, trying to maintain the original style and not break things
  • creating pull requests
  • collaborating with other developers on GitHub
  • updating my pull requests to include fixes for review comments


The Project I picked for pull request (https://github.com/lixiaoqity/testLink/pull/7)

I looked around the classmates' open source project and picked the project named testLink. The GitHub repository link is the following: https://github.com/lixiaoqity/testLink/pull/7. 

I picked this project because it also uses the NodeJS which I picked for my project. It was really interesting to see how code can be written differently for the same subject. When I look over the project, I realize I can add more features to this project. I filed the issue to say the feature I want to add and started working on the new feature. The new feature is an optional command-line argument -s which checks whether http:// URLs actually work using https://


At the first glance, I thought it is easy to add an optional argument. However, it does not work when I tried to use the way I did because the way the 'testLink' project handles the argument is different from how I did. I read the codes more carefully and got the way how can I add the feature. I created one function named testLink and put the code to check whether the link is good or bad. Also, I declare a variable named flag to make it true when this tool finds the arguments '-s'. Therefore, when the flag is true, the tool checks whether http:// works using https://. As I tried to maintain the original style Leon wrote the code, I only checked fileName[0].


The challenging part I got was maintaining the original style. I should get how he wrote the code, what he treats more or less careful. When I figure out how I can implement a new feature following his style, I felt exciting! This is the pull request I did for the new feature: https://github.com/lixiaoqity/testLink/pull/7. It was closed yesterday but Leon opened the pull request again. I am going to talk about this more with him later.


I got confident I can do better if I need to do a pull request and file issue. I practice how to use GitHub more professionally and it was an amazing experience! Also, I've learned how to do pull request, how to automatically link issues with the pull request, how to review the pull request, and how to merge the pull request. At the first time, I was confused how to check the part the code changed. I can see the changed part of the GitHub and review them. However, I did not know how to get the actual file with git. Later on, I got I can clone the forked repository he did to improve my code. This experience will worth in my future because I will not feel confused anymore for the pull request. I can reduce time as I already know how to get the new branch another person commits for my project next time. I am sure this knowledge will be worth in the future. I've learned a lot.


The pull request I've got
I got three pull requests to improve my command-line tool. I'm going to describe the optional features three people want me to review.


The first pull request I've got is passing directory path options. Kimin Lee would like to add a feature to check all files in the directory I pass using the argument -r. I cloned the directory he forked and tested whether my original functions are correctly working. However, I found four issues.
  • The README file has a newline issue on the argument section
  • In my previous code, I allow users to enter multiple arguments at the same time (e.g., url-fi -hvs test.html). However, it does not allow to do this when I use his code
  • When I use this tool without any arguments, it does not work
  • When I enter -r argument with a file (not a directory), it gives an error (ENOTDIR: not a directory).
I asked him to fix these issues and wait for him to fix them.


The second pull request I've got is path normalization. He code allows my tool to use relative path to find the files. It was an amazing improvement! I've merged his code to my repository.

3. Process multiple files and other tweaks (https://github.com/hyunjiLeeTech/URL-FI/pull/9)

The third pull request is allowing multiple files and other improvements. While I've reviewed his code and test, I found it doesn't work when I enter any arguments. It gives me an error when I tried to use any arguments. I ask him to fix this error and mention that I make my tool allow multiple arguments at the same time (e.g., url-fi -shv test.html) so consider this feature as well.

Comments

Post a Comment

Popular posts from this blog

Lab 8: Automated Testing and Continuous Integration

-
When I developed a program, it was time-consuming to test all the functions I created when I add a feature. I needed to run each feature, check whether it gives expected output or not, and check all the output. It is possible I forgot to test a feature and later on, I realize I did not test the feature. I wonder if there any ways I can do it automatically. Now, I got the way how to do that. There is automated testing for it! To begin with it, I started searching the testing framework to apply my command-line tool named url-fi. There are some testing frameworks for Node.js such as Jest, Mocha, and AVA. The testing framework I chose is  Jest  which is a testing framework developed by Facebook. I've installed Jest running 'npm install --save-dev jest' and test whether it works properly or not.  This document  is the way I followed to install the Jest testing framework. After I've installed the Jest testing framework, I worked on separating functions. As my tool contains al
Read more

Project: Final

-
Introduction In this post, I will describe the summary of how I have done each stage. The purpose of this post is for wrapping up this project. The purpose of the project is the optimization of one open-source project. I need to compile, benchmark, profiling, and optimize the software. The detailed information about the project is described in the  SPO600 winter project .  Previous posts related to this project The previous posts for this project are listed below. You can read the detailed steps of how I have done each stage. Stage 1 Project Stage 1 - Compiling and Benchmark Butteraugli Stage 2 Project Stage 2 - Profiling Butteraugli Project Stage 2: Profiling (x86_64) The links for the results Project: Organize the Results Stage 3 Project Stage 3: Optimization Stage 1 Stage 1 is for building and benchmarking the performance of an open-source software package. There are some requirements for the open-source package I need to consider. Firstly, the time for testin
Read more