Simplifying releases through git
October 27th, 2009 . by Daniel HölblingI confess: I love writing build scripts. They are usually insanely easy to write, and provide you with a disproportional amount of value over time that it’s almost tragic not to have them. And, I love git.
So, what’s better than to see git simplifying my buildfiles 
.
Imagine the usual: Your assembly version is encoded in your buildfile, so whenever you want to release you do the following:
- Increment version number in buildfile
- Run buildfile
- Create a tag in your SCM for the released version
Now, thanks to the smart people at the castle mailing list I found out about the git describe command. By using git-describe you can simplify the above to just:
- Create a tag in your SCM
- Run buildfile
The function for that is quite simple:
function Get-Git-Commit
{
return git describe
}
function Get-Git-Version
{
$v = git describe --abbrev=0
return $v -replace "v", ""
}
Get-Git-Commit is returning the full name of the build, giving me a string like: v0.1.0.2-2-gd19ce0f.
And Get-Git-Version will output the tag-name without the leading v so it can be used as the product version inside the assembly info.
My buildscript then uses this version information from git to write my AssemblyInfo.cs files and build numbers have started to magically change!
This technique helps me to avoid all the hassle of incrementing build numbers, but instead allows me to focus on my work more. Once I feel the release is done, I simply hit:
git tag –a v1.0.0.1
(don’t forget to use git push –tags to get them to your server)
Hey, that’s awesome! There has to be a catch right? Indeed, there is:
If git is not installed, you can’t compile. Bummer I know, especially since the unwashed masses are in the process of slowly grasping the concept of SVN, who would want to throw a DVCS like git at them?
This is why all of my build script have a step called release that packs everything together in one nice zip file and I can then upload it to some server. In case someone has no git, he’s stuck with my binary files.
You can see this in action by looking at these open-source buildfiles I wrote lately: dotless, elms-connector.
Ahhh, I understand what you were banging on about now. Skype chat isn't the best way of explaining a coding solution (either that or I wasn't paying attention). Great work on the build script anyway.
How are you handling the commit hash? The CLR only admits 16-bit numbers for each version component…
We don't use the hash in the version attribute but only in title and description.
The version is just straight from the git tag (like v1.1.0)
But Ayende adds the hash to the version number in Rhino-Mocks. But he has to disable some compiler warning for that.
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
When your build script updates the AssemblyInfo.cs files when releasing, doesn’t that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a ‘GIT reset –hard’ right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I’m still seeking a good balance myself.n
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
I’ve also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I’ll look into it a bit more.
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit. nIf you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that’s ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
That’s the best option. I’ve read MSI’s and other installers use the FileVersion, but no clue how exactly…
When your build script updates the AssemblyInfo.cs files when releasing, doesn't that require an additional GIT commit for the updated AssemblyInfo.cs files? Or does the script do a 'GIT reset –hard' right after releasing and you oonly tag the version in GIT? Or is the build script really doing a GIT commit+ GIT tag for every build? A commit for every build sounds like overkill. I'm still seeking a good balance myself.
I think you can put the complete hash in the informationalversion, it takes a string. The other version attributes require numbers.
I've also seen scripts where you put the hash into the normal version number and disable the warnings you get through some compiler flags. But I decided against it. Still thanks for the tipp, I'll look into it a bit more.
Actually the build script does not commit at all. AssemblyInfo.cs is NOT part of the repository. It gets ignored and therefore there is no need for git-commit.
If you make a clean clone of the repo you need to run the buildscript at least once before you can start working, but that's ok. After that whenever you commit and do a subsequent build the AssemblyInfo.cs will get updated to the newest version..
That's the best option. I've read MSI's and other installers use the FileVersion, but no clue how exactly…