Great to see the NuGet "ecosystem" getting features that are similar to the openwrap development workflow, I'd love for some of this wonderful work to also find its way on our OSS project too...
Conflicts of interests and all that. ________________________________ From: [email protected] [[email protected]] on behalf of Rafael Teixeira [[email protected]] Sent: 21 September 2011 13:42 To: [email protected] Subject: Re: New repos structure https://github.com/monoman/NugetCracker NugetCracker currrently doesn't have any specific support for teamcity, but it can weave the web of packages dependencies, including test-projects (unit or acceptance), and just yesterday I commited the Nugetify command to easy converting libs to nugets with automatic promotion of project references to nuget references. The scenario NugetCracker supports is, checkout all repos side-to-side in a build-working dir, fire NugetCracker which scans all directories (one can configure some subtree exclusions), finds all dependencies, issue commands to nugetify, bumpversion (with cascading), rebuild. Currently it supports a single command line direct command, and multiple commands in the interactive shell, but it is easy to add support for a response file, to script multiple commands, or a add a more complex feature: a smartbuild command to figure out changes and versioning-policies to build the whole-set of projects. By default it publishes packages to a local folder that can them be published on success to the intended feed, publishing individual packages to the feed on partial success doesn't seem like a healthy way to do it, as you aren't sure the changes won't break upper layers (test coverage in the lower layers and semantic changes on contracts may have updated unit tests that won't warn of the consequences on the consumer layers). Selling my fish, I know. But if NugetCracker can help Castle, besides helping my own nightmarish development of a distributed system with 160+ projects, and I think it can, I'd be happy. Regards, Rafael "Monoman" Teixeira --------------------------------------- "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" Isaac Asimov US science fiction novelist & scholar (1920 - 1992) On Tue, Sep 20, 2011 at 1:44 PM, Markus Zywitza <[email protected]<mailto:[email protected]>> wrote: Is this for building all-trunk-versions? Then there is an alternative. If we configure the projects to use binary dependencies as NuGet-packages, we could set up teamcity in the following way: Castle.Core -triggered by source code changes -build and test -publishes NuGet package to all-trunk-nuget-feed on buildserver Castle.Windsor (default) -triggered by source code changes -build and test -publishes NuGet package to all-trunk-nuget-feed on buildserver Castle.Windsor (all-trunk) -triggered by source code changes -triggered NuGet package change in all-trunk-nuget-feed on buildserver -build and test -publishes NuGet package to all-trunk-nuget-feed on buildserver And so on for the other projects. That way, it is clear when changes cause a failure in other projects builds and allows to fix it by cloning the source repository in a separate folder and update all NuGet packages using the all-trunks feed. Bleeding edge users can use the all-trunk feed for their regular development without building themselves. With a high test coverage, this feed could be even sort of "supported". -Markus 2011/9/20 G. Richard Bellamy <[email protected]<mailto:[email protected]>> I'm wondering if there's anything I can do to help with the repo restructuring? The last I heard, hammett was looking for help with filter-branch so he could move each repo into a single folder depth, and reduce the log to a near date (last commit). Ayende had also suggested subtree merges to help us deal with an aggregate project with multiple repos as sub-directories. -rb -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]<mailto:[email protected]>. To unsubscribe from this group, send email to [email protected]<mailto:castle-project-devel%[email protected]>. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]<mailto:[email protected]>. To unsubscribe from this group, send email to [email protected]<mailto:castle-project-devel%[email protected]>. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
