Is it worthwhile to look at octokit and writing a dev tool replacement in Ruby? Octokit is the github supported Ruby toolkit for the github API.
https://github.com/octokit/octokit.rb Thanks, dp From: crowbar-bounces On Behalf Of Victor Lowther Sent: Friday, January 03, 2014 10:49 AM To: Adam Spiers Cc: crowbar Subject: Re: [Crowbar] Resolving inter-repository dependencies for CB 2.0 On Fri, Jan 3, 2014 at 8:52 AM, Adam Spiers <aspi...@suse.com<mailto:aspi...@suse.com>> wrote: Victor Lowther (victor.lowt...@gmail.com<mailto:victor.lowt...@gmail.com>) wrote: > On Fri, Jan 3, 2014 at 5:33 AM, Adam Spiers > <aspi...@suse.com<mailto:aspi...@suse.com>> wrote: > > Victor Lowther (victor.lowt...@gmail.com<mailto:victor.lowt...@gmail.com>) > > wrote: > > > This is intended to work as a starting point for a discussion of what tool > > > we should use to use to track inter-repository dependencies for CB2.0 in > > > the opencrowbar org. > > > > Before evaluating the tools I think it would be worth trying to > > clarify the requirements. For example, all the approaches you list > > seem to assume that there will only be dependencies from a single > > superproject repository onto multiple slave repositories, but why is > > it safe to exclude the possible need to track dependencies between > > slave repositories? > > Then you are assuming too much. None of the tools I mentioned enforce such > a relationship between git repositories OK, maybe I didn't express myself clearly enough then, or maybe we are talking about different types of dependencies. I assumed that by "inter-repository dependencies" you were talking about dependencies at the version control layer, e.g. one of the following: - "commit X in repository A requires commit Y in repository B" - "commit X in repository A requires commit Y or newer in repository B" - "branch X in repository A requires commit Y in repository B" - "branch X in repository A requires commit Y or newer in repository B" - "tag X in repository A requires commit Y in repository B" - "tag X in repository A requires commit Y or newer in repository B" - "commit X in repository A requires branch Y in repository B" - "branch X in repository A requires branch Y in repository B" - "tag X in repository A requires branch Y in repository B" - "commit X in repository A requires tag Y in repository B" - "branch X in repository A requires tag Y in repository B" - "tag X in repository A requires tag Y in repository B" (Probably not all of these would be useful, but I'm just listing them now for clarity, to help us avoid talking at cross-purposes.) These types of dependencies are obviously very different in nature to the crowbar.yml types of dependencies such as "barclamp-nova requires barclamp-keystone". So are you talking about the first type of dependency or the second, or both, or something else? The first type of dependency. However, that all the tools express their relations in terms of parent/child relationships does not mean that we are restricted to a one superproject -> many subprojects structure -- I am leaning towards a one-superproject-per-release structure myself, and the superprojects would pick and choose whatever subset of the slaves were appropriate. With regards to the first type of dependency listed above (i.e. version control layer): ./dev, git submodule, and git subtree, and gitslave *all* assume a topology which involves a single parent repository and one or more child repositories. I'm not sure about gitslave, but for the other three, version control layer dependencies can only be expressed from the parent ("superproject" as gitslave calls it) onto children (e.g. to define a "snapshot" representing a particular release), not between children. So my question was: is this limitation safe, or might it get in the way later on? The answer may well be "yes, it's safe"; I just wanted to raise awareness that adoption of any of the tools you proposed will impose that limitation. That is an area I would like to discuss -- what sort of restrictions are we willing to live with here? > > What do these repositories contain? > > Source code, docs, and metadata. > > > Multiple barclamps in the superproject and one per slave? > > Doesn't matter for the purposes of this conversation. It does, because ./dev currently assumes no barclamps in the superproject and one per slave whereas the other tools you proposed don't, so if you want to achieve something different to the current layout then that will certainly impact the decision whether to continue using ./dev or not. Or splitting ./dev into several smaller tools, one of which would be the bit that handles git repo interdependencies. > > Where do tools live? > > Wherever we want them to. Will the superproject be release-specific or not? Development of ./dev and its associated files was held back by the fear of breaking reproducible builds for older releases. But then keeping any future repository "meta" tool in a separate repository to the build toolchain should alleviate this problem. One of the things I am interested in talking about. > > I have a strong preference for reusing existing technology over > > rolling custom tools. For example, packaging barclamps as gems would > > provide the functionality of the whole gem/bundler ecosystem for free, > > which AFAICS would in one stroke solve the whole problem. > > I don't see how introducing a packaging conversation here is useful, unless > you prefer downloading a gem over cloning a repo when you want to hack on > some random ruby project (as opposed to just using it) Yes, I *hugely* prefer that - that's the whole point! If dependencies are available as gems then this whole discussion becomes a non-issue. Example advantages: - Any barclamp repo could easily be unit-tested standalone in Travis simply by ensuring its Gemfile expressed the right dependencies (e.g. on the core framework and barclamp gems), rather than the awful https://github.com/crowbar/travis-ci-crowbar tree flattening hack we were forced to build previously, which was never able to automatically test pull requests. - Dependencies could be expressed using version numbers adhering to semantic versioning, which gives much more flexibility during testing than a monolithic approach which insists git cloning an exact set of commits/branches/tags from a set of remotes chosen by an opinionated tool. - Doesn't reinvent any wheels. - Proven technology already adopted by the whole Ruby community. - Everyone already knows bundler / Gemfile etc. very well => very shallow learning curve => more welcoming for newbies OK. Packaging and dependency handling are NOT mutually orthogonal problems. True, but I wish to focus on dependencies at the VCS level for the purposes of this conversation, not the packaging level. If you want to do otherwise, please start a new thread.
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
