Apr
13
2012

Sending your Git branch changes as an email attachment

IMG_1586The other day I wanted to send per email some code to a friend which doesn’t use Git. He is using Svn and I use Git Svn in front of this Svn repository. Why I do that? Don’t get me started…

So he couldn’t pull from my repo and we were kind of stuck. Really?!? For sure not, here was the goal I set as I am sure this will happen some other time: having the computer work for me. What a strange idea you would say! Yeah, the computer working for you. At the end aren’t we here to make the cool things and let the computer do the boring things?

Ok so I came up with a quick hack. I wanted to have a way to send all the new, or modified, files of my current Git branch per email as a zip attachment. Guess what it was quite easy even for a PowerShell beginner like me.

First of all I needed first to be able to determine on which Git branch I was curently. I googled and find the following

function Get-GitBranch {
    $symbolicref = git symbolic-ref HEAD
    $branch = $symbolicref.substring($symbolicref.LastIndexOf("/") +1)
    return $branch
}

Then I wanted to be able to Zip all the files, but to achieve I had to determine which were the files to Zip. this is done using the following

git diff --name-only HEAD..master

And making a Zip out of the list of files is done like this

function Zip-GitBranch([string]$zipFilename) {

    $branch = Get-GitBranch
   
    if (!$zipFilename) {
        $zipFilename = [string]::Format(".\{0}.zip", $branch)
    }

    $files = git diff --name-only HEAD..master

    foreach($file in $files) {
         & 'C:\Program Files\7-Zip\7z.exe' a $zipFilename $file
    }
   
    return $zipFilename
}

Finally I wanted to be able to send the zip as an attachment of an email using Outlook

function MailZip-GitBanch($Recipient) {
   
    if (!$Recipient) {
        Write-Host "You need to pass the email of the recipient as parameter"
        return
    }
   
    $branch = Get-GitBranch
    $zipFilename = [string]::Format(".\{0}.zip", $branch)
    $attachement = [IO.Path]::GetFullPath( $zipFilename )

    Zip-GitBranch($attachement)
       
    $ol = New-Object -comObject Outlook.Application
    $Mail = $ol.CreateItem(0)
    $Mail.Recipients.Add($Recipient)
    $Mail.Subject = "Changes for the branch: " + $branch
    $Mail.Body = "Check out the email attachement to see the changes made to the branch: " + $branch
    $Mail.Attachments.Add($attachement)
    $Mail.Send()
}

Now I can type the following command to send my changes to my friend

MailZip-GitBranch myemail@email.com

You can find the whole script on the following gist.

Feb
7
2012

Starting TeamCity builds from HipChat using Github Hubot

La table du diable depuis la Savane des Pétrifications

After writing about “Running your TeamCity builds from PowerShell for any Git branch” I’d like to talk about another integration which is using Github Hubot so that the build could be started directly form a chat room.

So using the same idea, which is to extend our development environment, we implemented a way to start TeamCity builds directly from our HipChat room. You could do the same from Campfire for sure.

The main idea of this is to have our daily tools right at our disposal where we spend a good part of our days, chat rooms.

First we had to install Github Hubot and we have chosen to use Heroku which offer free hosting for one of their web dyno. They even offer what they call Hubot Factory which is a way to allow people to easily and quickly deploy new instances of Hubot to Heroku. In fact we went with a manual installation described on this page “Hubot for HipChat on Heroku”.

The idea is still the same we need to run TeamCity builds by “Accessing the Server by HTTP”.

This time we want to have Hubot calling the TeamCity server so we need to add a new CoffeeScript to the scripts of Hubot which will launch the HTTP request needed.

Our script is heavily inspired from the TeamCity.coffee script, and here is a first version:

# Starts a build on TeamCity.
#
# You need to set the following variables:
# HUBOT_TEAMCITY_USERNAME = 
# HUBOT_TEAMCITY_PASSWORD = 
# HUBOT_TEAMCITY_HOSTNAME = 
#
# start build buildId -- Starts TeamCiyt build using buildId
module.exports = (robot) ->
  robot.respond /start build (.*)/i, (msg) ->
    username = process.env.HUBOT_TEAMCITY_USERNAME
    password = process.env.HUBOT_TEAMCITY_PASSWORD
    hostname = process.env.HUBOT_TEAMCITY_HOSTNAME
    buildName = msg.match[1]

    msg.http("http://#{hostname}/httpAuth/action.html?add2Queue=#{buildName}")
      .headers(Authorization: "Basic #{new Buffer("#{username}:#{password}").toString("base64")}",
               Accept: "application/json")
      .get() (err, res, body) ->
        if err
          msg.send "Team city says: #{err}"
          return

By the way I started to learn CoffeeScript so this is more hacking then something really productive.

And here is the result in our HipChat room asking hubot to start a build with the command:

hubot start build bt21

TeamCity, GitHub Hubot and HipChat

I will talk in another post about the last part which shows the status of the build in the chat room.

Feb
7
2012

Running your TeamCity builds from PowerShell for any Git branch

Plage le long de la Savane des Pétrifications

I love TeamCity and use it since a while to automate my build/release processes. As human we should never do the work a machine can do, we have certainly better and more interesting things to do.

The habit I saw in the different projects I worked for is to create new TeamCity builds for the branches you work on. It take quite some work to do, even with templates…

So I came with another way of doing it. It is leverage Git, PowerShell and the possibility to run TeamCity builds by “Accessing Server by HTTP”. Basically you just need to make a HTTP request to an Url like this:

http://testuser:testpassword@teamcity.jetbrains.com/httpAuth/action.html?add2Queue=bt10&system.name=<property name1>&system.value=<value1>&system.name=<property name2>&system.value=<value2>&env.name=<environment variable name1>&env.value=<environment variable value1>&env.name=<environment variable name2>&env.value=<environment variable value2>

We will also use the possibility to pass custom parameters (system properties and environment variables) through the HTTP request.

The parameter we want to pass is the Ref name of the Git VCS Root, so we start by setting it using a configuration parameter called BuildRefName, as this:

 

Git, PowerShell, TeamCity

Then we need to add a configuration parameters for our TeamCity project with the name BuildRefName which we currently set to master, so that if the parameter is not defined it will default to this value:

Git, PowerShell, TeamCity 2

Now that we have configured this you can already start a build from your browser by calling the URL!

http://testuser:testpassword@teamcity.jetbrains.com/httpAuth/action.html?add2Queue=bt10

Be sure to replace bt10 with your build id.

Nice ,but we want to get a step further and be able to start the build from PowerShell, which is quite easy!

To achieve this goal you add those two functions to your PowerShell profile:

function Get-Web($url, 
    [switch]$self,
    $credential, 
    $toFile,
    [switch]$bytes)
{
    #.Synopsis
    #    Downloads a file from the web
    #.Description
    #    Uses System.Net.Webclient (not the browser) to download data
    #    from the web.
    #.Parameter self
    #    Uses the default credentials when downloading that page (for downloading intranet pages)
    #.Parameter credential
    #    The credentials to use to download the web data
    #.Parameter url
    #    The page to download (e.g. www.msn.com)    
    #.Parameter toFile
    #    The file to save the web data to
    #.Parameter bytes
    #    Download the data as bytes   
    #.Example
    #    # Downloads www.live.com and outputs it as a string
    #    Get-Web http://www.live.com/
    #.Example
    #    # Downloads www.live.com and saves it to a file
    #    Get-Web http://wwww.msn.com/ -toFile www.msn.com.html
    $webclient = New-Object Net.Webclient
    if ($credential) {
        $webClient.Credentials = $credential
    }
    if ($self) {
        $webClient.UseDefaultCredentials = $true
    }
    if ($toFile) {
        if (-not "$toFile".Contains(":")) {
            $toFile = Join-Path $pwd $toFile
        }
        $webClient.DownloadFile($url, $toFile)
    } else {
        if ($bytes) {
            $webClient.DownloadData($url)
        } else {
            $webClient.DownloadString($url)
        }
    }
}

function tcBuild([string]$branch) {

	$url = "http://YourServerUrl/httpAuth/action.html?add2Queue=YourBuildId"

	if ($branch) {
		$url = $url + "&name=BuildRefName&value=" + $branch
    }
	
	$credentials = New-Object System.Net.NetworkCredential("Username", "Password")

	Get-Web $url -credential $credentials
}

Please adapt the tcBuild script by replacing the YourServerUrl, YourBuildId, Username, Password by your personal values.

The first function Get-Web is from this blog post: “Microcode: PowerShell Scripting Tricks: Scripting The Web (Part 1) (Get-Web)”.

The second, tcBuild, is quite easy and is the one you will use to start a build on the TeamCity server.

My workflow now is the following one:

  1. I commit on my local Git repository then
  2. when I want to run a build I push to the centralized Git origin repository in my branch then
  3. I start my build on the Git Branch from PowerShell by typing :

> tcBuild Jobping-10-NewFeature

where Jobping-10-NewFeature is the name of my Git branch.

This is quite cool and give me also the possibility to run kind of personal builds!

Nov
7
2011
Git // DVCS

DVCS and my usage of Git Svn

Sometime ago I moved “away” from subversion has my Version Control System (VCS) because I felt not free of my way of working with it. I found a great was to improve my work experience by using Git Svn in front of our central Subversion repository.

I started my experimentation with Mercurial and Hg Svn because I was already using Mercurial for my personal projects. I hit some much the wall with Hg Svn that I decided quite quickly to go and try Git Svn. I had no experience with Git at that time and I had the feeling that it was more complex to handle than Mercurial (which I still think).

So currently I use Git Svn to work on one of our product at Innoveo Solutions. I also made a presentation to the team during our techno pizza lunch about DVCS, Git, Git Flow and Git Svn.

And here is the list of what I personally gained as a developer:

  1. 2 steps commit
    1. Stage/commit, Push
  2. Local history / branching
    1. No connection to central repository needed to branch/to look at history
  3. Experiment / Refactoring / Spikes
    1. Commit changes on one path, if wrong rollback
  4. Smarter Merging
    1. Git’s focus on content rather file location
    2. Better at resolving merge conflicts for you (e.g. renames)
    3. Branching/Merging is daily workflow not anymore an ‘exceptional case’
  5. Stash changes
  6. Rebase / Rewriting history
    1. Until push you can use interactive rebase

Due to my 4h daily commute (more than 2h in the train), I very much appreciate the offline capabilities of DVCS. It lets me branch, watch the history without having a connection to the central repository. So that a really convenience thing in my day to day job.

But what I even prefer is working in local branches for experiment, refactoring. With that capability I am able again to commit small steps of code change. I particularly appreciate the possibility to experiment some refactoring and to rollback wrong changes when I feel that I went the wrong way with the change. In the past this was not possible and often you would not commit to SVN because that code would be shared with the others or t would break the build. Ok, I know I could do that with Svn working in a feature branch, but we all know the pain it is with the merging back, especially when you refactor and rename files. During refactoring it is important to be able to save/commit small chunk of code change and even more important is to be able to rollback those changes. So in that case DVCS is a perfect match to that problem.

What I currently don’t like in my current way of working with Git in front of Svn is that I have local branches which I don’t sync back to the central server. I don’t like it because if I have an issue with my local machine then those changes might be lost. I will investigate in the coming weeks about possible solutions even if the best one would be a migration of the central repository to Git. But his is another story because it means a wider change in the team.

About Laurent

Laurent Kempé

Laurent Kempé is the editor, founder, and primary contributor of Tech Head Brothers, a French portal about Microsoft .NET technologies.

He is currently employed by Innoveo Solutions since 10/2007 as a Senior Solution Architect and certified Scrum Master.

Founder, owner and Managing Partner of Jobping, which provides a unique and efficient platform for connecting Microsoft skilled job seekers with employers using Microsoft technologies.

Laurent is awarded by Microsoft since Avril 2002: Most Valuable Professional (MVP).

MVP
Certified ScrumMaster
JetBrains Academy Member

My status

Twitter

Flickr

www.flickr.com
This is a Flickr badge showing public photos and videos from Laurent Kempé. Make your own badge here.

Month List

Page List