Tag Archives: hudson

Hudson Modify Environment Variables Properties

Posted on by

Myself and another have been trying to figure out how to modify the environment variables programmaticly using groovy in Hudson. After a little of tinkering we were able to do it.

1
2
3
4
5
6
7
def hudson = hudson.model.Hudson.instance
def globalProps = hudson.globalNodeProperties
def props = globalProps.getAll(hudson.slaves.EnvironmentVariablesNodeProperty.class)
for (prop in props) {
    prop.envVars.put("TEST_ENV", "WORKS")
}
hudson.save() //This is needed in order to persist the change

Then if you want to expand this for the slaves:

1
2
3
4
5
6
7
8
9
10
11
12
def slaves = hudson.model.Hudson.instance.getNodes()
for (slave in slaves) {
    println "-----------------------"
    println slave.name
    println "-----------------------"

    def props = slave.nodeProperties.getAll(hudson.slaves.EnvironmentVariablesNodeProperty.class)
    for (prop in props) {
        prop.envVars.put("TEST_ENV", "WORKS")
    }
    //SAVE
}

Gerrit Workflow

Posted on by

The workflow defines a process for using with Google’s Gerrit project. It is excellent in a number of ways! If you are using Git at your company and want to have a nice code review process as well as a way to verify and have a few more checks and balances, this is an amazing tool that Google has provided open source. I did make a few customizations to the tool in order to better suite our needs within the company and maybe I will share those once I get some more free time.

The idea with the following workflow is to show you a developer process from beginning to the end of a feature using Gerrit.  We are not using Repo which is a Google developed tool to work with Git and Gerrit.  We are using straight out of the box Git with Gerrit.  In our company we have a few proprietary development build processes but I try to call those out in the workflow so that you can tell how it could be adapted to your company or open source project.

Workflow

  • Implement feature
    • 1
    2
     //Create topic branch off of master
    git checkout -b topic origin/master
  • Commit changes. Commit as many times as you want to the topic branch.
  • Get latest code frequently and especially before you push.
    • 1
    git pull
  • Fix Merge Conflicts
    • 1
    2
    3
     git mergetool
    //'''Do *NOT*''' commit after you do the merge
    git rebase --continue
  • Compile the code
    • 1
    2
    3
    4
    //This is an internal shortcut for us to do a full compile just like the integration hudson builds
    //You really want to be able to replicate exactly what the integration machines are doing and
    //make it as easy as possible.
    projbuild
  • Validate the code (This means running your unit tests, integration tests, a subset of all the selenium tests, etc.)
    • 1
    projbuild dev_check
  • Prepare a single commit for code review by squashing your commits
  • Create another local branch
    • 1
    git checkout -b topicForCodeReview origin/master
  • Merge squash your topic branch into your topicForCodeReview branch
    • 1
    git merge --squash topic
  • The squash leaves the changes in your topicForCodeReview branch in the staged state. You’ll need to fire up git gui and commit them to that branch.
  • Push for code review
    • 1
    git push for-code-review
  • Fix any merge issues using git mergetool if necessary.
  • Note: If you choose not to squash before pushing for code review, every commit will get a separate code review!! This is not recommended.

Setup

You will need to setup the git config a certain way in order to be able to pull off this workflow.  Pretty trivial changes though, so don’t worry to much yet 🙂

  • Set rebase to always
    • 1
    2
    [core]
      rebase = always
  • Set up the shortcut for “for-code-review”
    • 1
    2
    3
    [remote "for-code-review"]
      url = <main git uploading repository location>
      push = HEAD:refs/for/master