How can I retain compiler warnings in Hudson (CI) when using SVN Update?

views:

answers:

+1 Q:

How can I retain compiler warnings in Hudson (CI) when using SVN Update?

I've got a continuous integration setup using Hudson and lately I've configured the jobs to use svn update to get the latest version of the code. I really like this approach since it allows msbuild to version appropriately and only build the effected assemblies.

However, I've noticed that since I'm not doing a build of all the assemblies again, I loose all of the compiler warnings for those assemblies if they aren't built.

For example, if I have 3 assemblies with dependencies demonstrated via indenting:

Assembly 1 10 warnings
- Assembly 2 (Depends on 1) 10 warnings
  - Assembly 3 (Depends on 2) 10 warnings

The first build will build all 3 assemblies and log 30 warnings.

Next build, if I only change Assembly 3, Hudson will only build Assembly 3 and I will only get 10 warnings for that build, effectively marking 20 warnings as "fixed".

As far as I can tell, there isn't going to be any way around this, but I would love to know if anyone has configured Hudson to retain these compiler warnings from one build to another.

Edit: Yes I realize that this can turn into a debate of "you should / shouldn't be doing an update on a CI box", but there are reasons we went with the update approach.

Its roughly 3x faster
We're still producing the most up to date assemblies
msbuild can version the assemblies appropriately.

You do the continuous integration to see how one assembly interferes the other assemblies. So if they have dependencies you should build all. If they don't have dependencies at all, create one job per assembly (in your case 3).

The version you describe is not a full build it is only an update build and should be done on the developers machine.

EDIT: Versioning Issue

You can configure Hudson (in connection with SVN) to ignore commits by certain users. Using this black list, there should be no issue with msbuild doing the versioning.

Peter Schuetze 2010-07-14 19:09:48

Right, we're doing an update build by design because there is no need to rebuild assemblies that haven't changed. The individual developers do update builds and complete rebuilds as they need. I think you will have a hard time arguing that CI builds should not be update builds (in case you're alluding to that). Plus, by doing an update, we allow msbuild to handle the versioning as discussed here: http://stackoverflow.com/questions/1126880/how-can-i-auto-increment-the-c-assembly-version-via-our-ci-platform-hudson

Allen 2010-07-14 19:14:28

I edited the question to indicate that those 3 assemblies are related

Allen 2010-07-14 19:20:05

My definition of related is, that if an upstream project changes, it might result in breaking the build of the downstream projects. Therefore a complete build is necessary. If that is not the case than they are independent.

Peter Schuetze 2010-07-15 13:29:10

@peter, yeah see, msbuild is intelligent enough to understand that and therefore build all downstream projects... In my example, if I changed Assembly 2, then msbuild would build Assemblies 2 AND 3. Thats why automatic versioning (1.0.*) is so sexy because it will keep unchanged assemblies at the correct version and automatically increment the version for ALL affected assemblies

Allen 2010-07-15 15:22:20

You just have more trust in technology than I have. ;)

Peter Schuetze 2010-07-15 16:08:02

I would change your approach to a CI build. Doing an incremental build on a build machine is very misleading, and only of marginal value (IMHO) and unless your system is the size of an operating system you are probably not saving yourself much time.

If you have assemblies which do not change often or ever, package them away as "third party" dependencies (maybe even in a merge module so your deployment can pick them up easily) and don't rebuild them with your CI.

On the other hand, if all your assemblies are volatile (need to be rebuilt more than once in a release cycle) build them all, all the time.

dkackman 2010-07-14 19:15:43

In what way is it misleading? My CI box will still be building and producing the most up to date versions of the assemblies.Also, doing an update vs a complete wipe took our 50-75 assembly build from 15+ minutes down to an average of 2-3 minutes so it is worth it to us.

Allen 2010-07-14 19:22:21

Maybe I'm too conservative but I don't trust anything that isn't a clean build. Incremental builds can hide subtle things like the introduction of circular dependencies that would break a clean build. But yeah 15+ down to 2-3 minutes does change the equation.

dkackman 2010-07-14 20:23:00

I agree with dkackman about the trust, but not necessarily about the big change in the equation.

Peter Schuetze 2010-07-15 13:26:06

@dkackman, maybe I haven't described this properly or how properly done incremental builds work.I have a solution with 50+ projects. Msbuild is building the solution. References are done by project (not by assembled dll). If a change is committed to code in any given project then msbuild is intelligent enough to build every assembly that references the changed one. There is no way (in the above scenario) that you can slip a bug or a circular dependency into the mix that would have otherwise been caught by a fully clean-slate build

Allen 2010-07-15 15:14:32

@Allen - At 50+ projects per solution I would start looking at breaking projects down into more granular layers where every layer has: 1 solution, 1 CI, 1 production build, 1 merge module (assuming you're using MSI). I personally do not like the "One solution to rule them and in darkness bind them" approach to managing a large system.

dkackman 2010-07-15 15:32:41

In the early 2000's, MSDN recommended this approach up to 75-100 projects and that has no doubt grown. Having 1 solution per project isn' necessary because you can point msbuild at projects as well as solutions, so you could achieve the same result with the preexisting infrastructure. You may want to read "Structuring Solutions and Projects": http://msdn.microsoft.com/en-us/library/ee817674.aspx they specifically say "Use a Single Solution Model Whenever Possible, Use a Multi-Solution Model Only if Absolutely Necessary"

Allen 2010-07-15 15:59:32

Oh I don't advocate 1 solution per project! I go with 1 solution per layer/tier or package (a package being 1-n assemblies that are tightly coupled around function). I frankly disagree with the recommendation to favor 1 solution. It may be easier in some respects but also lends itself to tightly coupled poorly cohesive system architecture. In short I like the solution structure to mirror the system architecture. If you buy that, 1 solution implies ill defined system architecture.

dkackman 2010-07-15 16:17:34

We (and MSDN) do it for the functionality, not the ease of use. I fail to see how 1 solution lends to tightly coupled poorly cohesive system architecture. Its just a tool, how you architect and use it will determine what the result is, moreso than your tooling. Maybe if you could offer up a benefit of your way you could sway me, but so far you've only said "I don't do it that way, doing it that way MAY lead to xyz". I can see how you think organizing your solutions in a certain manner helps you keep things logically situated but thats what solution folders, projects and namespaces are for.

Allen 2010-07-15 16:54:09

... continued. Honestly, when I think about architecture and loose coupling, I'm never saying "Damn, if I just had multiple solution files, I could have this much looser and have vastly superior architecture".

Allen 2010-07-15 16:55:14

There is no single silver bullet approach to this sort of SCM, and a single solution can and does work. In my experience, large single solution systems have been monolithic and exhibit many of the attributes of the big ball of mud http://www.laputan.org/mud/. Separate solutions introduce structural, rather than procedural/conventional separation between layers, allowing for better isolation over time, especially in reference to the section in the above about shearing layers. The structural separation puts a hurdle to violating the type architecture in front of the developer.

dkackman 2010-07-16 13:00:13

And the reason I say MAY and TEND and things like that is because every system can start with a decent architecture. The single solution approach makes the erosion of that architecture, which will happen, happen quicker as it puts the onus on the developer to maintain its constraints, not on the structure of the system. (and we all know that us developers are lazy bastards :))

dkackman 2010-07-16 13:04:37

PS: this is kinda like having a debate via twitter. Make your point in 600 characters or less. Go!

dkackman 2010-07-16 13:41:40

Well, msbuild is doing what it should be doing: Its only logging the warnings that it encountered.

If you must use svn update, the only way would be to somehow:

parse the build log and determine what assemblies were not built
foreach unbuilt assembly
- look up the warnings for the last time that particular assembly was built
- manually carry those warnings forward, into the current build.

It may / may not be unwieldy and it would have to have a decent understanding of the msbuild log format.

One could also argue that it is misleading since you'd be recording warnings that were not logged for that particular build.

Allen 2010-07-14 20:36:12

Just have three individual builds and you will always have the correct warnings for each assembly.

Peter Schuetze 2010-07-15 13:42:35

I've honestly thought about that but idk how feasible it is on a large scale project

Allen 2010-07-15 15:01:26

ansaurus

tags:

views:

answers:

How can I retain compiler warnings in Hudson (CI) when using SVN Update?

related questions