Bitbucket hook triggers build on first push on */master, but not later ones

Using Jenkins
1

I have installed OpenJDK-11-JRE

$ java -version
openjdk version "11.0.15" 2022-04-19 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.15+9-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.15+9-LTS, mixed mode, sharing)

I have set up a webhook from a private Bitbucket repository, and configured a build to trigger when a change is pushed to Bitbucket. After setting up the project for the first time and pushing to Bitbucket, the build triggers fine (i.e. the authentication works), however on subsequent pushes I get this error:

Started on Jun 16, 2022, 2:33:08 AM
Using strategy: Default
[poll] Last Built Revision: Revision 396117b48ff8f3ca106995ba9b7e09dee1620377 (refs/remotes/origin/master)
The recommended git tool is: NONE
using credential 7ecfabd5-0e19-4294-882c-cc3f53386dc9
 > git --version # timeout=10
 > git --version # 'git version 1.8.3.1'
using GIT_ASKPASS to set credentials 
 > git ls-remote -h https://<myorganisation>@bitbucket.org/<myorganisation>/<reponame>.git # timeout=10
FATAL: hudson.plugins.git.GitException: Command "git ls-remote -h https://<myorganisation>@bitbucket.org/<myorganisation>/<reponame>.git" returned status code 128:
stdout: 
stderr: fatal: cannot exec '/tmp/jenkins-gitclient-pass13876777631166062367.sh': Permission denied
fatal: could not read Password for 'https://<myorganisation>@bitbucket.org': No such device or address

hudson.plugins.git.GitException: Command "git ls-remote -h https://<myorganisation>@bitbucket.org/<myorganisation>/<reponame>.git" returned status code 128:
stdout: 
stderr: fatal: cannot exec '/tmp/jenkins-gitclient-pass13876777631166062367.sh': Permission denied
fatal: could not read Password for 'https://<myorganisation>@bitbucket.org': No such device or address

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2671)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2096)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1996)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1987)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:3547)
	at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:732)
	at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:691)
Caused: java.io.IOException
	at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:693)
	at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:419)
	at hudson.scm.SCM.poll(SCM.java:436)
	at hudson.model.AbstractProject._poll(AbstractProject.java:1396)
	at hudson.model.AbstractProject.poll(AbstractProject.java:1302)
	at com.cloudbees.jenkins.plugins.BitBucketTriggerRunnable.runPolling(BitBucketTriggerRunnable.java:46)
	at com.cloudbees.jenkins.plugins.BitBucketTriggerRunnable.run(BitBucketTriggerRunnable.java:89)
	at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:123)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Done. Took 0.57 sec
No changes

What’s weird is that if I leave the branch specifier blank, I can then trigger builds with pushes to master, but then I’m obviously going to trigger a build when any branch is committed to which I don’t want.

2

I’ve discovered a hacky work-around. If I add a secondary branch to build alongside */master, it works, even if the named secondary branch doesn’t exist. Would still be interested in a better solution if anyone knows though.