Skip to end of metadata
Go to start of metadata

Plugin Information

View Job Revision on the plugin site for more information.

This plugin enables users to set a revision (a version) for the Jenkins job.

Features

The job revision sets the JOB_REVISION as an environment variable in the Jenkins job.

Some use cases

  • To bring traceability when there are multiple branches of a product.

Configuration

Combination with other plugins

It is suggested to use the EnvInject Plugin to manage all job environment variables.
EnvInject plugin retrieves the job revision variable (JOB_REVISION).

Roadmap

  • Retrieve the revision from the main build step stored in your build descriptor (Maven, Ivy, Gradle, ...)

Changelog

Version 0.6 (2012-01-03)
  • Add an optionalBlock
Version 0.5 (2011-05-16)
  • Built for Jenkins 1.410 (company target)
Version 0.4 (2011-02-17)
  • Workaround issue in IBM JVM causing intermittent ClassNotFoundException. (JENKINS-5141)
Version 0.3 (2010-07-02)
  • Added a dedicated page to display the revision; the revision is also exposed by API (XML, JSON and Python).
Version 0.2 (2009-11-08)
  • Added an Hudson ParameterValue to keep track of the revision through the builds.
Version 0.1 (2009-11-02)
  • Initial release

3 Comments

  1. Does the job revision automatically increase when saving the config without changing the value manually? This would be an helpful feature for me, since I would typically forget to change the revision manually, which renders the revision number useless. In addition, I will not maintain the server indefinitely. The maintainers after me are more likely to forget this, since the maintenance will slow down in the future.

  2. Unknown User (gboissinot)

    The job revision is not automatically updated when you saves your Hudson Job configuration. In my opinion, you must be able to save n times your job configuration without any impact on the value of hudson revision.
    The hudson revision value has to be given by the team in charge of the job.
    Set the job revision value has to be done at the same level as the other steps. The Hudson maintener is not in charge of this kind of configuration.

    1. Sorry, I had a different understanding what the revision was referring to. I would have used it to mark the revisions of a build script. I would use for the main (may be even minor) version the app version that can be build. Then I would count up the next element by one every time I save the configuration. This would be my revision number of the job. This would help me to keep track of the revision, that my build script is at.

      In combination with the scm-sync-configuration plugin, this would be extremely useful. For identifying the job configuration for a specific run. Currently I have to use the timestamp.