diff --git a/content/en/community/code/continuous-integrating-jx-itself.md b/content/en/community/code/continuous-integrating-jx-itself.md
index f264d9cc3a4..6e66f51737b 100644
--- a/content/en/community/code/continuous-integrating-jx-itself.md
+++ b/content/en/community/code/continuous-integrating-jx-itself.md
@@ -11,9 +11,9 @@ aliases:
 You may be wondering how Jenkins X introduce changes to Jenkins X. Of course, Jenkins X is built using Jenkins X itself! That means that new changes to the project go through a CI process, and are built and tested using pipelines that run on a Jenkins X Kubernetes cluster.
 
 ## Pipelines
-A Pull Request in the [jx repository](https://github.com/jenkins-x/jx) will automatically trigger some jobs to do CI. The jobs are triggered [by Prow](/docs/reference/components/prow/), and we can [configure which jobs to execute](https://github.com/jenkins-x/prow-config-tekton/blob/f1a74a38c2936722f8507769e5a30b56ca96fe45/prow/config.yaml#L902-L932). The jobs with always_run configured to be true, will be ran when the PR is opened. All jobs (independently of having always_run set to true or false) can be manually triggered writing a comment in the PR. The comment needed to trigger the job is also in the configuration, in the trigger key. For example, to trigger the end-to-end tests manually, you may write a new comment in the PR containing "/test bdd", and the bdd job will be triggered.
+A Pull Request in the [jx repository](https://github.com/jenkins-x/jx) will automatically trigger some jobs to do CI. The jobs are triggered [by Lighthouse](https://github.com/jenkins-x/lighthouse), and we can [configure which jobs to execute](https://github.com/jenkins-x/jx/blob/main/.lighthouse/jenkins-x/triggers.yaml). The jobs with always_run configured to be true, will be ran when the PR is opened. All jobs (independently of having always_run set to true or false) can be manually triggered writing a comment in the PR. The comment needed to trigger the job is also in the configuration, in the trigger key. For example, to trigger the end-to-end tests manually, you may write a new comment in the PR containing "/test bdd", and the bdd job will be triggered.
 
-The jobs all have a name and a context [in the configuration](https://github.com/jenkins-x/prow-config-tekton/blob/f1a74a38c2936722f8507769e5a30b56ca96fe45/prow/config.yaml#L902-L932). The name is the name what will show up on GitHub, and the context is the Jenkins X pipeline to execute.
+The jobs all have a name and a context in the configuration. The name is the name what will show up on GitHub, and the context is the Jenkins X pipeline to execute.
 
 ![Jobs executed during CI](/images/contribute/ci-jobs.png)
 
@@ -28,7 +28,7 @@ Following our bdd pipeline example, here are the steps executed as part of [the
 ## End to end tests
 For the e2e tests, the application binary is compiled with the changes on the pull request so that the tests use these changes. Docker images are also published to Google Cloud Registry (GCR) with the changes on the pull request, so testing locally is easier.
 
-[The e2e tests live on a different repository](https://github.com/jenkins-x/bdd-jx), and they are ran using [a bash script](https://github.com/jenkins-x/jx/blob/master/jx/scripts/ci.sh), that will be executed inside a container (like all the other steps in all the other pipelines). The bash script reads some secrets from the Kubernetes cluster where this job is running, and prepares the container where the step is being ran to run the tests configuring the Git client locally, creating a valid kubeconfig file to be able to talk to a Kubernetes cluster, etc.
+[The e2e tests live on a different repository](https://github.com/jenkins-x/bdd-jx3), and they are ran using [a bash script](https://github.com/jx3-versions/jx/blob/master/jx/scripts/ci.sh), that will be executed inside a container (like all the other steps in all the other pipelines). The bash script reads some secrets from the Kubernetes cluster where this job is running, and prepares the container where the step is being ran to run the tests configuring the Git client locally, creating a valid kubeconfig file to be able to talk to a Kubernetes cluster, etc.
 
 One of the most common e2e test is to create a new application, push it to a new GitHub repository, and deploy it using jx. These repositories created for testing are created on [a GitHub Enterprise instance called beescloud](https://github.beescloud.com/). Credentials to do that are read from the Kubernetes cluster, and passed as parameters while invoking the tests.