On Wed, Dec 4, 2013 at 2:54 PM, David Kemp <[email protected]> wrote:
> You can definitely do an automated build on demand, but the interesting > part is specifying exactly what to build. > Currently a build is made up of a bunch of repos at one tag, and some other > repos at another tag. > We would need to have a well defined way to specify which tag for each > repo. > > example: > I want to build cordova-android from the 'fancy-pants' branch, because I am > ready to push it to master > > I presumably need: > cordova-android - fancy-pants branch > cli,plugman,coho,mobilespec, js from master branch > all plugins from master branch > > If we can ALWAYS say that a demand build is the same as a master build, but > with one repo at a different branch that might be pretty easy... > +1 to this. I suspect we almost always want to test new feature against tip-of-tree (I guess thats master). So being able to run that but replace some of the repos with a different branch would be awesome. What if we used the convention of naming feature branches in all the applicable repos the same thing, that way we can poke CI with a single name and it would check out that branch on all the repos if it existed? > > > > > On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland <[email protected]> wrote: > > > On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill <[email protected]> > > wrote: > > > > > On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland <[email protected]> > > > wrote:> Dev becomes a staging branch, essentially; and all actual dev > > work > > > happens > > > > on branches. That sounds like a more sane way to do it. The only > > reason > > > I > > > > had it on dev in the first place was to be able to test with buildbot > > -- > > > > I'd love to have a way to run those branches through the CI server > > before > > > > merging them into dev/staging/master. > > > > > > > > > Good point. Maybe we standardize a third branch (ducks for cover) that > > the > > > CI server also tests and can be used for breaking dev work. This way > dev > > is > > > used for staging and only has code that can be released. I'm afraid > that > > > this just adds more complexity to plugins though and I am not a fan of > > > adding more complexity. > > > > > > > I was thinking that it would be cool to be able to force a buildbot build > > of a specific branch (though maybe a set of branches would be required) > -- > > it wouldn't have to happen with every commit, but you could say "I'm > ready > > to merge my feature into dev, let's get buildbot to run all of the tests > on > > that branch first, to see if the merge will break anything". > > > > That would avoid the need for a third special branch, but would let > anybody > > with access to buildbot (which we hope is everybody, soon) the ability to > > test a branch before merging. > > > > I don't know if it's possible to get buildbot to do that or not; I'll > defer > > to David on that subject :) > > > > Ian > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > Still confusing at times. It will be > > > > > nice once we can get away from this dev-master setup we have. I'm > > sure > > > > many > > > > > of us have pushed code to dev that isn't in a sate to be released. > > > Maybe > > > > > this point/process should get added to our wiki? Not sure where the > > > best > > > > > place for it would be. > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland < > [email protected]> > > > > > wrote: > > > > > > > > > > > Hey Steven, > > > > > > > > > > > > File is close to being ready, but I haven't merged in my Android > > code > > > > > yet, > > > > > > and I want to add some more tests, given how critical the plugin > > is. > > > > I'm > > > > > > not comfortable with it going to master yet. If you want, I can > > pull > > > it > > > > > out > > > > > > of dev and put it on another branch. (There have been some other > > > > commits, > > > > > > so we could also create a new branch without those commits, and > > merge > > > > > > *that* into master instead) > > > > > > > > > > > > Let me know how you want to handle it, I'll help out any way I > can. > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Any plugin issues I should know about before releasing today? > > > > > > > > > > > > > > Last I heard file and file-transfer dev branches aren't ready > to > > be > > > > > > merged > > > > > > > into master. Has this changed? Ian? > > > > > > > > > > > > > > Plugin issues that are still being reviewed/worked on: > > > > > > > https://issues.apache.org/jira/browse/CB-5525 > > > > > > > https://issues.apache.org/jira/browse/CB-5531 > > > > > > > https://issues.apache.org/jira/browse/CB-5532 > > > > > > > https://issues.apache.org/jira/browse/CB-5430 > > > > > > > https://issues.apache.org/jira/browse/CB-5504 > > > > > > > https://issues.apache.org/jira/browse/CB-5505 > > > > > > > > > > > > > > I can wait until later in the day to release if some of these > are > > > > > getting > > > > > > > resolve today. I know Jesse is looking at the windows ones. > > > > > > > > > > > > > > We can also just do another plugin release next week (or post > > > > holidays) > > > > > > > once some of these land. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
