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

Document preferred methods to configure notifyCommit access

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • git:5.2.0
      Jenkins 2.401.3.4

      The hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled system property is not working, I am still getting a 401 stating that i have to provide a token.

          [JENKINS-71876] Document preferred methods to configure notifyCommit access

          Mark Waite added a comment - - edited

          I'm not able to duplicate the problem as described. Steps that I took while attempting to duplicate it include:

          • Create a plugins.txt that lists the exact plugins to be installed (including git plugin 5.2.0)
          • Create a run-jenkins.sh script that starts Jenkins 2.401.3 after downloading the plugins listed in plugins.txt
          • Delete the -Dhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled from the run-jenkins.sh script
          • Run the modified run-jenkins.sh script to run Jenkins 2.401.3 with the required plugins
          • Define a freestyle job using https://github.com/MarkEWaite/git-plugin.git as the repository and with poll scm enabled (but with no polling schedule)
          • Run the curl command to confirm that notifyCommit requires an access token
          • Stop the script and insert the -Dhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled command line argument
          • Run the run-jenkins.sh script to start Jenkins again
          • Run the curl command to confirm that notifyCommit does not require an access token when the property is set to disabled

          When I ran that curl command with the property set to the value disabled, the notifyCommit caused the repository to be polled and the job to be built.

          I suspect that the system property is not being set from the Java command line, either because it is being set in the wrong location on the Java command line or is not being passed on the command line in a way that is detected by Jenkins. You can check if the property is set by opening the /manage/systemInfo URL and unhiding all the values. On my system, when the property is set, there is an entry that shows the value of that property.

          Mark Waite added a comment - - edited I'm not able to duplicate the problem as described. Steps that I took while attempting to duplicate it include: Create a plugins.txt that lists the exact plugins to be installed (including git plugin 5.2.0) Create a run-jenkins.sh script that starts Jenkins 2.401.3 after downloading the plugins listed in plugins.txt Delete the -Dhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled from the run-jenkins.sh script Run the modified run-jenkins.sh script to run Jenkins 2.401.3 with the required plugins Define a freestyle job using https://github.com/MarkEWaite/git-plugin.git as the repository and with poll scm enabled (but with no polling schedule) Run the curl command to confirm that notifyCommit requires an access token Stop the script and insert the -Dhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled command line argument Run the run-jenkins.sh script to start Jenkins again Run the curl command to confirm that notifyCommit does not require an access token when the property is set to disabled When I ran that curl command with the property set to the value disabled , the notifyCommit caused the repository to be polled and the job to be built. I suspect that the system property is not being set from the Java command line, either because it is being set in the wrong location on the Java command line or is not being passed on the command line in a way that is detected by Jenkins. You can check if the property is set by opening the /manage/systemInfo URL and unhiding all the values. On my system, when the property is set, there is an entry that shows the value of that property.

          Don added a comment -

          The property is set and being read by Jenkins:

          It is still requiring a token.  This only happens on some controllers.  All of our controllers are configured the same as we use JCasC.

          Don added a comment - The property is set and being read by Jenkins: It is still requiring a token.  This only happens on some controllers.  All of our controllers are configured the same as we use JCasC.

          Mark Waite added a comment -

          Thanks d_kallman. You'll need to provide more details in order to identify the differences between the working and non-working cases. I don't have any additional suggestions to offer on what might be different between the working and the non-working cases.

          Mark Waite added a comment - Thanks d_kallman . You'll need to provide more details in order to identify the differences between the working and non-working cases. I don't have any additional suggestions to offer on what might be different between the working and the non-working cases.

          Don added a comment - - edited

          That's what I figured.  In the meantime, the property should not require a restart correct (set from script console)? I think we tried it both ways. 

          The working and non-working scenarios are not different as far as I can tell.  They are both controllers with multibranch pipelines on them using Git as a branch source and they are both in the same subnet.  Neither one of them has ever had a token, they were both upgraded from 4.11.3 (we were a little behind), and they both should be receiving webhooks from Bitbucket.  Internally, we have advised everyone to change from git branch source to Bitbucket (this was set up before my time).  We are also working with CloudBees support.

          Don added a comment - - edited That's what I figured.  In the meantime, the property should not require a restart correct (set from script console)? I think we tried it both ways.  The working and non-working scenarios are not different as far as I can tell.  They are both controllers with multibranch pipelines on them using Git as a branch source and they are both in the same subnet.  Neither one of them has ever had a token, they were both upgraded from 4.11.3 (we were a little behind), and they both should be receiving webhooks from Bitbucket.  Internally, we have advised everyone to change from git branch source to Bitbucket (this was set up before my time).  We are also working with CloudBees support.

          Mark Waite added a comment -

          In the meantime, the property should not require a restart correct (set from script console)?

          I'm not sure that setting the system property from the script console will work. The system property value is read once when the GitStatus Java class is initialized. I'm not sure if that is before or after system init hooks are processed by groovy.

          With the run-jenkins.sh script described in an earlier comment, I replaced the system property set from the command line with a system property set from the script console. The script console version did not disable the notifyCommit token even though the property is displayed in the system information page.

          You'll need to use a command line property to set that value or the git plugin will need to be extended to read the notifyCommit property value more often. It currently reads it only once when the JVM starts.

          Mark Waite added a comment - In the meantime, the property should not require a restart correct (set from script console)? I'm not sure that setting the system property from the script console will work. The system property value is read once when the GitStatus Java class is initialized. I'm not sure if that is before or after system init hooks are processed by groovy. With the run-jenkins.sh script described in an earlier comment, I replaced the system property set from the command line with a system property set from the script console. The script console version did not disable the notifyCommit token even though the property is displayed in the system information page. You'll need to use a command line property to set that value or the git plugin will need to be extended to read the notifyCommit property value more often. It currently reads it only once when the JVM starts.

          Don added a comment -

          Ok, but why then would setting it from the script console work for some of our controller but not others?  And also, I just tried setting the command line property and it is still asking for a token.  I can see the property on the running JVM.

          Don added a comment - Ok, but why then would setting it from the script console work for some of our controller but not others?  And also, I just tried setting the command line property and it is still asking for a token.  I can see the property on the running JVM.

          Don added a comment -

          I take back the second part.  I see it in the running JVM because i set the system property. I had a syntax error in my java_opts.  This is working if I set the property and restart the controller.

           

          Don added a comment - I take back the second part.  I see it in the running JVM because i set the system property. I had a syntax error in my java_opts.  This is working if I set the property and restart the controller.  

          Mark Waite added a comment -

          The fix for this issue would be to read the value of the system property more frequently. Hopefully, "more frequently" does not mean "too frequently", where "too frequently" would mean "often enough to impact performance on large Jenkins controllers like ci.jenkins.io"

          Mark Waite added a comment - The fix for this issue would be to read the value of the system property more frequently. Hopefully, "more frequently" does not mean "too frequently", where "too frequently" would mean "often enough to impact performance on large Jenkins controllers like ci.jenkins.io"

          HelloWorld added a comment -

          HI, Kindly allow me to work on this issue , thank you !

          HelloWorld added a comment - HI, Kindly allow me to work on this issue , thank you !

          Markus Winter added a comment -

          Do we really have a problem here?

          Setting a system property via script console or init.groovy might be a problem but when we directly set the field in the class in the script console with

          hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL="disabled"

          this should already work I think

          Markus Winter added a comment - Do we really have a problem here? Setting a system property via script console or init.groovy might be a problem but when we directly set the field in the class in the script console with hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL= "disabled" this should already work I think

          Mark Waite added a comment - - edited

          Thanks for an excellent insight mawinter69. The groovy init script syntax that I used to duplicate the problem was setting the system property like this:

          System.setProperty('hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL', 'disabled')
          

          Since the system property is read only once at startup, it did not help to set the system property from groovy, because the hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL variable was initialized before the system property was modified.

          Your suggestion to set the field in the class is much better and works very well. I add the groovy init script line:

          hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL='disabled'
          

          I think that it would help if the git plugin documentation that mentions hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL were extended to more precisely describe the techniques to set the value. It can either be set from the Java command line with

          java -Dhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled jenkins.war
          

          or it can be set from a groovy script in the init.groovy.d directory with a statement like this:

          hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL='disabled'
          

          sirine707 would you like to submit the documentation improvement?

          Mark Waite added a comment - - edited Thanks for an excellent insight mawinter69 . The groovy init script syntax that I used to duplicate the problem was setting the system property like this: System .setProperty( 'hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL' , 'disabled' ) Since the system property is read only once at startup, it did not help to set the system property from groovy, because the hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL variable was initialized before the system property was modified. Your suggestion to set the field in the class is much better and works very well. I add the groovy init script line: hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL= 'disabled' I think that it would help if the git plugin documentation that mentions hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL were extended to more precisely describe the techniques to set the value. It can either be set from the Java command line with java -Dhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled jenkins.war or it can be set from a groovy script in the init.groovy.d directory with a statement like this: hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL= 'disabled' sirine707 would you like to submit the documentation improvement?

          HelloWorld added a comment -

          markewaite yes I work on it , will the update include only README file of git-plugin or jenkins.io official website too ? 

          HelloWorld added a comment - markewaite yes I work on it , will the update include only README file of git-plugin or jenkins.io official website too ? 

          Mark Waite added a comment -

          Plugin readme is enough. It will then be automatically updated on the plugins.jenkins.io page.

          Mark Waite added a comment - Plugin readme is enough. It will then be automatically updated on the plugins.jenkins.io page.

            sirine707 HelloWorld
            d_kallman Don
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: