The new Sibbell GitHub Integration
TL;DR You can now install Sibbell directly onto your GitHub repos. Sibbell will create GitHub issues when there’s a new release you care about so that you can work those discussions and updates directly back into your development process.
The purpose of Sibbell has always been to keep you up-to-date on the projects you’re interested in. It started out as a personal product, because it was solving a personal problem. It has always been great at helping you browse the web, stumble across a GitHub repo you’re personally interested in, and immediately “star” it to begin receiving emails from Sibbell when they publish a new release. It’s an extremely lightweight, noise-free way to stay in touch with a project that you already use or someday might want to use.
As things have evolved and after talking with lots of people who use Sibbell, we’ve come to the (mostly obvious) conclusion that the more advanced use cases are really “project” or “business” oriented, not personal. Which makes sense. At some point the projects that you follow become more than just “interesting” — your team and products become dependent on them. Updates to those dependencies become important topics of discussion as you decide if, why, and how to update your code to take advantage of the new version.
We want to help you take the next step in how you leverage open-source.
Introducing: Sibbell for Business
You can now install our GitHub integration directly onto your repos. Simply put a
.sibbell.yml file at the root of the project, and a new GitHub issue will be created when there’s a new release for any of the projects you specify.
The features we’re offering to start are intentionally simple. To us, simplicity has always been a major factor in why people like to use Sibbell. And while we do think there are some no-brainer ways to expand how our integration works, we want to take it step by step and make sure that any additional features are added for a good reason, not just because we can or because some other service does it.
The obvious questions you may have
Why just GitHub repositories?
For better or worse, a huge portion of open-source software still lives on GitHub. If you think about the dependencies that you would want notifications on, I’ll bet >90% live in a GitHub repo. That being said, we know that when it comes to installing a lot of these things, you use a package manager. And those package managers do not always reflect the “releases” in GitHub. But most of the time they do, and we want to make sure that we get the rest of the product right before we jump off the cliff of supporting every package management system, plugin directory, and git host under the sun. Oh, and because not everything is best installed through some package manager! Like Kubernetes, Terraform, Docker, etc.
Why not parse my requirements files?
- There are so many kinds. While it’s possible to add support for every file format in existence, it opens up a world of nuance (not to mention polling, scraping, webhooks and the like). And if Sibbell then doesn’t work with your “custom” setup, then you probably won’t use it. Instead we’re going to start simple. So simple that it it will work for anyone, guaranteed— a basic YAML file which specifies other GitHub repos.
- Despite there being so many ways to specify dependencies, not everything fits neatly into some requirements file.
- Do you actually want to be bugged about every single one of your dependencies? For some people the answer may be yes, and we applaud you! In our experience, that’s a lot of work, even if a service goes so far as to open a PR for you (see next question). So our approach, to start with, is to specify the ones that you actually care about and are the pillars of your app. Start by getting in the habit of actually dealing with the important updates, which you’re probably ignoring today, then go from there.
Sure, at some point we do hope to be able to automatically detect and intelligently help you keep track of and update everything you need. It would be great to have some tool that you immediately install on every project, with almost zero-configuration and instantly reap the benefits of having a no-hassle, 100% up-to-date, secure, and sustainable repo. In our opinion, nobody has gotten this right yet, because it ain’t easy.
Why doesn’t it create pull requests instead of issues?
Some services do this, and it definitely removes some steps! But what if:
- The update requires more than incrementing a pinned requirement version (if that is even a possibility).
- You don’t have some killer, comprehensive test suite which catches 100% of bugs, 150% of the time
- You merge one of those pull requests, only to break your product, and then realize that you didn’t actually take the time to comprehend the changes that were being made. Now you’re typing as fast as you can, sweating with headphones on and Slack notifications muted, desperately trying to recover while mumbling, “f*#$ing bots…”
Again, we want to start simple. We will create an issue, giving you as much information as we can about the new version. You (and your team) will consciously decide that it is an update you need to perform, and that you’re doing it in the best way possible. Then, together we will celebrate 🎉
If you have any feedback at all, we want to hear it. We deliberately removed features that we weren’t sure were on track with how people would want to use this, and have plenty of ideas of our own. Go to https://sibbell.com, install our GitHub integration, and let us know what you think!