Git | Jenkins plugin

Git Username and Password Binding

This binding provides authentication support over HTTP protocol using command line git in a Pipeline job.

Click the Pipeline Syntax Snippet Generator and choose the withCredentials step, add Git Username and Password binding.

Choose the required credentials and Git tool name, specific to the generated Pipeline snippet.

Two variable bindings are used, GIT_USERNAME and GIT_PASSWORD , to pass the username and password to sh , bat , and powershell steps inside the withCredentials block of a Pipeline job. The variable bindings are available even if the JGit or JGit with Apache HTTP Client git implementation is being used.

Shell example

withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id', gitToolName: 'git-tool')]) { sh 'git fetch --all'

withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id', gitToolName: 'git-tool')]) { bat 'git submodule update --init --recursive'

withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id', gitToolName: 'git-tool')]) { powershell 'git push'

The URL of the remote repository. The git plugin passes the remote repository URL to the git implementation (command line or JGit). Valid repository URL’s include https, ssh, scp, git, local file, and other forms. Valid repository URL forms are described in the git documentation.

Credentials

Credentials are defined using the Jenkins credentials plugin. They are selected from a drop-down list and their identifier is stored in the job definition. Refer to using credentials for more details on supported credential types.

Git uses a short name to simplify user references to the URL of the remote repository. The default short name is origin. Other values may be assigned and then used throughout the job definition to refer to the remote repository.

Refspec

A refspec maps remote branches to local references. It defines the branches and tags which will be fetched from the remote repository into the agent workspace.

A refspec defines the remote references that will be retrieved and how they map to local references. If left blank, it will default to the normal git fetch behavior and will retrieve all branches. This default behavior is sufficient for most cases.

The default refspec is +refs/heads/*:refs/remotes/REPOSITORYNAME/ where REPOSITORYNAME is the value you specify in the above repository "Name" field. The default refspec retrieves all branches. If a checkout only needs one branch, then a more restrictive refspec can reduce the data transfer from the remote repository to the agent workspace. For example, +refs/heads/master:refs/remotes/origin/master will retrieve only the master branch and nothing else.

The refspec can be used with the honor refspec on initial clone option in the advanced clone behaviors to limit the number of remote branches mapped to local references. If "honor refspec on initial clone" is not enabled, then a default refspec for its initial fetch. This maintains compatibility with previous behavior and allows the job definition to decide if the refspec should be honored on initial clone.

Multiple refspecs can be entered by separating them with a space character. The refspec value +refs/heads/master:refs/remotes/origin/master +refs/heads/develop:refs/remotes/origin/develop retrieves the master branch and the develop branch and nothing else.

Refer to the git refspec documentation for more refspec details.

The git plugin supports username / password credentials and private key credentials provided by the Jenkins credentials plugin. It does not support other credential types like secret text, secret file, or certificates. Select credentials from the job definition drop down menu or enter their identifiers in Pipeline job definitions.

When the remote repository is accessed with the HTTP or HTTPS protocols, the plugin requires a username / password credential. Other credential types will not work with HTTP or HTTPS protocols.

When the remote repository is accessed with the ssh protocol, the plugin requires an ssh private key credential. Other credential types will not work with the ssh protocol.

url (required) should match the URL in which a Jenkins job is configured to clone.

branches (optional) is a comma separated list of one or more branches meant for multi-branch pipelines.

sha1 (optional) the SHA1 Git commit hash which triggered the notification.

token (optional) a secret token which must match the Jenkins configuration. Jenkins ignores non-matching token requests.

Add the following line in your hooks/post-receive file on the git server, replacing <URL of the Git repository> with the fully qualified URL you use when cloning the repository, and replacing <Access token> with a token generated by a Jenkins administrator using the "Git plugin notifyCommit access tokens" section of the "Configure Global Security" page.

curl "http://yourserver/git/notifyCommit?url=<URL of the Git repository>&token=<Access token>"

This will scan all the jobs that:

Have Build Triggers > Poll SCM enabled. No polling schedule is required.

Are configured to build the repository at the specified URL

For jobs that meet these conditions, polling will be triggered. If polling finds a change worthy of a build, a build will be triggered.

This allows a notify script to remain the same for all Jenkins jobs. Or if you have multiple repositories under a single repository host application (such as Gitosis), you can share a single post-receive hook script with all the repositories.

The token parameter is required by default as a security measure, but can be disabled by the following system property:

hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL

It has two modes:

disabled-for-polling - Allows unauthenticated requests as long as they only request polling of the repository supplied in the url query parameter. Prohibits unauthenticated requests that attempt to schedule a build immediately by providing a sha1 query parameter.

disabled - Fully disables the access token mechanism and allows all requests to notifyCommit to be unauthenticated. This option is insecure and is not recommended.

When notifyCommit is successful, the list of triggered projects is returned.

If JGit and command line git are both enabled on an agent, the git plugin uses a "git tool chooser" to choose a preferred git implementation. The preferred git implementation depends on the size of the repository and the git plugin features requested by the job. If the repository size is less than the JGit repository size threshold and the git features of the job are all implemented in JGit, then JGit is used. If the repository size is greater than the JGit repository size threshold or the job requires git features that are not implemented in JGit, then command line git is used.

If checked, the plugin will disable the feature that recommends a git implementation on the basis of the size of a repository. This switch may be used in case of a bug in the performance improvement feature. If you enable this setting, please report a git plugin issue that describes why you needed to enable it.

If checked, the initial checkout step will not avoid the second fetch. Git plugin versions prior to git plugin 4.4 would perform two fetch operations during the initial repository checkout. Git plugin 4.4 removes the second fetch operation in most cases. Enabling this option will restore the second fetch operation. This setting is only needed if there is a bug in the redundant fetch removal logic. If you enable this setting, please report a git plugin issue that describes why you needed to enable it.

If checked, the git tag action will be added to any builds that happen after the box is checked. Prior to git plugin 4.5.0, the git tag action was always added. Git plugin 4.5.0 and later will not add the git tag action to new builds unless the administrator enables it.

The git tag action allows a user to apply a tag to the git repository in the workspace based on the git commit used in the build applying the tag. The git plugin does not push the applied tag to any other location. If the workspace is removed, the tag that was applied is lost. Tagging a workspace made sense when using centralized repositories that automatically applied the tag to the centralized repository. Applying a git tag in an agent workspace doesn’t have many practical uses.

The global settings of the git plugin can be defined with the Jenkins configuration as code plugin. Detailed descriptions of the individual settings are available in the global configuration settings section of this document.

An example configuration might look like this:

createAccountBasedOnEmail: false disableGitToolChooser: false globalConfigEmail: "[email protected]" globalConfigName: "jenkins-user" hideCredentials: false showEntireCommitSummaryInChanges: true useExistingAccountWithSameEmail: false

Git hooks allow scripts to be invoked when certain important git repository actions occur. This configuration controls the execution of client-side hooks on the controller and on agents. It is recommended that git hooks be disabled on the controller and on agents.

Most git repositories do not use hooks in the repository and do not need repository hooks. In those rare cases where repository hooks are needed, it is highly recommended that they are disabled on the Jenkins controller and on Jenkins agents.

Client-side hooks are not copied when the repository is cloned by Jenkins using the inbuilt SCM methods. However, client-side hooks might be installed in a repository by build steps or by misconfiguration.

If hook scripts are allowed, a client-side hook script installed in a repository will execute when the matching git operation is performed. For example, if hooks are allowed and a git repository includes a post-checkout hook, the hook script will run after any checkout in that repository. If hooks are allowed and a git repository includes a pre-auto-gc hook, the hook script will run before any automatic git garbage collection task.

See "Customizing Git - Git Hooks" for more details about git repository hooks.

A Repository Browser adds links in "changes" views within Jenkins to an external system for browsing the details of those changes. The "Auto" selection attempts to infer the repository browser from the "Repository URL" and can detect cloud versions of GitHub, Bitbucket and GitLab.

Repository browsers include:

AssemblaWeb

The git plugin provides one binding to support authenticated git operations over HTTP or HTTPS protocol, namely Git Username and Password. The git plugin depends on the Credential Binding Plugin to support these bindings.

To access the Git Username and Password binding in a Pipeline job, visit Git Credentials Binding

Freestyle projects can use git credential binding with the following steps:

Check the box Use secret text(s) or file(s), add Git Username and Password binding.

Choose the required credentials and Git tool name.

Extensions add new behavior or modify existing plugin behavior for different uses. Extensions help users more precisely tune the plugin to meet their needs.

Extensions include:

Build Initiation Extensions

Merge Extensions

Deprecated Extensions

breadth of history retrieval (refspecs)

depth of history retrieval (shallow clone)

disc space use (reference repositories)

duration of the command (timeout)

tag retrieval

Advanced clone behaviors include:

Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec. If this is not enabled, then the plugin default refspec includes all remote branches.

Shallow clone

Perform a shallow clone by requesting a limited number of commits from the tip of the requested branch(es). Git will not download the complete history of the project. This can save time and disk space when you just want to access the latest version of a repository.

Shallow clone depth

Set shallow clone depth to the specified number of commits. Git will only download depth commits from the remote repository, saving time and disk space.

Path of the reference repo to use during clone

Specify a folder containing a repository that will be used by git as a reference during clone operations. This option will be ignored if the folder is not available on the agent.

Timeout (in minutes) for clone and fetch operations

Specify a timeout (in minutes) for clone and fetch operations.

Fetch tags

Deselect this to perform a clone without tags, saving time and disk space when you want to access only what is specified by the refspec, without considering any repository tags.

Removes tags from the local workspace before fetch if they no longer exist on the remote. If stale tags are not pruned, deletion of a remote tag will not remove the local tag in the workspace. If the local tag already exists in the workspace, git correctly refuses to create the tag again. Pruning stale tags allows the local workspace to create a tag with the same name as a tag which was removed from the remote.

depth of history retrieval (shallow clone)

disc space use (reference repositories)

credential use

duration of the command (timeout)

concurrent threads used to fetch submodules

Advanced sub-modules include:

Retrieve all submodules recursively. Without this option, submodules which contain other submodules will ignore the contained submodules.

Update tracking submodules to tip of branch

Retrieve the tip of the configured branch in .gitmodules.

Use credentials from default remote of parent repository

Use credentials from the default remote of the parent project. Submodule updates do not use credentials by default. Enabling this extension will provide the parent repository credentials to each of the submodule repositories. Submodule credentials require that the submodule repository must accept the same credentials as the parent project. If the parent project is cloned with https, then the authenticated submodule references must use https as well. If the parent project is cloned with ssh, then the authenticated submodule references must use ssh as well.

Path of the reference repo to use during submodule update

Folder containing a repository that will be used by git as a reference during submodule clone operations. This option will be ignored if the folder is not available on the agent running the build. A reference repository may contain multiple subprojects. See the combining repositories section for more details.

Timeout (in minutes) for submodule operations

Specify a timeout (in minutes) for submodules operations. This option overrides the default timeout.

Number of threads to use when updating submodules

Number of parallel processes to be used when updating submodules. Default is to use a single thread for submodule updates

Shallow clone

Perform shallow clone of submodules. Git will not download the complete history of the project, saving time and disk space.

Shallow clone depth

Set shallow clone depth for submodules. Git will only download recent history of the project, saving time and disk space.

If given, checkout the revision to build as HEAD on the named branch. If value is an empty string or "**", then the branch name is computed from the remote branch without the origin. In that case, a remote branch 'origin/master' will be checked out to a local branch named 'master', and a remote branch 'origin/develop/new-feature' will be checked out to a local branch named 'develop/new-feature'. If a specific revision and not branch HEAD is checked out, then 'detached' will be used as the local branch name.

Clean the workspace after every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. Resets all tracked files to their versioned state. Ensures that the workspace is in the same state as if clone and checkout were performed in a new workspace. Reduces the risk that current build will be affected by files generated by prior builds. Does not remove files outside the workspace (like temporary files or cache files). Does not remove files in the .git repository of the workspace.

Clean the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. Resets all tracked files to their versioned state. Ensures that the workspace is in the same state as if cloned and checkout were performed in a new workspace. Reduces the risk that current build will be affected by files generated by prior builds. Does not remove files outside the workspace (like temporary files or cache files). Does not remove files in the .git repository of the workspace.

Specify the paths that you’d like to sparse checkout. This may be used for saving space (Think about a reference repository). Be sure to use a recent version of Git, at least above 1.7.10.

Multiple sparse checkout path values can be added to a single job.

'Calculate changelog against a specific branch' uses the specified branch to compute the changelog instead of computing it based on the previous build. This extension can be useful for computing changes related to a known base branch, especially in environments which do not have the concept of a "pull request".

The git plugin polls remotely using ls-remote when configured with a single branch (no wildcards!). When this extension is enabled, the polling is performed from a cloned copy of the workspace instead of using ls-remote.

If this option is selected, polling will use a workspace instead of using ls-remote.

By default, the plugin polls by executing a polling process or thread on the Jenkins controller. If the Jenkins controller does not have a git installation, the administrator may enable JGit to use a pure Java git implementation for polling. In addition, the administrator may need to disable command line git to prevent use of command line git on the Jenkins controller.

These options allow you to perform a merge to a particular branch before building. For example, you could specify an integration branch to be built, and to merge to master. In this scenario, on every change of integration, Jenkins will perform a merge with the master branch, and try to perform a build if the merge is successful. It then may push the merge back to the remote repository if the Git Push post-build action is selected.

If set and Jenkins is configured to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build should be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user. Using this behavior prevents the faster git ls-remote polling mechanism. It forces polling to require a workspace, as if you had selected the Force polling using workspace extension.

Each exclusion uses exact string comparison and must be separated by a new line.
User names are only excluded if they exactly match one of the names in this list.

If set and Jenkins is configured to poll for changes, Jenkins will pay attention to included and/or excluded files and/or folders when determining if a build needs to be triggered.

Using this behavior will preclude the faster remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user. Using this behavior will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace, as if you had selected the Force polling using workspace extension as well.

Each inclusion uses java regular expression pattern matching, and must be separated by a new line. An empty list implies that everything is included.

Excluded Regions

Each exclusion uses java regular expression pattern matching, and must be separated by a new line. An empty list excludes nothing.

If set and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to the regular expression pattern when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct message. You can create more complex patterns using embedded flag expressions.

When you are interested in using a job to build multiple branches, you can choose how Jenkins chooses the branches to build and the order they should be built.

This extension point in Jenkins is used by many other plugins to control the job as it builds specific commits. When you activate those plugins, you may see them installing a custom build strategy.

The maximum age of a commit (in days) for it to be built. This uses the GIT_COMMITTER_DATE, not GIT_AUTHOR_DATE

Commit in Ancestry

If an ancestor commit (SHA-1) is provided, only branches with this commit in their history will be built.

Default

Build all the branches that match the branch name pattern.

Inverse

Build all branches except for those which match the branch specifiers configure above. This is useful, for example, when you have jobs building your master and various release branches and you want a second job which builds all new feature branches. For example, branches which do not match these patterns without redundantly building master and the release branches again each time they change.

Name of the repository, such as origin, that contains the branch. If left blank, it’ll default to the name of the first repository configured.

Branch to merge to

The name of the branch within the named repository to merge to, such as master.

Merge strategy

Merge strategy selection. Choices include:

default

resolve

recursive

octopus

subtree

recursive_theirs

--ff: fast-forward which gracefully falls back to a merge commit when required

-ff-only: fast-forward without any fallback

--no-ff: merge commit always, even if a fast-forward would have been allowed

Defines the user name value which git will assign to new commits made in the workspace. If given, the environment variables GIT_COMMITTER_NAME and GIT_AUTHOR_NAME are set for builds and override values from the global settings.

user.email

Defines the user email value which git will assign to new commits made in the workspace. If given, the environment variables GIT_COMMITTER_EMAIL and GIT_AUTHOR_EMAIL are set for builds and override values from the global settings.

An experiment was created many years ago that attempted to create combinations of submodules within the Jenkins job. The experiment was never available to Freestyle projects or other legacy projects like multi-configuration projects. It was visible in Pipeline, configuration as code, and JobDSL.

The implementation of the experiment has been removed. Dependabot and other configuration tools are better suited to evaluate submodule combinations.

There are no known uses of the submodule combinator and no open Jira issues reported against the submodule combinator. Those who were using submodule combinator should remain with git plugin versions prior to 4.6.0.

The submodule combinator ignores any user provided value of the following arguments to git’s checkout scm:

A boolean that is now always set to false. Submodule configurations are no longer evaluated by the git plugin.

submoduleCfg

A list of submodule names and branches that is now always empty. Submodule configurations are no longer evaluated by the git plugin.

checkout([$class: 'GitSCM',
    branches: [[name: 'master']],
    doGenerateSubmoduleConfigurations: false,
    extensions: [],
    submoduleCfg: [],
    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin']]])

SHA-1 of the commit used in the preceding build of this project. If this is the first time a particular branch is being built, this variable is not set.

GIT_PREVIOUS_SUCCESSFUL_COMMIT

SHA-1 of the commit used in the most recent successful build of this project. If this is the first time a particular branch is being built, this variable is not set.

Some Jenkins plugins (like email extension, build name setter, and description setter) allow parameterized references to reformat the text of supported variables. Variables that support parameterized references to reformat their text are called "token macros". The git plugin provides token macros for:

integer length of the commit ID that should be displayed. ${GIT_REVISION} might expand to a806ba7701bcfc9f784ccb7854c26f03e045c1d2, while ${GIT_REVISION,length=8} would expand to a806ba77.

GIT_BRANCH

Expands to the name of the branch that was built.

boolean that expands to all branch names that point to the current commit when enabled. By default, the token expands to just one of the branch names

fullName

boolean that expands to the full branch name, such as remotes/origin/master or origin/master. Otherwise, it expands to the short name, such as master.

The most common use of token macros is in Freestyle projects. Jenkins Pipeline supports a rich set of string operations so that token macros are not generally used in Pipelines.

When used with Pipeline, the token macro base values are generally assigned by the first checkout performed in a Pipeline. Subsequent checkout operations do not modify the values of the token macros in the Pipeline.

Command line git is the reference git implementation in the git plugin and the git client plugin. Command line git provides the most functionality and is the most stable implementation. Some installations may not want to install command line git and may want to disable the command line git implementation. Administrators may disable command line git with the property org.jenkinsci.plugins.gitclient.Git.useCLI=false.

Command line git and JGit can fetch a repository using a local URL (like file:/my/repo.git) or a path (like /my/repo.git). SECURITY-2478 notes that fetching from a local URL or a path creates a security vulnerability on the Jenkins controller. Current releases of the git plugin disallow fetch from a local URL and from a path. If a local URL or a path is required and administrators accept the risk of disabling this security safeguard, the Java property hudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT=true can be set from the command line that starts the Jenkins controller.

Multibranch Pipelines that use the Git branch source will create cached git repositories on the Jenkins controller. By default, the cached git repositories are stored in the caches subdirectory of the Jenkins home directory (JENKINS_HOME).

Administrators may want to store those git repositories in another location for better performance or to exclude them from backups. For example, they might choose to place the cache directories in /var/cache/jenkins.

The default git cache directory location can be overridden by setting the property jenkins.plugins.git.AbstractGitSCMSource.cacheRootDir=/var/cache/jenkins.

The Jenkins git plugin provides a "git publisher" as a post-build action. The git publisher can push commits or tags from the workspace of a Freestyle project to the remote repository.

The git publisher is only available for Freestyle projects. It is not available for Pipeline, Multibranch Pipeline, Organization Folder, or any other job type other than Freestyle.

Git Publisher Options

The git publisher behaviors are controlled by options that can be configured as part of the Jenkins job. Options include;

Git refuses to replace a remote commit with a different commit. This prevents accidental overwrite of new commits on the remote repository. However, there may be times when overwriting commits on the remote repository is acceptable and even desired. If the commits from the local workspace should overwrite commits on the remote repository, enable this option. It will request that the remote repository destroy history and replace it with history from the workspace.

Name of the tag to be pushed from the local workspace to the remote repository. The name may include Jenkins environment variables or may be a fixed string. For example, the tag to push might be $BUILD_TAG, my-tag-$BUILD_NUMBER, build-$BUILD_NUMBER-from-$NODE_NAME, or a-very-specific-string-that-will-be-used-once.

Tag message

If the option is selected to create a tag or update a tag, then this message will be associated with the tag that is created. The message will expand references to Jenkins environment variables. For example, the message Build $BUILD_NUMBER tagged on $NODE_NAME will use the message Build 1 tagged on special-agent if build 1 of the job runs on an agent named 'special-agent'.

Create new tag

Create a new tag in the workspace. The git publisher will fail the job if the tag already exists.

Update new tag

Modify existing tag in the workspace so that it points to the most recent commit. Many git repository hosting services will reject attempts to push a tag which has been modified to point to a different commit than its original commit. Refer to force push for an option which may force the remote repository to accept a modified tag. The git documentation strongly advises against updating tags.

Tag remote name

Git uses the 'remote name' as a short string replacement for the full URL of the remote repository. This option defines which remote should receive the push. This is typically origin, though it could be any one of the remote names defined when the plugin performs the checkout.

The name of the remote branch that will receive the latest commits from the agent workspace. This is usually the same branch that was used for the checkout

Target remote name

The short name of the remote that will receive the latest commits from the agent workspace. Usually this is origin. It needs to be a short name that is defined in the agent workspace, either through the initial checkout or through later configuration.

Rebase before push

Some Jenkins jobs may be blocked from pushing changes to the remote repository because the remote repository has received new commits since the start of the job. This may happen with projects that receive many commits or with projects that have long running jobs. The Rebase before push option fetches the most recent commits from the remote repository, applies local changes over the most recent commits, then pushes the result. The plugin uses git rebase to apply the local changes over the most recent remote changes.

Because Rebase before push is modifying the commits in the agent workspace after the job has completed, it is creating a configuration of commits that has not been evaluated by any Jenkins job. The commits in the local workspace have been evaluated by the job. The most recent commits from the remote repository have not been evaluated by the job. Users may find that the risk of pushing an untested configuration is less than the risk of delaying the visibility of the changes which have been evaluated by the job.

$ cd multirepository-cache.git $ git init --bare $ git remote add parent https://github.com/jenkinsci/git-plugin $ git remote add child-1 https://github.com/jenkinsci/git-client-plugin $ git remote add child-2 https://github.com/jenkinsci/platformlabeler-plugin $ git fetch --all

Those commands create a single bare repository with the current commits from all three repositories. If that reference repository is used in the advanced clone options clone reference repository, it will reduce data transfer and disc use for the parent repository. If that reference repository is used in the submodule options clone reference repository, it will reduce data transfer and disc use for the submodule repositories.

The git plugin has an issue (JENKINS-19022) that sometimes causes excessive memory use and disc use in the build history of a job. The problem occurs because in some cases the git plugin copies the git build data from previous builds to the most recent build, even though the git build data from the previous build is not used in the most recent build. The issue can be especially challenging when a job retains a very large number of historical builds or when a job builds a wide range of commits during its history.

Multiple attempts to resolve the core issue without breaking compatibility have been unsuccessful. A workaround is provided below that will remove the git build data from the build records. The workaround is a system groovy script that needs to be run from the Jenkins Administrator’s Script Console (as in https://jenkins.example.com/script ). Administrator permission is required to run system groovy scripts.

This script removes the static list of BuildsByBranch that is stored for each build by the Git Plugin.

hudsonInstance = hudson.model.Hudson.instance jobNames = hudsonInstance.getJobNames() allItems = [] for (name in jobNames) { allItems += hudsonInstance.getItemByFullName(name) // Iterate over all jobs and find the ones that have a hudson.plugins.git.util.BuildData // as an action. // We then clean it by removing the useless array action.buildsByBranchName for (job in allItems) { println("job: " + job.name); def counter = 0; for (build in job.getBuilds()) { // It is possible for a build to have multiple BuildData actions // since we can use the Mulitple SCM plugin. def gitActions = build.getActions(hudson.plugins.git.util.BuildData.class) if (gitActions != null) { for (action in gitActions) { action.buildsByBranchName = new HashMap<String, Build>(); hudson.plugins.git.Revision r = action.getLastBuiltRevision(); if (r != null) { for (branch in r.getBranches()) { action.buildsByBranchName.put(branch.getName(), action.lastBuild) build.actions.remove(action) build.actions.add(action) build.save(); counter++; if (job instanceof MatrixProject) { def runcounter = 0; for (run in build.getRuns()) { gitActions = run.getActions(hudson.plugins.git.util.BuildData.class) if (gitActions != null) { for (action in gitActions) { action.buildsByBranchName = new HashMap<String, Build>(); hudson.plugins.git.Revision r = action.getLastBuiltRevision(); if (r != null) { for (branch in r.getBranches()) { action.buildsByBranchName.put(branch.getName(), action.lastBuild) run.actions.remove(action) run.actions.add(action) run.save(); runcounter++; if (runcounter > 0) { println(" -->> cleaned: " + runcounter + " runs"); if (counter > 0) { println("-- cleaned: " + counter + " builds");