on Wed Feb 29 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Dave Abrahams wrote:
on Tue Feb 28 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Dave Abrahams wrote:
on Wed Feb 08 2012, Daniel James <dnljms-AT-gmail.com> wrote:
The problem that we face with something like gitflow is testing. [...]
The way we plan to handle this with Ryppl is that you check in a testing specification with your project. The testing specification is just a text file, something like this JSON:
[...]
Where you can request multiple configurations to be tested for commits on each branch. To get your in-development work tested, just publish a feature branch containing a test specification file to your public repository.
The test results are then added to the commit using git notes.
How does this approach compare to the one discussed in http://lists.boost.org/Archives/boost/2012/02/190418.php ?
The message above seems to be (mostly) describing a mechanism for automatically merging feature branches. As far as I can tell, the approaches are apples and oranges, and thus are basically compatible. We do something like that at Boostpro for handling upstream merges to Clang.
I'm not sure whether this is correct. The script I outlined does involve a git merge, but it's only a temporary one in the working directory that will be reset afterwards. The purpose of the script is not to merge (in fact the intent is to leave all branches unchanged) but to provide a transparent image to the testing volunteer, which includes exactly one branch of each Boost library.
Sorry, I don't understand what you mean by a "transparent image."
So my impression is that the planned Ryppl testing model and the testing model concept from the thread in the Boost archives do have similar goals, i.e. to automate testing of heterogeneous selections of branches from the various libraries. After some more thought I suspect the planned approach from Ryppl is superior, though. :-)
Why do you think that? (you give up pretty easily!)
There's one important thing about the git-flow model that I'm not sure you've accounted for, though: on feature branches, completely broken commits are de-rigeur.
I was aware of that; the idea would be that a library developer pushes the feature branch to be tested to the public repository when the last commit on that branch is expected to be stable, then waits until it's tested before pushing again. After all, the developer isn't interested in testing completely broken commits. I think this is the same thing that the planned Ryppl approach aims to accomodate for by listing the exact commits to be tested.
Well, you don't need to list "exact commits". A tree-ish could be a branch name, so every change on that branch gets tested. I suppose that if you're checking in known-broken work it might make sense to have a special notation in the commit message that would prevent that commit from being tested when it appears on a feature branch. -- Dave Abrahams BoostPro Computing http://www.boostpro.com