First steps as a contributor
As a part of my open source journey, it was long due that I started contributing to these projects myself. The fact Hacktoberfest 2021 was going on, only added more inspiration to the mix and I started looking around for issues that I could work on.
Finding an issue in an open source project
This was actually harder than I expected. As a starting point, I wanted to focus on issues that were targeted for newcomers to projects and so I focused on issues having the label good-first-issue or hacktoberfest. Even though there were close to 50k open issues that came up, a lot of them were in old projects and the ones that were newly created often had people already working on them.
After I had spent a few days, on and off, searching for the perfect issue for myself to work on, I realized that my strategy itself was inherently flawed. I was looking for something based on JavaScript/TypeScript in a popular open source project, targetted at newcomers. This drastically narrowed issues I could work on, not to mention that the competition for these issues is fierce, especially considering Hacktoberfest.
I knew that something had to change, so I stopped looking for the ideal and restarted my search with a open mind, prepared to be challenged. This is when I stumbled upon #2384 in telescope.
Telescope: Autodeployment server not remembering previous build info
This issue was related to autodeployment and this was something that I was not familiar with. However, at this point I was ready to learn and tackle the issue and I decided to work on it. After indicating my intention by leaving a comment on the issue, I started exploring the problem.
The /status endpoint was not displaying the previous build information and was instead returning null. The bug was quite well described, with links to the files and a possible solution that could fix it. I was specifically looking at this part of the code:
build.proc = shell.exec(
`./deploy.sh ${build.type} ${build.githubData.after}`,
{ silent: true },
(code) => {
build.finish(code);
builds.current = builds.previous;
builds.current = null;
// See if there's another build ready to go
run();
}
);
Having never worked with shelljs, I spent a little bit going through their documentation and found out that exec() accepted 3 arguments for the callback, namely code, stdout and stderr. Gaining that little bit of knowledge, I went back into the file to gain an idea of what was going on.
The problem was with these two lines:
builds.current = builds.previous;
builds.current = null;
builds.current was immediately being assigned null, so that made the previous statement redundant. However, more importantly, the previous build information was never being persisted, which is why it was null in the /status endpoint.
Thus,
I replaced it with:
builds.previous= builds.current ;
builds.current = null;
Now, while I was confident that it would fix the problem, I was still unsure as I hadn't tested it yet. Since this was related to autodeployment, I was actually not sure if this was something I could even test locally so I asked the maintainers for advise and I was suggested to open a pull request.
*Link to the pull request: #2392
After going through the review phase and addressing the changes, I merged in changes from master so my branch could be merged. However, it was pointed out to me that that I should instead rebase on master. So, I ended up rebasing and squashing my commits (twice! as the first time my local branch wasn't in sync with the upstream). Finally though, the pull request was accepted and merged!
Being my first contribution to an open source project, this was definitely a wild ride starting from the search, to actually setting up complex projects and working on something I had never done before! It was a very exciting process and especially when I saw that my contribution made a real difference even if it wasn’t a big change. After the bug fix, the /status endpoint correctly showed the previous build information:
Top comments (0)