Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Dependency CI – Continuous testing for your dependencies

dependencyci.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#31

Post by Sir_Cmpwn »

andrewnez wrote: post #21
code_research wrote: post #5

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 o…

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...

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

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#32

Post by yellowsir »

insomniacity wrote: post #27

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?

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

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#33

Post by tomstuart »

yellowsir wrote: post #32
insomniacity wrote: post #27

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?

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

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.

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#34

Post by 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!

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#35

Post by 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://www.versioneye.com/

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#36

Post by was_boring »

ckastner wrote: post #14

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] ht…

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

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#38

Post by code_research »

Sir_Cmpwn wrote: post #31
andrewnez wrote: post #21

Earlier quoted context omitted.

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...

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

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.

Re: Show HN: Dependency CI – Continuous testing for your dependencies

#39

Post by insomniacity »

tomstuart wrote: post #33
yellowsir wrote: post #32

Earlier quoted context omitted.

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

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 fir…

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