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

51–60 of 64 posts

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

#51

Post by ckastner »

was_boring wrote: post #36
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.

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.

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

#52

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

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

#54

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

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

#55

Post by robbles »

CiPHPerCoder wrote: post #43
code_research wrote: post #38

Earlier quoted context omitted.

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.

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?

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.

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

#56

Post by discodave »

greggman wrote: post #54

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

Many ways to skin a cat.

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

#57

Post by ceslami »

greggman wrote: post #54

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

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.

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

#58

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

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

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

#60

Post by tomschlick »

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

What about /.bots or /.ci ? Those are specific to these types of services.
Post reply on HN