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?
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.