A few months ago we decided to upgrade our source control provider and moved everything over to Visual Studio Online. It’s been working great for source control, though getting used to using Git instead of the TFS source control is a bit of work. For a few reasons we’re not using the build features of Visual Studi Online, but instead are using a Jenkins build server. Jenkins is really nice and can do just about anything you could want, which is a big plus. The only down side is that it’s all in Java. Why is that a down side, you may wonder? Well if things get broken, you’re in a pickle.
We were running all well and good for over a month. Nightly builds were running. Version umbers were auto-incrementing. Releases for Windows and Mono were getting auto-generated and getting FTPed up to the public release directory. Things were great. Until about a week before Christmas, when an update for the git plug-in was released. The Git plug-in is what allows you to configure Jenkins to easily connect to a Git server and pull your source code. Well the plug-in update broke the ability to get code from a Git server on Windows. Now Jenkins has a rollback feature, and had I understood what the failure actually was (it wasn’t obvious that it was a plug-in failure) then I could have rolled back and probably been fine. But I didn’t know. And in my effort to “fix” things, I wiped out the roll-back archived version.
So the option was to either install a Java environment and try to learn how Jenkins works and fix it, or to wait for the community to fix the problem. I opted to do the latter, because it surely would break other people and would get straightened out quickly, right? Hmm, not so much it seems. I found a reported bug and asked for a time estimate. I waited a few days. No fix. I left the office for a week of “unplugged” vacation and came back.. No fix. I then learned that you can access the nightly builds for the plug ins themselves (which is actually pretty cool) so I tried manually installing the latest builds of the plug-in. Turns out it was still broken.
While I was trying to figure out what was broken, I also appear to have broken something in the Git workspace on the server too, so it was hard to tell if the plug-in was failing, or if Git was confused. I know that I was confused. So today I decided that I really needed to get this stuff working again. I changed the Job to no longer use source control, but instead to just run Window batch files.
REM make sure nothing is hidden
attrib -H /S
REM recursively remove child folders
for /d %%X in (*.*) do rd /s /q "%%X"
REM delete files in root folder
del /q /f *
REM get the source
git clone https://[username]:[password]@opennetcf.visualstudio.com/DefaultCollection/_git/SolutionFamily
REM check out
git checkout master
git add ./Common/SolutionFamily.VersionInfo.cs
REM increment the build number
powershell -File "%WORKSPACE%\Utility\SetFamilyVersion.ps1" 2.1.%BUILD_NUMBER%.0
REM commit the change
git commit -a -m auto-version
git push https://[username]:[password]@opennetcf.visualstudio.com/DefaultCollection/_git/SolutionFamily
Once that was done, the MSBUILD plug-in was then able to build from the workspace, though the source code directory had changed one level as compared to where the Git plug-in had been pulling code. If I had wanted to, I could have had my command do the build as well and not even used the MSBUILD plug in by adding this to the end:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe "/p:Configuration=Debug;Platform=Any CPU" /m "%WORKSPACE%\SolutionFamily\SolutionEngine.FFx.sln" && exit %%ERRORLEVEL%%
Once the Git plug-in is actually fixed, I’ll post how to use it to connect to Visual Studio Online. It actually seems to be working “somewhat” this morning. I say “somewhat” because while it actually is pulling the code and behaving properly, when you do the configuration you get an error, which makes it look like it’s going to fail. Until that’s ironed out I’m going to wait.