Retrieve Jenkins X Activities, Logs, Pipelines, and More

While UIs are nice to look at, I am a firm believer that nothing beats the command line concerning speed and repeatability. Fortunately, we can retrieve almost any information related to Jenkins X through jx executable.

Retrieving activities#

We can, for example, get the last activities (builds) of those jobs.

The output is as follows:

We can see that there were activities with each of the three jobs. We had one deployment to the production environment (environment-jx-rocks-production), and two deployments to staging (environment-jx-rocks-staging). The first build (activity) is always performed when a job is created. Initially, environments only contain a few applications necessary for their correct operation. The reason for the second build of the staging environment lies in the creation of the jx-go project. One of the steps in its pipeline is in charge of promoting a successful build to the staging environment automatically. When we explore jenkins-x.yml in more detail, you’ll get a better understanding of the process, including promotions.

The last activity is of the jx-go pipeline. So far, we did not push any change to the repository, so we have only one build that was run when the job itself was generated through the quickstart process.

Applying filters on activities#

Listing the most recent activities is very useful since we have only a few pipelines, but when their number grows, we’ll need to be more specific. For example, we might want to retrieve only the activities related to the jx-go pipeline.

This time, the output is limited to all the activities related to jx-go which, in our case, is a single build of the master branch.

This time, we used the --watch flag to tell Jenkins X that we’d like to watch the activities. Since there are no pending builds, the output will stay intact, so please press ctrl+c to stop the watch and return to the prompt.

🔍 Internally, Jenkins X activities are stored as Kubernetes Custom Resources (CRDs). If you’re curious, you can see them by executing kubectl --namespace jx get act.

Retrieving logs#

Activities provide only a high-level overview of what happened. When everything is successful, that is often all the information we need. However, when things go wrong and some of the tests fail, we might need to dig deeper into a build by retrieving the logs.

Since we did not specify from which build we’d like to retrieve logs, we are faced with the prompt to select the pipeline from which we’d like to extract the output. We could choose one of the pipelines, but we won’t do that since I want to show you that we can be more specific in our request for logs.

Please press ctrl+c to return to the prompt.

Applying filters on logs#

We can use the --filter argument to retrieve logs from the last build of a specific pipeline.

The output should show the logs of the last build of jx-go, no matter the branch.

We can be even more specific than that and request logs from the specific GitHub user, of the specific pipeline, from the last build of a specific branch.

The output should show the logs of the last build of the jx-go pipeline initiated by a commit to the master branch.

Being able to retrieve logs from a specific pipeline is not of much use if we don’t know which pipelines we have. Fortunately, we can extract the list of all the pipelines as well.

Retrieving pipelines#

We can see that there are three pipelines named environment-jx-rocks-production, environment-jx-rocks-staging, and jx-go (I’ll ignore the existence of the dummy pipeline). The first two are in charge of deploying applications to staging and production environments. Since we are using Kubernetes, those environments are separate namespaces. We’ll discuss those two later. The third job is related to the jx-go project we created as a quickstart.

Retrieving applications#

We can also retrieve the list of applications currently managed by Jenkins X.

The output is as follows:

For now, retrieving the applications is uneventful since we have only one deployed to the staging environment.

Retrieving environments#

So far, we talked about the staging and production environments. Are those the only ones we have? Let’s check it out.

The output is as follows:

As you can see, there is a third environment named dev. We’ll explore it later. For now, remember that its purpose is true to its name, it is meant to facilitate development.

Retrieving applications from a specific environment#

Now that we know which environments we have, we can combine that information and list only the applications in one of them. Let’s see which ones are running in the staging environment.

The output is as follows.

We already knew from before that the jx-go application is running in staging and we already know that nothing is installed in production. Nevertheless, we can confirm that with the command that follows.

It should come as no surprise that the output states that no applications were found in environments production. We did not promote anything to production yet. We’ll do that later.

Exploring project releases#

Finally, Jenkins X also created a GitHub release for us. We can confirm that by going to project releases.

For now, we have only one release that is not very descriptive, since we did not create any issues that should be listed in release notes. The release you see in front of you is only the initial one created by pushing the quickstart files to Git.

Finally, we have not yet confirmed whether the new application is indeed deployed and can be accessed.

We retrieved the host from jx-go Ingress and used it to send a curl request. As a result, the output is:

We confirmed that the application created as a quickstart was deployed to the staging environment. All we did was execute jx create quickstart and Jenkins X did most of the heavy lifting for us.

Let’s wrap up this discussion in the next lesson.