0

I'm using hudson to auto-deploy my Rails app to heroku. In my main build job I pull from a Git repo (hosted using gitosis on the same machine), master branch with the following:

URL of repository: /home/git/repositories/my_app.git
Name of repository: origin
Refspec: +refs/heads/master:refs/remotes/origin/master
Branches to build: master

Then, assuming all tests pass, I want to kick off a new build that is the deploy to Heroku.

I can't however figure out how to get that deploy build to checkout the particular revision that this build was using. I understand there's a parameterized trigger plugin that would allow me to pass this revision number, but I don't know how I can tell hudson to checkout this particular revision on the deploy build.

I'm pretty sure this just has to do with my limited knowledge of git, but where in the hudson git config's is there an option to checkout a particular revision?

Otherwise, I could have many commits happen whilst a build is happening, and when it kicks off a deploy build, that deploy build would just check out the HEAD of the branch, which may not be the same as the code that was pushed that triggered this build.

I don't fully understand why I have a refspec in Hudson, then also specify a branch to build, I thought this was the same thing. Can refspec somehow specify the revision number? How would this be referenced if it was passed through with the parameterized trigger plugin?

(I've never used that plugin, but someone else recommended it as a way to pass in vars to a new build, if there's another way I'm all ears)

brad
  • 492
  • 1
  • 10
  • 22

2 Answers2

1

See here for an git explanation.

BTW, do you store the deployable artifacts in git or do you rebuild your app before deploying? Otherwise let your first job push the artifacts into a repository (can be different than the one for source code, we have a designated space on the file system) and the second job pulls it from the repository and deploys it.

Community
  • 1
Peter Schuetze
  • 1,231
  • 10
  • 17
  • I'm pretty new to hudson and git so i'm just figuring this all out. Are you suggesting that hudson should create, say, a new branch with a build number and push it back to the repo, then pass that on to my deploy build to check out and deploy? It's a rails app so there isn't actually a lot of "building". Heroku take care of deployment by just pushing the repo to the heroku remote. – brad Dec 29 '09 at 18:22
  • 1
    I am not sure what deployment means for you because I am coming from the j2ee world with ear and war files. These artifacts we currently put in a directory structure so we have a one to one relationship between an artifact and a certain job build number. You can also use your code repository for this. However, I read your question the way that you want to create two jobs (first one builds and runs tests and second one builds and deploys). If your deploying is essentially just copying your files to a server, you can do all steps in one job->test->deploy. No need for a specific git revision. – Peter Schuetze Dec 29 '09 at 19:18
  • that was my initial idea also, but I couldn't find any post-build options to run custom scripts (in my case, push to heroku). I'm using a freestyle project as it's a ruby project, and ya, deployment is literally pushing the repo to heroku so there's no building really. I thought about just having the last step of the build do the deploy, it's not a post-build step as I would have wanted, but if it's the last step and it's run, I guess I"m safe to assume all other steps passed. Thoughts? – brad Dec 30 '09 at 01:29
  • 1
    With a freestyle project you can add as many build steps as you want. So it is more a definition if you call it another buildstep or if you call it post build step. Regarding passing the build, Hudson stops executing following steps if one step fails. So you should be save with assuming, that everything worked fine when the deploy part runs. – Peter Schuetze Dec 30 '09 at 02:18
0

I think that you can do this more easily by setting up the steps in hudson to run your tests and then push, if your tests return a non-zero exit on failure. This works because I think hudson will stop executing the chain of build steps as soon as there's a failure (non-zero exit status).

pjz
  • 10,497
  • 1
  • 31
  • 40