As the deadline of our first release drew near, we were tasked to find a partner on slack and make contributions to their repo. It was a very eventful yet incredibly fun experience.
All of our projects are some form of text processing tools using LLMs, and our task this week was to implement a -t option to display token information about our API calls.
First of all, I want to give a huge shout out to Amir. I truly couldn't asked for a better partner! My man literally learned Rust from scratch to work on my project! I landed on his project because it's written in Java - I had some prior experience with Java and I wanted to pick it back up. Later we found out we were the two outliers in this course since everyone else is using TypeScript, JavaScript or Python.
My work on Amir's repo
I reached out to Amir on Slack and filed an issue immediately. I went through the standard git routine: Fork, clone, and create a new branch.
His project uses picocli for argument parsing. I briefly looked through the documentation and realized it was pretty similar to the clap crate I used for my project. So I mimicked his other code as well as my own understanding of clap. This part was easy.
Another thing I noticed was that his project uses Cohere as the API provider, and it is not an OpenAI compatible api, so I spent some time on their API documentation and eventually figured out the response structure.
Another thing worth mentioning: I really had to hold off the temptation to write the code in my own style - Initially, I wrote a separate class just for the token information. But I quickly realized this project uses a more centralized approach when it comes to organizing the code. So I undid the changes:
Honestly, it was easier than I thought. By the next day I had the work done and made the pull request
Amir's work on my repo
After my contribution to his repo, we had a call on Discord where he expressed his interest to work on my project. I gave him a simple walkthrough and a big warning - since he never worked with Rust before. However, he decided to challenge himself and do it anyway. Truly admirable!
I went offline, expecting him to take quite some time. To my surprise, by the time around midnight, he had everything working and submitted his PR!
Doing code review was a really interesting experience. It puts me in this perspective to think of different ways to write my code. It inspired me to have this internal conversation of "how much do I want to keep it my way" versus "is the other person's approach actually better".
In the review, I made some comments on certain things I wanted to change to fit into the scheme of the project, but other than that, the code looked really solid. I checked out his branch and tested to make sure everything was working. However, just as I decided to approve the merge, I ran into some problems:
GitHub (in)Actions
In my project, I had set up a workflow for testing. I configured a repository secret for my API key and it was working perfectly on my repo. However, all the testing failed for Amir's pull request.
I did a ton of research online and eventually found that by default, GitHub restricts access to repository secrets from pull requests. There is a trigger option called pull_request_target, which in theory will grant this permission, but for some reasons it didn't work for me either.
The next day we consulted our professor. We learned that it was a necessary security approach to not allow random people running malicious code on your repo, using your API key. He suggested that I don't use API keys for testing at all, since it would make the API server a point of failure for the workflow.
Instead, I was advised to set up unit testing, with a mock http server that gives hard coded responses. I spent the rest of the day working on this. And by the end, I had a simple test module working!
Top comments (0)