I have a jenkins job that runs when code is pushed to `master` and `develop` branch. This job also picks up PRs. This job also has `sha1` as a build parameter to trigger builds manually.

      The job picks up PRs and builds them. Same with pushes to `master` or `develop`. The issue is when The job is triggered manually. It seems to pickup a random branch. sometimes a PR, sometimes `origin/develop`. The GIT_BRANCH environment variable is overwritten with some other branch and not sha1.

      *Job config*
      ````
      build parameters: sha1 (default value: origin/<branchName>) so technically, the job should fail as there is no branch called `origin/<branchName>`
      Branches to build -1 : origin/master
      Branches to build - 2: origin/develop
      Branches to build - 3: ${sha1}
      Refspec: +refs/heads/*:refs/remotes/origin/* +refs/pull/*:refs/remotes/origin/pr/*

      • [√ ] Build when a change is pushed to GitHub
      • [√ ] GitHub Pull Request Builder
        ````

      *Jenkins and plugin versions*
      ````
      jenkins version: 2.7.1

      Git client plugin: 2.0.0
      Git plugin: 3.0.0
      GitHub API Plugin: 1.77
      GitHub plugin: 1.21.1
      GitHub Pull Request Builder: 1.33.1
      ````

          [JENKINS-38406] GIT_BRANCH wrongly set.

          I submitted pull request #442 that helped me to solve this issue for our use case. I am not sure if this solution is acceptable to you. I have my changes running in production for our CI builds that were affected by this situation. In my case I had two distinct types of issues both stemming from this behavior of the Git plugin.

          One case was a GitSCM multi-branch job that was servicing as a packaging job for our product. We use Gradle to build the final Debian assembly and this job was designed to run using a maintenance branch or master branch. We envision having multiple maintenance branches eventually so this could become a harder problem later on. Our Gradle builds use hints to select the correct artifacts to assemble the Debian package.

          The job in question needs to be executed when the specific branch is changed because the Gradle build script is adjusted for new or changed artifacts entering the assembly or manually when the dependencies for the job have been updated releasing new versions. The way we accomplish this with the proposed change is setting a choice parameter to the job. The default value for the choice parameter is blank which as you see in this pull request results in the default behavior of the GitSCM plugin. This allows commit notifications or Git polling to work as expected. When the user triggering the job selects the alternate choices which are git branch names the changes here will direct the git plugin to build the selected branch instead of the last successful build. The same parameter can be used when this is triggered by an upstream job using the parameterized trigger build step or post build action.

          The other case we encountered is when in the same situation we required builds of modules out of separate git repositories to build as downstream triggered jobs. The branches in these repositories are in the same master or maintenance branch setup even across the distinct git repositories. We use this to allow components of the product to have independent source control but follow same release cycles. It is desirable for a dependency to trigger a build of the consumer when it changes. But in this case we want to trigger a build of the matching release stream branch, either the development stream or a maintenance branch. The parameterized trigger is now able to hint the desired branch to the downstream job even if this job is executing against a different git repository, the only requirement is that the branch names are matching.

          Alexander Volanis added a comment - I submitted pull request #442 that helped me to solve this issue for our use case. I am not sure if this solution is acceptable to you. I have my changes running in production for our CI builds that were affected by this situation. In my case I had two distinct types of issues both stemming from this behavior of the Git plugin. One case was a GitSCM multi-branch job that was servicing as a packaging job for our product. We use Gradle to build the final Debian assembly and this job was designed to run using a maintenance branch or master branch. We envision having multiple maintenance branches eventually so this could become a harder problem later on. Our Gradle builds use hints to select the correct artifacts to assemble the Debian package. The job in question needs to be executed when the specific branch is changed because the Gradle build script is adjusted for new or changed artifacts entering the assembly or manually when the dependencies for the job have been updated releasing new versions. The way we accomplish this with the proposed change is setting a choice parameter to the job. The default value for the choice parameter is blank which as you see in this pull request results in the default behavior of the GitSCM plugin. This allows commit notifications or Git polling to work as expected. When the user triggering the job selects the alternate choices which are git branch names the changes here will direct the git plugin to build the selected branch instead of the last successful build. The same parameter can be used when this is triggered by an upstream job using the parameterized trigger build step or post build action. The other case we encountered is when in the same situation we required builds of modules out of separate git repositories to build as downstream triggered jobs. The branches in these repositories are in the same master or maintenance branch setup even across the distinct git repositories. We use this to allow components of the product to have independent source control but follow same release cycles. It is desirable for a dependency to trigger a build of the consumer when it changes. But in this case we want to trigger a build of the matching release stream branch, either the development stream or a maintenance branch. The parameterized trigger is now able to hint the desired branch to the downstream job even if this job is executing against a different git repository, the only requirement is that the branch names are matching.

            Unassigned Unassigned
            puneeth_n Puneeth Nanjundaswamy
            Votes:
            6 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: