Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: update bdd explanation #3755

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
+3 −3
Draft

fix: update bdd explanation #3755

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions content/en/community/code/continuous-integrating-jx-itself.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)

Expand All @@ -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.

Expand Down