I have a tiny project that need updating – the idcc.co.il website (*).
Source control I setup a new git repository on my home machine (using smart-http from git-dot-aspx, a different story for a different post) and now I got to setup a build server.
Team city Downloaded TeamCity 5.1.4 (the free, Professional version). Installation was mostly painless, except that the build-agent properties setter got stuck and I had to manually edit the build-agent conf file. No biggie – just RTFM: http://confluence.jetbrains.net/display/TCD5/Setting+up+and+Running+Additional+Build+Agents#SettingupandRunningAdditionalBuildAgents-InstallingviaZIPFile.
git integration Git is supported out of the box. I did have a minor glitch – the git-dot-aspx thing is very immature, and it simply did not work. Luckily the repository is located on the same machine as the build server and build agent so I simply directed the VCS root to the location on the filesystem.
building I had a few glitches with MSBuild complaining about missing project types (the webapplication targets file) – that’s the first three failures you see in the snapshot. I then copied the targets from somewhere else and I got the bulid running
Fixing the tests only to find that I have a broken test. Since when I created the initial website, I never set a build server, thus some changes I later introduced caused a minor regression. Now that I have a proper build server it (hopefully) won’t happen again.
thanx a bunch to the work done by Mauricio Scheffer, Henry Conceição and the rest of the people helping out in the process.
fork away :)
Anyone who have ever seen something like that might relate to this post:
Breaking the CI is not nice, however it does happen at times. When it happen, someone (myself this time) is appointed responsible, and will fix the build asap.
However, sometimes people do break the CI and then go home without fixing it
There are a few ways to deal with that. Usually you’d call the person who did the commit that made the build fail, and will consult with him about the best way to fix it quickly until he gets back. But sometimes it would prove complex to fix for someone that try to come in without having good knowledge on the full context.
So would you keep the CI red? that’s really bad, as you won’t get good feedback if someone else commits bad work, as it won’t turn to red, it would rather simply stay red.
At these times you’d simply wish that the person who broke the build wouldn’t have committed his change in the first place.
That’s what source control is for.
Just fire up your Subversion Log, gitk, whatever (I guess that even TFS has that ability ;) ), figure out the offending commit id, and revert these changes.
Then you get your CI in a good shape again, and you are free to break it in the regular day-to-day manner.
The CI breaker will then come back in tomorrow and will examine his change, then re-apply it correctly.
Just throw ‘!svn/bc/REVISION_NUMBER/’ to the url, right after the repository root
thx gooli for the superb tip.
Following Ayende’s post on Patch management approaches using centralized SCM, here are how I would have dealt with the 4 issues that he brings up, using a Decentralised SCM.
I use git, so I’ll use git terms here. I guess it’s quite similar for other DSCM systems.
Note that I haven’t used patches on git development as until now all of my git work was on repositories I had write access to, However the principals are the same (i.e. - all of the tree is local to my machine, thus I can reach any point in the history locally).
First I’ll clone the hosted repository to my local machine.
So, using a DSCM, I can work locally with the benefits of a SCM, have as many branches/features as I want. the whole tree is stored locally, and its blazing fast to switch branches, so I can easily work on every aspect I want, and easily create a patch from every node in the history tree, to send to the project owners.
After failing to setup git access to my newly created repository on git-hub, I managed to nail the problem, thanks to Lee Henson’s good advice (and by re-reading the hint text)
After generating the public key (with puttygen) I copied to git-hub only the key itself (the HEX part), while I was also supposed to copy the text surrounding it, as can be seen in the image below:
Copy + Paste => now it works
Now that I’m getting old, I need to keep up with the cool kids, so I’m taking git for a spin.
Downloaded MSys Git.
Upon install I went for the git-bash option. Running the bash shell has reminded my some of the old unix memories, however I am much more comfy with the windows shell these days, so I have manually added the the path things needed for running in cmd.exe/f
Now it was time to test remote. Luckily enough I got a git-hub invitation.
Step 1 - signup to git-hub.
downloaded the newest putty, then used puttygen to generate public and private key.
Step 2 - create a private repository - went smoothly.
Step 3 - trying to push to the remote repo.
I ran the PAGEANT.EXE tool, loaded it with the private key, and set the GIT_SSH environment variable to point to PLINK.EXE.
Then tried to “git push origin master” and got a message like “The server’s key signature is not in the registry, press ‘y’ for storing in the registry, ‘n’ for skipping, ‘return’ to exit”. the problem is - it got stuck, no input allowed except ctrl-C.
Then I tried to putty directly to the server, and now it did let me press the y, hoora - server’s public key’s signature is stored.
You’d think could push to the repository? think again. I then started getting other weird errors like “No supported authentication methods available”.
Maybe Ill try again tomorrow.
UPDATE (07/04/2008 - I guess tomorrow is a flexible term these days …):It was me being silly. Now it works perfectly
Well, Here’s my first hopfully useful post in my blog.
pdb files of projects and assemblies being referenced by a web application, somtimes become “source controlled” when using VS 2005 and VSS. This is leading to the pdbs and even dlls to become readonly, and therefore the break of a succesful post-build events, such as copying newly compiled dlls to the web application’s Bin directory, hence unexpected behavior of the application.
The “Why the heck this is happening”:
Using VS 2005 to develop ASP.NET 2.0 applications is somewhat different than in the good old VS 2003.
The main difference is caused by the missing project file.
As opposed to VS 2003, which compiled the cs (and vb) files of a web project using csc.exe (and vbc.exe), as with regular (not web) projects, things are different with VS 2005 web projects.
In order to allow on the fly compile of source files (codebehinds and App_Code files), and on the other hand, to allow a precompilation ofthe whole project (including aspx, ascxand other “non code” files), the framework has provided us with a special compiler, named aspnet_compiler.exe
allowing a full “automated” compiled outside of any IDE, requires disrelying on an IDE specific file, such as the csproj/vbproj files, therefore, everything in (and under) the application’s directory considered to be a part of the project.
In VS 2003 the compiler knew about referenced dlls and projects from the csproj/vbproj file. Now referenced dlls are known throuh a .refresh file in the Bin directory, that points to the location of the dll, and referenced project files are written to a special section in the web.config.
Controlling the source manually using VSS interface is possible, yet you have to manually remember not to check in items from the Bin directory, except the .refresh files.
The VSS integretion in VS 2005 is trying to outsmart the problem. it assumes that if a .refrsh file exists in the Bin directory, then the file it references is not to be source controlled. For example: if the Bin directory contains a file names MyAssembly.dll.refresh, then if it also contains a file names MyAssembly.dll (and it will, after a succesfull build), it won’t treat it as source controlled.
It also understands that if a file is there, due to a build action, it is also marked so it won’t besource controlled.
But, if you build you solution in Debug configuration,now you have pdb files in the Bin directory. let’s say that you do a Release Build, that does not create and copy pdb files. now the existing pdb files in the Bin directory are not marked, and the VSS integration will sense that there are new files in the Bin, that have no .refresh file, andwas not created during the last Build event, so it will mark them as Check InPending files !!!
The “Gosh it’s Ugly solution”:
You need to:1.Rebuild the solution in Debug configuration2. Close and Reopen the project.
If you’ve already accidently Checked In the pdb files, you need to:1. Manually delete them from the VSS.2. Manually set their readonly attribute to false.3.Rebuild the solution in Debug configuration4. Close and Reopen the project.
The place where i’ve found this solution: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=106422&SiteID=1
So until next time, keep on with the good coding thing you’ve beendoing while you’ve start reading this post.