
Show HN: Dependency CI – Continuous testing for your dependencies - andrewnez
https://dependencyci.com
======
code_research
This is a very interesting service, thank you!

May I ask you for some little thing that might change the (development) world?
Would you _please_ like to introduce a folder, where people might put their
dependency.yml file - this is an effort to finally stop the spreading cancer
of "put one more config file into the project root".

I would like to suggest to call that folder simply "config" \- all the
projects and tools out there should have no problem with that. Optionally
there could be _one_ top level config file called "config.rc" \- this file
points to the actual config dir if it is not "config".

It would be verrry nice if one service just starts with that and hopefully all
the others will follow and it will become a defacto standard. The pollution of
the top level project directories really must stop.

Thank you!

~~~
andrewnez
Agreed, I'll definitely the ability to move your dependencyci.yml file into a
.github folder like the issue and pull request templates:
[https://github.com/blog/2111-issue-and-pull-request-
template...](https://github.com/blog/2111-issue-and-pull-request-templates)

~~~
Sir_Cmpwn
How about .meta? Hopefully we can encourage github to support this, too. Maybe
.meta/github/ could be a thing, too.

~~~
code_research
In the config.rc file you could call that folder however you want.

I personally do not like ".meta", because it is not clear what kind of
information it may contain. "Meta" might be anything, documentation,
description, website, design papers, everything is meta. It is a bit like
using "Information" as a menu entry for a website.

~~~
CiPHPerCoder
It sounds like we should probably all get together and write a draft RFC for
this. Choosing a good directory to toss everything into would be grand.

I'd prefer .well-known since there's already an RFC for it, but maybe .dev-
extra would be more appropriate?

~~~
robbles
Do you really want to type either of those prefixes thousands of times?
Brevity and lack of special chars in the name would be nice to have.

------
andrewnez
I’ve been working on Dependency CI along with
[https://libraries.io](https://libraries.io), the service that powers it, in
my spare time for the past few months, it’s great to finally get it out into
the real world.

Dependency CI works like Travis CI but for the dependencies of your
application, checking them for license and status issues every time you push
to GitHub.

I've written a up a post on medium with more details:
[https://medium.com/@teabass/introducing-dependency-
ci-e859fa...](https://medium.com/@teabass/introducing-dependency-
ci-e859fa138eb6)

It’s 100% free for open source projects and there’s a 14 day free trial for
checking private github repositories too.

~~~
dom96
Hey, Nimble creator here. Just wanted to ask, are there any reasons why it's
not currently supported on Dependency CI? (apart from just lack of time on
your side :))

~~~
andrewnez
Hey Dom, it's mostly because I've not written a parser for the .nimble
manifest file, if you feel like adding it to
[https://github.com/librariesio/bibliothecary](https://github.com/librariesio/bibliothecary)
then it will be easy to add support for it!

------
tombh
I've known Andrew for a few years and what I love about this is how it
reflects him as person: someone who loves bringing people together. Dependency
CI seems to me to be a manifestation of that. Hopefully one effect of
Dependency CI, if (when) it becomes popular is that it raises the bar for the
stability of projects that other people depend on. We're all in this together.
Keep up the great and inspiring work Andrew!

------
jvehent
Similar to Greenkeeper or requires.io, but with a larger range of languages
supported. Very interesting.

As a side note, I recommend creating a separate github account when granting
permission to this kind of 3rd party. Don't grant them full read/write on your
repos, create an account that's temporarily admin, then make that account read
only.

------
ckastner
The Debian project's Continuous Integration project [1] re-tests all dependent
objects whenever a dependency within the Debian archive changes. This way,
changes that might negatively affect dependents can be caught early.

This is immensely useful, especially to the maintainers of libraries.

In order for them to be tested, dependent objects have to declare their
testability using the autopkgtest [2] interface.

[1] [https://ci.debian.net/](https://ci.debian.net/)

[2]
[https://people.debian.org/~mpitt/autopkgtest/README.package-...](https://people.debian.org/~mpitt/autopkgtest/README.package-
tests.html)

~~~
was_boring
I was hoping that this would be a similar service, but it doesn't appear to
be.

~~~
ckastner
It appears to me that Dependency CI is focused on dependency metadata,
focusing on the state/version/license/etc the dependency declares.

Debian's CI focuses on actual run-time testing, specifically what it calls
"as-installed" testing (as opposed to build-time testing). You don't test a
specific build result, but whatever is installed in $PATH, $LD_LIBRARY_PATH,
and so on.

Because the tested objects also use the as-installed dependencies --
libraries, modules, etc. -- whenever one of the dependencies changes, the
dependents can automatically be re-tested for compatibility.

------
michaelmior
There are plenty of other services in this space (see below for a couple). I
hadn't heard of Dependency CI and what immediately impresses me is the number
of different package managers supported.

[https://gemnasium.com/](https://gemnasium.com/)

[https://www.versioneye.com/](https://www.versioneye.com/)

------
insomniacity
OP- Do you have a roadmap to supporting this outside of GitHub? I think the
people that benefit most from it, due to corporate policies and outdated deps,
are the people least likely to be using GitHub!

Everyone else - Is this a general problem with people locking these (very
cool) tools to GitHub? Is there a generalised solution to the problem of
source control integration?

~~~
yellowsir
its bad decision making. but to be fair dependency ci will add gitlab and
bitbucket in the future. it still sucks that awesome tools like this are
github first, git is a central tool and tools arround git should not depend on
any hoster at all - imho

~~~
tomstuart
What alternative decision are you imagining? A service like this can’t depend
on Git alone. It needs to know when the repo is updated (e.g. GitHub’s
webhooks) and has to publish its results somewhere (e.g. GitHub’s commit
statuses). So it only really works with hosted repos.

Since each hosting service has a different API, each integration needs to be
built individually. And it makes sense to integrate with GitHub first because
it’s the most popular repo host.

~~~
insomniacity
It's the most popular repo host on HN for sure, but think about all the
private repos behind corporate firewalls etc!

~~~
happyslobro
Some of which are Github Enterprise :p

------
Mizza
For JavaScript and Python developers, there is a newish service called Doppins
(from Norway!) that I've really been enjoying for my open source projects:
[https://doppins.com/](https://doppins.com/)

No conf required other than your normal requirements.txt, sends you a PR
whenever there are new versions available. Cracking stuff.

------
eisokant
Having gotten to know Andrew a bit over the last few months, I can
wholeheartedly say that he cares a lot about the open source community.
DependencyCI and Libraries.io are labours of love and craftsmanship!

------
SlashmanX
Great work on this, looks very useful. Does it only work with GitHub? Would
love to have this for my private GitLab instance

~~~
andybak
Yep. Same for Bitbucket. Or just support all git repos that are accessible via
the public internet.

Github's pricing model means that lots of people can't use it for private
repos - 'per repo' pricing isn't fun if you prefer lots of small repos.

~~~
hamandcheese
Github changed their pricing model to per user pricing with unlimited private
repos:

[https://github.com/pricing](https://github.com/pricing)

------
didymospl
Great idea! My company requires external libraries licenses to be revieved
every half a year and it usually takes a couple of days to do so. Your project
could be a real time-saver. Unfortunately the integration with Maven does not
seem to work in most cases, if it did I would already have sent the link to
our CTO.

~~~
reiz
You could use the VersionEye Maven Plugin for that:
[https://github.com/versioneye/versioneye_maven_plugin](https://github.com/versioneye/versioneye_maven_plugin).
It checks your dependencies against a license whitelist on the VersionEye
server and if there is a violation it breaks your build on your CI server.
That way you can enforce a license policy continuously. It's much better than
just checking licenses once a year ;-)

I'm working on VersionEye since a couple years, it's a similar project and I
open sourced it last week: [https://blog.versioneye.com/2016/06/28/versioneye-
goes-open-...](https://blog.versioneye.com/2016/06/28/versioneye-goes-open-
source/). I'm following Andrews activities since a while and like what he did
with libraries.io. Great job! As both projects have a big overlap and are open
source now I'm open for collaboration :)

------
greggman
Isn't this the actually the wrong solution? I thought I was told I should be
pulling my dependencies into my own cloned repos. Then my project uses my
clones. When I want an update I test it out, update the cloned repo and update
the project to use the latest tag/hash of my cloned repo. Isn't that what
pretty much all the top projects do?

This way everything is under my control. What good is it if I'm told my
dependencies has been deleted? And then I what? Copy my old dep from my dev
machine to a cloned repo and point to that? Isn't that the same step as above?

Or maybe I just don't get it.

~~~
ceslami
You're not wrong, but you can use that technique and benefit from Dependency
CI too.

Typically, you can define your dependencies in a file specific to a certain
package manager. NPM uses `package.json`, RubyGems uses `Gemfile`, etc.

It is a reasonable practice to "vendor in" your dependencies, as you suggest.
But given the declaration of your dependencies in some manifest file,
Dependency CI can give you valuable insights.

------
wiremine
Cool concept! Is the spec for the dependency.yml file open source? Would be
cool to see something like it become a standard: it's a concern for the
project owner, but also for the project clients/users.

~~~
andrewnez
It's in the works, very little documentation at the moment:
[https://github.com/dependencyci/dotyaml](https://github.com/dependencyci/dotyaml)

------
sethd
What would be really interesting is a service that would tell me the build
status and code coverage metrics for each version of a dependency I use in my
project (and each dependency they use their projects and so on).

Even more interesting would be something that would attempt to force code
coverage analysis on projects that use a standard testing framework, have a
certain amount of tests present, but don't have CC configured in their
project.

At first I was thinking that is what this service did but it doesn't appear to
be the case.

------
musha68k
There's also a somewhat similar service a friend and myself evaluated a couple
of months ago, we had similar ideas but we eventually let go of our prototype
because of "fear" of said competition ...

DepdendencyCI already did better than us in that regard and it seems like they
are doing an an all-around great job (I especially like the multi language
support)! :)

 _Hattip_ to the team!

------
RichWalton
I added my project and the service claims it has 0 dependencies (Listed in the
build.gradle file).

Bug?

[https://dependencyci.com/github/RichTeaLang/RichTea](https://dependencyci.com/github/RichTeaLang/RichTea)

~~~
andrewnez
Will investigate that for you shortly, I've only just added support for
gradle, might be skipping some sections of file

------
machbio
For python developers - why does not any CI out there support Conda - out of
the box.. :(

------
ericcholis
Very interesting, but I can't seem to sign up for the trial to use on private
repositories.

------
jakozaur
Great idea! Would love also MVP version of that which help you pick better
dependencies.

~~~
royka118
Thats the authors other project libraries.io :)

------
swalsh
This would be super useful for making sure left-pad is still functioning.

------
Pirate-of-SV
Would be cool if it could support Puppet modules.

------
benjamuk
Very proud of Andrew's tenacity and ability to offer a simple solution to a
problem that strengthens the open source community rather than ruminating
and/or grand standing about it.

