Bitbucket webhook generating build on the wrong GIT repository - jenkins

Question

I want to trigger a pipeline on my OpenShift when an event occurs on bitbucket (push for example). I configured a webhook correctly following the instructions on Openshift documentation pages. Although I had to change my Openshift template of my pipeline which generated some conflicts.
The BuildConfig looks like this:
- apiVersion: "v1"
kind: "BuildConfig"
metadata:
name: "${SERVICE_NAME}-pipeline"
spec:
source:
contextDir: '${APPLICATION_GIT_JENKINSFILE_REPO_CONTEXT_DIR}'
git:
ref: master
uri: '${APPLICATION_GIT_JENKINSFILE_REPO}'
sourceSecret:
name: git-secret
type: Git
strategy:
jenkinsPipelineStrategy:
jenkinsfilePath: Jenkinsfile
triggers:
type: "Bitbucket"
bitbucket:
secretReference:
name: "mysecret"
So, on the 'source' component I reference a git repository where my Jenkinsfile is located. This way I can have many pipelines with only a single Jenkinsfile centralized. Note that this repo is completly different from the location of the api where I'm configuring the webhook.
This approach although fails on an automatic trigger due to the fact that the payload sent to the Openshift has the commit id of the changes of the respective api repository. Openshift (I don't know why) tries to associate that commit with the repo that is present on this template (Jenkinsfile repo).
The logs are the following:
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://jenkinsfile-repo.git # timeout=10
Fetching upstream changes from http://jenkinsfile-repo.git
> git --version # timeout=10
using GIT_ASKPASS to set credentials git-secret
> git fetch --tags --progress http://jenkinsfile-repo.git +refs/heads/*:refs/remotes/origin/*
> git rev-parse 79370e4fa88f19c693d85d82fbdbed77620d048b^{commit} # timeout=10
hudson.plugins.git.GitException: Command "git rev-parse 79370e4fa88f19c693d85d82fbdbed77620d048b^{commit}" returned status code 128:
stdout: 79370e4fa88f19c693d85d82fbdbed77620d048b^{commit}
stderr: fatal: ambiguous argument '79370e4fa88f19c693d85d82fbdbed77620d048b^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2016)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1984)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1980)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1612)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1624)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:809)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at hudson.plugins.git.RevisionParameterAction.toRevision(RevisionParameterAction.java:98)
at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1070)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1187)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:144)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE
There we can see the behavior I tried to explain, the '79370e4fa88f19c693d85d82fbdbed77620d048b' was the commit id on the api repo, which OpenShift is trying to associate with the jenkinsfile repo.
If I could for example ignore the payload the problem wouldn't exist.
Thanks for the help.

Answer 1

I don't think you require put type: git(duplicate) and also try using https:// bitbucket url,
source:
contextDir: '${APPLICATION_GIT_JENKINSFILE_REPO_CONTEXT_DIR}'
git:
ref: master
uri: '${APPLICATION_GIT_JENKINSFILE_REPO}'
sourceSecret:
name: git-secret
type: Git *****remove and try ?

Answer 2

I managed to implement a workaround, although I still don't understand why the behavior I specified previously occurs.
Basically the current solution looks like this:
The openshift template references the GIT repository of the respective API, and that repository has a Jenkinsfile of his own, which is the same for every API. Although, the only thing this Jenkinsfile does is to call a groovy script that is centralized in a separate GIT repository and is declared as a shared library in Jenkins.
This way if we must change something, a stage of a pipeline for example, we only need to change in a single location, which was the objective from the begginning.