We’ll import the application stored in the vfarcic/go-demo-6 repository. We’ll use it as a guinea pig to test the import process and to flesh out potential problems we might encounter.

Fork the repository#

But before we import the repository, you’ll have to fork the code. Otherwise, you won’t be able to push changes since you are not yet a collaborator on that specific repository.

Please make sure that you are logged in and click the Fork button located in the top-right corner. Follow the on-screen instructions.

Clone the repository#

Next, we need to clone the repository you just forked.

⚠️ Please replace [...] with your GitHub user before executing the commands that follow.

Replace the master branch with the orig branch#

Chances are that I did not leave the master branch in the state I intended it to be or that I’m doing something with it while you’re reading this. I might be testing some recently released Jenkins X feature, or maybe I’m trying to fix a problem from one of the examples. To be sure that you have the correct version of the code, we’ll replace the master branch with the orig branch, and push it back to GitHub.

Inspect the repository#

Now you should have the intended code in the master branch of the repository you forked. Feel free to take a look at what we have by opening the repository in a browser. Fortunately, there is a jx command that does just that.

widget

Exploring the project files#

Let’s quickly explore the files of the project before we import it into Jenkins X.

The output is as follows:

What do we see in the project directory?#

As you can see, there’s (almost) nothing in that repository but Go code (*.go) and libraries (vendor).

That project is one extreme of the possible spectrum of projects we might want to import to Jenkins X. It only has the code of the application, there is no Dockerfile and there is no Helm chart. Heck, there isn’t even a script for building a binary, nor is there a mechanism to run tests. And there definitely isn’t a jenkins-x.yml that defines a continuous delivery pipeline for the application. There’s only code and almost nothing else.

📝 Such a situation might not be your case. Maybe you do have scripts for running tests or building the code. Or perhaps you do have Dockerfile, and maybe you are already a heavy Kubernetes user, and you do have a Helm chart. You might have other files as well. We’ll discuss those situations later. For now, we’ll work on the case when there is nothing but a code of an application.

Importing repository into Jenkins X#

Let’s see what happens when we try to import that repository into Jenkins X.

jx import --batch-mode

The output is as follows:

We can see from the output that Jenkins X detected that the project is 100.000000% written in Go, so it selected the go build pack.

  • It applied it to the local repository and pushed the changes to GitHub.
  • It created a Jenkins project as well as a GitHub webhook that will trigger builds whenever we push changes to one of the selected branches. Those branches are by default:
    • master
    • develop
    • PR-.*
    • feature.*

We could have changed the pattern by adding the --branches flag. But, for our purposes, and many others, those branches are just what we need.

Inspect the local copy of the repository#

Now, let’s take another look at the files in the local copy of the repository.

ls -1

The output is as follows:

Dockerfile
Jenkinsfile
Makefile
OWNERS
OWNERS_ALIASES
README.md
charts
functional_test.go
go.mod
jenkins-x.yml
main.go
main_test.go
production_test.go
skaffold.yaml
vendor
watch.sh

We can see that quite a few new files were added to the project through the import process.

  • We acquired Dockerfile that will be used to build container images

  • We acquired jenkins-x.yml that defines all the steps of our pipeline.

  • Further on, Makefile is new as well. It, among others, defines targets to build, test, and install the application.

  • There is the charts directory that contains files in Helm format. We’ll use it to package, install, and upgrade our application.

  • Then, there is skaffold.yaml that contains instructions on how to build container images.

  • Finally, we acquired watch.sh. It allows us to compile the binary and create a container image every time we change a file in that project. It is a handy script for local development. There are a few other new files (e.g., OWNERS) added to the mix.

Do not think that is the only explanation you’ll get about those files. We’ll explore these files in much more detail later on in the course. For now, what matters is that we imported our project into Jenkins X and that it should contain everything the project needs for both local development and continuous delivery pipeline.

Now that the project is in Jenkins X, we should see it as one of the activities and observe the first build in action. You already know that we can limit the retrieval of Jenkins X activities to a specific project and that we can use --watch to watch the progress.

jx get activities \
    --filter go-demo-6 \
    --watch

By the time the build is finished, the output, without the entries repeated due to changes in status, should be as follows.

Please stop watching the activities by pressing ctrl+c.

So far, the end result looks similar to the one we got when we created a quickstart. Jenkins X created the files it needs, it created a GitHub webhook, it created a pipeline, and it pushed changes to GitHub. As a result, we got our first build, and by the look of it, it was successful.

Check for potential problems#

Since I have a paranoid nature, we’ll double-check that everything indeed looks ok.

Please open the PullRequest link from the activity output.

So far, so good. The go-demo-6 job created a pull request to the environment-jx-rocks-staging repository. As a result, the webhook from that repository should have initiated a pipeline activity, and the result should be a new release of the application in the staging environment. We won’t go through that part of the process just yet. For now, just note that the application should be running, and we’ll check that soon.

The information we need to confirm that the application is indeed running is in the list of the applications running in the staging environment. We’ll explore the environments later. For now, just run the command that follows.

jx get applications

The output is as follows:

We can see the address through which our application should be accessible in the URL column. Please copy it and use it instead of [...] in the command that follows.

The output is as follows:

Now that was unexpected! Everything looks ok from Jenkins X’s perspective, but the application is not accessible. Did we fail to do something, or did Jenkins X fail to do the right thing?

When in doubt, we can always take a look at the logs.

The output is as follows:

The problem is in the database; it’s missing. The application tried to connect to MongoDB but couldn’t find it.

In retrospect, that makes sense. While Jenkins X does the right thing most of the time, it could not know that we need a database, specifically MongoDB. There is no such information in the repository, except inside the Go code. Excluding the possibility of scanning the whole code and figuring out that MongoDB is needed based on imported libraries, it’s normal that Jenkins X did not add it to the Helm chart it generated when we imported the project.

The only sensible thing we can do is to modify the Helm chart and add the YAML files Kubernetes will need to spin up a database together with the application.

🔍 Please note that we’ll explore how to fix the issues that occurred from importing a specific application into Jenkins X. Your problems will likely be different. Nevertheless, I believe that the exercises that follow will give you an insight into what to expect when importing projects. Watch out for auto-generated Helm charts as they are the most common culprit.


In the next lesson, we will fix the auto-generated Helm chart.

Creating a Kubernetes Cluster with Jenkins X
Fixing the Auto-Generated Helm Chart
Mark as Completed
Report an Issue