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

          Don created issue -
          Don made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]
          Mark Waite made changes -
          Attachment New: run-jenkins.sh [ 61046 ]
          Mark Waite made changes -
          Attachment New: plugins.txt [ 61047 ]

          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 made changes -
          Attachment New: image-2023-08-23-08-26-16-529.png [ 61052 ]

          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.

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

              Created:
              Updated:
              Resolved: