How to ensure same git checkout for build and deploy jobs in Jenkins?

In Jenkins, I have a “Build” job setup to poll my git repo and automatically build on change. Then, I have separate “Deploy to DEV”, “Deploy to QA”, etc. jobs that will call an Ant build that deploys appropriately. Currently, this configuration works great.

However, this process favors deploying the latest build on the latest development branch. I use the Copy Artifact plugin to allow the user to choose which build to deploy. Also, the Ant scripts for build/deploy are part of the repo and are subject to change. This means it’s possible the artifact could be incompatible between versions. So, it’s ideal that I ensure that the build and deploy jobs are run using the same git checkout.

Is there an easier way? It ought to be possible for the Deploy job to obtain the git checkout hash used from the selected build and checkout. However, I don’t see any options or plugins that do this.

Any ideas on how to simplify this configuration?

  • How can I create parameterized Jenkins job?
  • Jenkins issue with Git on Windows
  • How to build a pipeline of jobs in Jenkins?
  • Any decent Eclipse plugin for monitoring Jenkins?
  • Downloading a directory inside a git repo
  • build error in jenkins.Fatal error: 'Cordova/CDVViewController.h' file not found
  • Passing data between build steps in Jenkins
  • How to fork a background process in Jenkins? Setting BUILD_ID and using nohup seems to be non working
  • 2 Solutions collect form web for “How to ensure same git checkout for build and deploy jobs in Jenkins?”

    You can use Parameterized Trigger Plugin to do this for you. The straight way is to prepare file with parameters as a build step and pass this parameters to the downstream job using the plugin. You can pass git revision as a parameter for example or other settings.

    The details would vary for a Git repo (see https://stackoverflow.com/a/13117975/466874), but for our SVN-based jobs, what we do is have the build job (re)create an SVN tag (with a static name like “LatestSuccessfulBuild”) at successful completion, and then we configure the deployment jobs to use that tag as their repo URL rather than the trunk location. This ensures that deployments are always of whatever revision was successfully built by the build job (meaning all unit tests passed, etc.) rather than allowing newer trunk commits to sneak into the deployment build.

    Git Baby is a git and github fan, let's start git clone.