Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-41906

Abort Job if no change in defined branch (e.g. master)

      If the GIT plugin pulls the latest version from the defined branch and there is no change, the following build steps should not be executed and the jenkins job should be aborted with status SUCCESS.

      Reason: When using webhooks (Bitbucket), jobs get triggered by any commit to any branch. So the job for master branch is triggered all the time and runs through although there was no change to it.

          [JENKINS-41906] Abort Job if no change in defined branch (e.g. master)

          Mark Waite added a comment -

          If the master branch is being built repeatedly even though there is no change in it, that is a bug. Please provide step by step instructions to duplicate that bug.

          Mark Waite added a comment - If the master branch is being built repeatedly even though there is no change in it, that is a bug. Please provide step by step instructions to duplicate that bug.

          Justus Someo added a comment - - edited

          1. Set up GIT plugin in your Job to your repo (Bitbucket in our case):

          <repo URL / credentials>
          Name: origin
          Refspec: +refs/heads/Jenkins_test:refs/remotes/origin/Jenkins_test  (can also be empty)
          
          Branches to build:
             Branch: */Jenkins_test
              
          Repo browser: (Auto)
          

          2. Add build step "Execute shell":

           echo "Test"
          

          3. Save and run Job (multiple times) from Jenkins. Notice that Job always prints "Test", but there are no entries in Jenkins's "Changes"

          ------------------------

          This is how I test it currently, because I don't want to spam master branch with test commits. But from my understanding this should make no difference if it's master or some other branch.

          Justus Someo added a comment - - edited 1. Set up GIT plugin in your Job to your repo (Bitbucket in our case): <repo URL / credentials> Name: origin Refspec: +refs/heads/Jenkins_test:refs/remotes/origin/Jenkins_test (can also be empty) Branches to build: Branch: */Jenkins_test Repo browser: (Auto) 2. Add build step "Execute shell": echo "Test" 3. Save and run Job (multiple times) from Jenkins. Notice that Job always prints "Test", but there are no entries in Jenkins's "Changes" ------------------------ This is how I test it currently, because I don't want to spam master branch with test commits. But from my understanding this should make no difference if it's master or some other branch.

          Justus Someo added a comment - - edited

          My console output:

          Building in workspace /var/lib/jenkins/workspace/Test_git
           > git rev-parse --is-inside-work-tree # timeout=10
          Fetching changes from the remote Git repository
           > git config remote.origin.url https://*************** # timeout=10
          Fetching upstream changes from https://***********************
           > git --version # timeout=10
          using GIT_ASKPASS to set credentials 
          Setting http proxy: 127.0.0.1:3128
           > git fetch --tags --progress https://************* +refs/heads/*:refs/remotes/origin/*
           > git rev-parse refs/remotes/origin/Jenkins_test^{commit} # timeout=10
           > git rev-parse refs/remotes/origin/origin/Jenkins_test^{commit} # timeout=10
          Checking out Revision dc123e87a5987e21cdd2d5db2227cd3a77717bf2 (refs/remotes/origin/Jenkins_test)
           > git config core.sparsecheckout # timeout=10
           > git checkout -f dc123e87a5987e21cdd2d5db2227cd3a77717bf2
           > git rev-list dc123e87a5987e21cdd2d5db2227cd3a77717bf2 # timeout=10
          [Test_git] $ /bin/bash -xe /tmp/hudson7762506148806493829.sh
          + echo test
          test
          Finished: SUCCESS
          

          Justus Someo added a comment - - edited My console output: Building in workspace / var /lib/jenkins/workspace/Test_git > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https: //*************** # timeout=10 Fetching upstream changes from https: //*********************** > git --version # timeout=10 using GIT_ASKPASS to set credentials Setting http proxy: 127.0.0.1:3128 > git fetch --tags --progress https: //************* +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/Jenkins_test^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/Jenkins_test^{commit} # timeout=10 Checking out Revision dc123e87a5987e21cdd2d5db2227cd3a77717bf2 (refs/remotes/origin/Jenkins_test) > git config core.sparsecheckout # timeout=10 > git checkout -f dc123e87a5987e21cdd2d5db2227cd3a77717bf2 > git rev-list dc123e87a5987e21cdd2d5db2227cd3a77717bf2 # timeout=10 [Test_git] $ /bin/bash -xe /tmp/hudson7762506148806493829.sh + echo test test Finished: SUCCESS

          Mark Waite added a comment - - edited

          I'm unable to duplicate the problem you're reporting, either with a freestyle job, nor with a pipeline job. The environment I'm using to duplicate the problem can be reconstructed with the following steps:

          1. Clone, build, and run the docker instance
              $ git clone https://github.com/MarkEWaite/docker JENKINS-41906
              $ cd JENKINS-41906
              $ git checkout -b lts-with-plugins 43617aecbb2ad5250460bdbf2c5d3b6fbdc37e94
              $ docker build -t jenkins:JENKINS-41906 .
              $ # Copy jdk8 from Oracle to ~/public_html/jdk/jdk-8u121-linux-x64.tar.gz
              $ # Copy ant-1.9.8 from Apache to ~/public_html/ant/apache-ant-1.9.8-bin.zip
              $ docker run -i --rm \
                  --publish 8080:8080 \
                  --volume ~/public_html/:/var/jenkins_home/userContent/ \
                  jenkins:JENKINS-41906
            
          2. Connect a web browser to that docker instance (http://localhost:8080)
          3. Open the "Bugs - Individual Checks" folder
          4. Open the "JENKINS-41906-master-branch-builds-without-change" job
          5. Click "Poll now" (simulate the web hook), confirm that the job builds (because it has not been built before)
          6. Click "Poll now" (simulate the web hook again), confirm that the job does not build (already built)

          I also checked it with a pipeline job in that same Docker instance. You can see the behavior in the pipeline job with the following steps:

          1. Open the "Bugs - Pipeline Checks" folder
          2. Open the "jenkins-bugs" pipeline job
          3. Click the "Scan Multibranch Pipeline" link and "Run Now" to index branches for that repository
          4. Confirm that a job is created and built for the "master" branch and all other branches
          5. Wait 10-15 minutes, then Click the "Scan Multibranch Pipeline" link and "Run Now" to index branches again for that repository. That will likely detect changes on one of the branches, since I usually have tests running somewhere that will commit to that repository
          6. Confirm that the job named "master" did not rebuild, even though other jobs rebuilt due to changes in them

          Can you provide more details of the steps to duplicate the problem you're seeing?

          Are you using a freestyle job, a multi-configuration job, a pipeline job, a multi-branch pipeline job, or some other type of job?

          Are there other details of your environment which I missed in my attempt to duplicate the problem?

          Mark Waite added a comment - - edited I'm unable to duplicate the problem you're reporting, either with a freestyle job, nor with a pipeline job. The environment I'm using to duplicate the problem can be reconstructed with the following steps: Clone, build, and run the docker instance $ git clone https: //github.com/MarkEWaite/docker JENKINS-41906 $ cd JENKINS-41906 $ git checkout -b lts-with-plugins 43617aecbb2ad5250460bdbf2c5d3b6fbdc37e94 $ docker build -t jenkins:JENKINS-41906 . $ # Copy jdk8 from Oracle to ~/public_html/jdk/jdk-8u121-linux-x64.tar.gz $ # Copy ant-1.9.8 from Apache to ~/public_html/ant/apache-ant-1.9.8-bin.zip $ docker run -i --rm \ --publish 8080:8080 \ --volume ~/public_html/:/ var /jenkins_home/userContent/ \ jenkins:JENKINS-41906 Connect a web browser to that docker instance ( http://localhost:8080 ) Open the "Bugs - Individual Checks" folder Open the " JENKINS-41906 -master-branch-builds-without-change" job Click "Poll now" (simulate the web hook), confirm that the job builds (because it has not been built before) Click "Poll now" (simulate the web hook again), confirm that the job does not build (already built) I also checked it with a pipeline job in that same Docker instance. You can see the behavior in the pipeline job with the following steps: Open the "Bugs - Pipeline Checks" folder Open the "jenkins-bugs" pipeline job Click the "Scan Multibranch Pipeline" link and "Run Now" to index branches for that repository Confirm that a job is created and built for the "master" branch and all other branches Wait 10-15 minutes, then Click the "Scan Multibranch Pipeline" link and "Run Now" to index branches again for that repository. That will likely detect changes on one of the branches, since I usually have tests running somewhere that will commit to that repository Confirm that the job named "master" did not rebuild, even though other jobs rebuilt due to changes in them Can you provide more details of the steps to duplicate the problem you're seeing? Are you using a freestyle job, a multi-configuration job, a pipeline job, a multi-branch pipeline job, or some other type of job? Are there other details of your environment which I missed in my attempt to duplicate the problem?

          Ralph A added a comment - - edited

          someid When did this issue start happening? I can see that you filed the bug on Feb 10th so it is safe to assume that it showed up around that time? Did you upgrade any of the plugins besides Git? I am asking because I am facing a similar/same issue.

          I usually push my changes to my Github repo which triggers a webhook and causes Jenkins to poll for changes ONLY for that specific branch. I noticed this part of the workflow broken on Monday the 13th but it was still working on the Friday the 10th. I do not remember changing anything in my configuration over the weekend but I might have updated some plugins on Friday, that's why I am asking if you upgraded any of the plugins besides Git.

          The bug I reported for the same/similar issue that you are having can be seen here: JENKINS-42020

          Ralph A added a comment - - edited someid When did this issue start happening? I can see that you filed the bug on Feb 10th so it is safe to assume that it showed up around that time? Did you upgrade any of the plugins besides Git? I am asking because I am facing a similar/same issue. I usually push my changes to my Github repo which triggers a webhook and causes Jenkins to poll for changes ONLY for that specific branch. I noticed this part of the workflow broken on Monday the 13th but it was still working on the Friday the 10th. I do not remember changing anything in my configuration over the weekend but I might have updated some plugins on Friday, that's why I am asking if you upgraded any of the plugins besides Git. The bug I reported for the same/similar issue that you are having can be seen here: JENKINS-42020

          Justus Someo added a comment - - edited

          Hey,

          this issue was there from the beginning I started with Jenkins (around December last year). I just happened to make this request after I tested all there was and after the GIT plugin update didn't fix this.

          Btw. I use Jenkins 2.40. Is there a possibility that this is the cause of this behavior?

          Edit: I just updated to version 2.46 and it's still behaving like this.

          Justus Someo added a comment - - edited Hey, this issue was there from the beginning I started with Jenkins (around December last year). I just happened to make this request after I tested all there was and after the GIT plugin update didn't fix this. Btw. I use Jenkins 2.40. Is there a possibility that this is the cause of this behavior? Edit: I just updated to version 2.46 and it's still behaving like this.

            Unassigned Unassigned
            someid Justus Someo
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: