Replicating release builds of CC.Net locally

[psla...@mywebgrocer.com]

Hi, I'm looking to add a specific feature (Bug #272) to a locally built copy of CC.Net v1.8.4 but I'm having a few issues with replicating the builds exactly.

If I can first replicate the build process and build binaries that are bit for bit identical to the official versions then it's a fairly trivial matter to patch the existing build servers with the one small change we need without having to validate them all over again.

When I run build-package.bat I do get a "BUILD SUCCEEDED" message but the binaries that are produced are about 20K larger than the official binaries.

Is there any public doc that would help me replicate the official build server environment so that I can replicate the builds? I'm assuming the main issue is that I do not have exactly the same versions of the build tools.

Thanks

[Ruben Willems]

You're doing the correct thing.

download the source of the involved version( 1.8.4 in your case)

and run the build_package.bat file

you can see in the involved build script that we zip the source after compilation
so there is no extra get or so involved that could explain code differences.

with kind regards
Ruben Willems

--

---
You received this message because you are subscribed to the Google Groups "ccnet-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ccnet-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[psla...@mywebgrocer.com]

Yes, I am getting a output source ZIP that is identical to the official source ZIP (except for the minor changes I made to hardcode the git commit # and the version number)

I'm using a clean Windows 2012 system with just the Windows SDK v7.0.7600.16385.40715 installed.

I'm opening the CMD prompt shortcut that the SDK setup and then CDing to the dir where the source is extracted and running "build-package.bat"

Yet the binaries that are output are not identical to the official builds which leads me to believe that one of the tools I'm using is a different version from those that you are using on the official build server.

Do you happen to have a list of what tool versions you have installed on the official build server?

[Ruben Willems]

the only thing that could be different is the version of .Net itself
all the other tools are included in the zip file (they are in the repository)

all should be fine though, I used that method for years and never had any problem / abnormality

what kind of adjustment did you make?

if it is a new kind of task or so, it's better to create that as a plugin,

so you could install a new version, copy that dll in the bin folder and you're done.

No longer updating the source afterwards.

with kind regards
Ruben Willems

[psla...@mywebgrocer.com]

I haven't made any adjustments yet except for the minor changes I made to hardcode the git commit # and the build version number, but they shouldn't make a difference like this.

The change I need to make is the change that fixes SVN repos with relative pathed externals (Bug #272), it's only about 10 lines of code in \project\core\sourcecontrol\Svn.cs and is in the 1.9 branch, but we don't feel comfortable using one of the nightly builds to replace a working v1.8.4 set of systems (4 servers). Rebuilding with just this one change would be preferable for us at this time.

What versions of .NET and the SDK are you using?

[Ruben Willems]

I can not say :-(

I do not have physical access to the build server, to check this.

But the method you use should work, I think you worry to much in this case :-)

The packaged source you can download at sourceforge, is the source used to build the setup.

otherwise you could copy the entire svn.cs file, alter it to you whishes, and just change the reflector attribute.

Next you need to update ccnet.config to use your new svn.

This way your sure that your code is ran.

with kind regards
Ruben Willems

[Daniel Nauck]

Hello,

the following is installed:

C:\Program Files\Microsoft SDKs\Windows\v7.1>clrver

Versions installed on the machine:

v2.0.50727

v4.0.30319

+ German language stuff

Well, if you get the source and use the build package stuff you get exactly the same version. Thats what the build server does.

Kind regards,

Daniel

[psla...@mywebgrocer.com]

I was missing the v4.0.30319 CLR so I installed the v7.1 SDK but I'm still not getting identical binaries.

Ruben: Can you please give me some more details on the reflector attribute changes you mentioned? I asked a few .NET devs here and no-one seemed to understand exactly what you meant by that.

Thanks.

[James Chaldecott]

Just a quick message from a lurker...

The C# compiler isn't deterministic. The binaries will always be slightly different.

I can't find the link now, but there was a blog post or something the other day saying that they've just done the work so that the Roslyn compiler *will* be deterministic.

You could always use Reflector (or ildasm?) on both binaries and compare the output of that, I suppose.

James

Sent from my Windows Phone

---

From: psla...@mywebgrocer.com
Sent: ‎27/‎05/‎2014 23:17
To: ccnet...@googlegroups.com
Subject: Re: [ccnet-devel] Replicating release builds of CC.Net locally

[Ruben Willems]

What I meant was that you could make your 'own' svn source control.
Here are some tips :
http://www.cruisecontrolnet.org/projects/ccnet/wiki/DevInfo_MakingPlugins

at the bottom of that page are links to my blog with more detailed examples,

but basically it comes to this :

° make a new Visual Studio solution with a project in it : myCCNetStuff

° here you copy svn.cs of CCNet in

° make your changes

° change the reflector attribute at the class level, now it is  [ReflectorType("cvs")]

    change it to  [ReflectorType("svnextended")]

° compile the plugin (make sure you follow the naming guide as mention in the above link)

° place the plugin into the CCNet bin folder

° update ccnet.config, change the source control provider from svn to svnextended

that should do it

with kind regards
Ruben Willems

[psla...@mywebgrocer.com]

OK, now everything I was seeing makes sense :-)

I was going on the flawed premise that the C# compiler would output the same bits every time.

Here's a good blog article that describes in detail why that does not happen:

http://ericlippert.com/2012/05/31/past-performance-is-no-guarantee-of-future-results/