One of the main challenges of submitting a contribution to any open source project is getting one of the maintainers to review your change. These people are usually limited in number and may be busy working on other projects.
Does the pattern below sound familiar to you or someone you know?
– Put effort into adding your feature to project X
– Receive no response from maintainer for several days
– Try to reach maintainers through Slack/IRC/mailing list
– Maintainer says something like “will test soon”
…and the saga continues.
Although some form of this is almost inevitable, one way we can alleviate the pain of going through this process is to shorten the feedback loop between the change maker and the change approver via continuous integration.
But wait – do we just want to run an automated build every time a pull request is opened? Well, it really depends.
Managing open source contributions
I maintain an open source project called ChartMuseum. ChartMuseum is an artifact repository server built for serving Helm charts. One of the interesting parts of the project is its wide array of supported cloud storage backends, including Azure, Amazon, Google, Openstack, Oracle, and Alibaba.
The ChartMuseum CI pipeline runs a large suite of Go unit tests, as well as a robust acceptance test suite that verifies Helm works with ChartMuseum end-to-end with each cloud provider. To do so, the pipeline has the necessary credentials to access these cloud providers.
When somebody submits a PR from a fork, how can I be sure the change isn’t harvesting these credentials? Or mining Bitcoin on my infrastructure (extreme..)? The short answer is I just need to take a quick glance at the changes before running a pipeline against it.
New Codefresh trigger for PR comments
Codefresh has now made the feedback loop even shorter with the introduction of the PR comment-added trigger.
Once it’s been decided that a change isn’t evil, one of the repo admins just needs to make a comment on the PR with some predefined command such as /test and the build will begin.
You can create multiple pipelines, all with different comment “commands” to launch different types of tests. You could even go as far as to use the GitHub API to automatically merge a PR in some scenarios. The possibilities here are endless.
So now the maintainers have an efficient way to verify a PR, but what about the PR submitter? A maintainer may have allowed for the testing process to begin, but what if the build fails? The individual submitting the change might want access to the build logs to see exactly what went wrong.
Introducing Public Pipelines
Codefresh has now added the ability to make your pipelines publicly-viewable, even by users without a Codefresh account.
Now, once a build has started, the PR submitter can click the “Details” link which will direct the user to the running build, in a new public view.
Not only is this helpful for pull requests, but also for the current state of the master branch. If a pipeline is marked as public, the pipeline badge (which is typically placed at the top of a project README) will link the user to the entire build history of the project.
Being transparent about the state of an open source project can help gain users’ trust. People are hesitant to use things that are not well tested, especially for mission-critical systems. There is no better way to be transparent than to share your testing strategy and build output with the world.
What are you waiting for?
Go on! Add some Codefresh pipelines to your open source project and start experiencing the difference. Start building your pipelines today!
