Hi Christian, If I may make a suggestion about the technology, consider TeamCity instead of CCnet for continuous integration. It supports Mono on both Linux and Windows, has an excellent UI and many great features. I've used it (though on MS .NET, not on Mono) and found it an excellent tool. There is a free edition which should be more than enough for this project.
http://www.jetbrains.com/teamcity/index.html Regards, Evgeny Christian M. Jensen wrote: > Thanks for the brain dump. > > I have started the gears rolling over on this side of the fence. It may > be a bit as this is a corporate timescale I am working with - I am on > board though. > > Even though you may not hear from me for a week or so do not think for a > moment that I am not on top of my commitment - I am the architect and my > focus is not always that of a laser but I do get the job done. > > When I am ready to pull the trigger, I don't want to be the build master > but rather a progenitor of the system - meaning I will pave the way, but > all the other developers need to march on it. > > So, with that said, when the systems goes live, I will have (barring any > concerns in choices) two servers (1 Linux, 1 Windows) that you can point > to. These servers will: > * Watch the SVN server for any changes to the build configuration > * Update itself with any new build configuration scripts > * Watch the SVN server for any referenced projects > * Build any changed projects > * Run any unit tests > * Create distributions > > My Technology choices that I can see are: > * CCnet > * Nant > * NUnit > * NCover > * NDoc (or better) > * Anything else that runs on Linux and Windows > > The general idea is to be able to make a build configuration that will > execute the same on windows as well as Linux (mono) - I have never done > it so I might be speaking the impossible but I would at least like to > try. I expect that I cannot as I doubt MSBuild is available in Mono. > > These machines will either be at my office on our huge pipes or at my > house on a decent cable modem - either way, it will be done. > > Thanks for all the hard work thus far! > > Christian > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Jonathan Pryor > Sent: Sunday, October 18, 2009 7:30 AM > To: [email protected] > Subject: [dblinq] Re: Error compiling r1237 in VS2008 from fresh SVN > > > On Sat, 2009-10-17 at 23:10 -0700, Christian Jensen wrote: > >> The first question I have is - am I in the right place? >> > > Yes, this is the right place. > > >> There is mention of this being integrated into Mono - should I be >> > there? > > Mono has a copy of DbLinq to implement System.Data.Linq.dll. DbLinq > (this project) is the "upstream" (main) project. > > >> If I am in the right place then I need to make a comment - I am unable >> to get the project to build. >> > > Erickson Qua committed a fix for this (as I'm sure you've seen). > > I committed a more appropriate fix in r1239. > > >> There is a reference to an object type that is not of the correct >> visibility. In namespace DbLinq.Firebird the class FirebirdSqlProvider >> in the method GetTranslator() the "New" is trying to create a type of >> "FirebirdExpressionTranslator" which cannot be seen as it has not >> visibility declaration. >> > > Actually, the problem was that FirebirdExpressionTranslator.cs wasn't in > the System.Data.Linq project, and thus the type didn't exist. > > >> I have a cruise control server I can drop this project onto and allow >> public access - this might help out with this sort of error. >> > > I'm sure that would be appreciated. > > >> I would love to investigate this project further and even contribute >> but need some guidance - how much help do you need if any and how can >> I help. >> > > We need lots of help. :-) > > In addition to a continuous integration server (which you've gracefully > offered), we also need developers to "take care of" databases. > > For example, we have hundreds of tests. Not all tests pass under all > databases. (In fact, not all tests pass for any database, period.) > Some (read: me) find this very difficult to fix a given test case when > there's no way to easily know if any other tests were broken, as the > test suites are never "green." > > The solution we've chosen so far is to annotate known-failures with > NUnit's [Explicit] attribute for *release* builds. This allows us to > take the Release unit test build and have the known-failures > automatically skipped, so release test runs can actually be green. We > do this with some #if logic, e.g.: > > #if !DEBUG && (MSSQL && !L2SQL) > [Explicit] > #endif > > This test says that for release builds (!DEBUG) and DbLinq's Microsoft > SQL Server support (MSSQL && !L2SQL -- L2SQL is defined when building > tests against Microsoft's Linq-to-SQL provider), the test should be > skipped. Meanwhile, SQLite executes this test without error. > > The problem is that the known-failures vary for each DB, and we don't > want to skip all known-failures across all DB's (as with the above test, > we don't want SQLite to regress), so this is effectively a tax on > developers. > > Furthermore, not all developers have access to all databases. For > example, I only have access to SQLite and SQL Server Express. > Consequently I have no way of knowing which tests are known failures > under PostgreSQL, Firebird, Oracle, etc. > > So as part of a continuous integration server, you would need to do two > things: > > 1. Decide which databases you want to test. At minimum this should > include SQLite (as it runs everywhere). > 2. For the databases chosen from (1), make sure that there aren't any > failing tests. > > You can find database configuration instructions at: > > http://groups.google.com/group/dblinq/web/unit-tests > > Thanks, > - Jon > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" 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/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
