How to Contribute to the Harness CLI
Last September, we released a command line client for working with Harness. The Harness CLI is open sourced under the MIT license, and it provides an alternative to the Web UI for creating and managing pipelines, environments, and other CI/CD workflows. The purpose of this post is to provide some guidance around contributing to the project, including a retrospective of my own first PR, with lessons around contributing to open source in general. You're highly encouraged to read through the release blog for more on our motivations for developing a command line client.
Learning From My First PR
I recently opened my first pull request for the CLI project: a small tweak around creating secrets in Harness' built-in secrets manager. The team was kind enough to approve and merge the PR last week. While this was my first code contribution to the CLI, I've relied on it heavily as a user in my day-to-day work. Here are a few things I learned in moving from a user to a contributor. These are lessons can probably be applied to almost any open source project.
Don't be afraid to start small
Open source projects often have community expectations that far exceed the number of contributors and maintainers. OpenSSL famously had one full-time maintainer when the library's Heartbleed vulnerability was discovered back in 2014. Many project maintainers at minimum split their responsibilities between their business facing role and open source work. They're excited then when community members offer their help, as they almost always could use it.
Some projects have a CONTRIBUTING.md in the repository root that lays out contribution guidelines. Otherwise, opening a GitHub issue (for larger contributions) or pull request (for smaller patches) is a good bet. A maintainer will then be happy to point you in the right direction.
Feel free to offer code if that's your skillset. However, contributions to docs are just as valuable. If you don't feel comfortable around the codebase, any efforts toward enhancing or clarifying core documentation, tutorials, and diagrams should be well received. Skilled technical writers are sorely needed in open source. My recent contribution to the Harness CLI was a blend of both code and docs. I added an argument to the secrets management command, and also updated the help docs to include the new required parameter.
Understand the project's ecosystem
As I mentioned previously, don't be afraid to contribute even if you're new to the project, with copyediting the docs as a great starting point. For more substantial contributions, you should strive to understand both the codebase and user experience. The Harness CLI, for example, implements command line equivalents for workflows performed in the Harness Web UI. It uses REST API calls for the creation and management of most entities. You'll want familiarity with these concepts, and should also have a Harness account for learning and testing.
Beyond a technical understanding of the software, be sure to also align with the codebase in style and syntax. If variables are camel case, use camel case. If functions are heavily broken up, try to follow that pattern. Perfection isn't expected of course. Just make an effort to speak the language of those who will be reviewing your PR.
In my case, you'll see I wrote my code to match the project's conventions for command flags and variable names.
Leverage AI coding assistants... to a point
I'd be remiss if I didn't bring up generative AI and coding assistants. These tools help developers feel more confident writing code that otherwise might intimidate them. Please do use AI to develop code snippets, mermaid diagrams, improvements to documentation wording, or any other contribution you'd feel would be helpful. Still, don't generate boilerplate, untested code and submit a PR without understanding the what and why. That would just waste the time of reviewers.
Instead, prompt the UI with problems motivated by your knowledge of the project. Then carefully review the output and modify as needed to match the codebase's style and contributor guidelines. AI and code assistance are great productivity tools; just combine their use with care and intentionality.
Contributing to open source is a fantastic way to stretch your technical skills and network with developers from all over the world. Harness hosts several open source projects, including the Harness CLI as well as the development platform Gitness. We welcomes contributions, so feel free to open an issue or PR. Please also consider joining our community Slack channel to interact with other Harnessians as well as the broader CI/CD community.