41–50 of 64 posts
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.
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.
Earlier quoted context omitted.
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.
I'd prefer .well-known since there's already an RFC for it, but maybe .dev-extra would be more appropriate?
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’ve been working on Dependency CI along with 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.co…
Earlier quoted context omitted.
I've thought of the same thing, but I feel that the horse has well and truly bolted, run back through the barn a few times, kicked some shelving over and then continued out the front and over the horizon at a brisk pace.
The ideal solution is a migration path; retain support for config in project root, but check a configuration directory first.
Great idea! Would love also MVP version of that which help you pick better dependencies.
I’ve been working on Dependency CI along with 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.co…
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 :))
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.
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?