Editing, debugging, and GitHub in Red Hat CodeReady Workspaces 2

January 23, 2020
Don Schenck
Related topics:
Developer Tools

In a previous article, I showed how to get Red Hat CodeReady Workspaces 2.0 (CRW) up and running with a workspace available for use. This time, we will go through the edit-debug-push (to GitHub) cycle. This walk-through will simulate a real-life development effort.

To start, you'll need to fork a GitHub repository. The Quote Of The Day repo contains a microservice written in Go that we'll use for this article. Don't worry if you've never worked with Go. This is a simple program and we'll only change one line of code.

After you fork the repo, make note of (or copy) your fork's URL. We'll be using that information in a moment.

Create a Go workspace

Next, we'll use the pre-configured Go workspace as a basis to create our workspace in CRW. We will make a change to the configuration before we launch the workspace by removing the default demo GitHub reference and, instead, adding our forked repo's URL. Doing this means that our workspace will open with our code in front of us and ready for editing, debugging, and pushing back to our repo.

From the Workspaces section, select the Add Workspace button. When you are presented with the New Workspace page, you will see a list of built-in workspaces. Select the Go workspace. While you're on that page, also remove the example project. Both actions are shown in Figure 1:

Select the Go workspace and remove the example project.
Figure 1: Select the correct language workspace and remove the example project.">

The next step is to get the source code we want for this project. To do this, connect to your GitHub account by choosing the GitHub option in the Add or import Project section, as shown in Figure 2:

Connect your GitHub account to a CRW workspace
Figure 2: Connect your GitHub account to the new workspace.">

After connecting, you will be presented with a list of every GitHub project to which you have rights. Note that the list is in alphabetical order by project.

Select the qotd project—the one you forked earlier—and click the Add button to add this project to your workspace definition, as shown in Figure 3:

Select qotd and click Add
Figure 3: Add the qotd project to your workspace definition.">

You should see a result similar to what's shown in Figure 4:

Your new workspace definition
Figure 4: Your new workspace definition.">

When you reach this point, click the CREATE & OPEN button (that huge green one) to get things rolling.

We have ignition. You'll notice something really cool at this point. CRW automagically opens the README.md file in the editor, as shown in Figure 5:

CRW editor with README.md displayed
Figure 5: The editor opens your project.">

This is a small thing, but I think it's nice because it means that you start with an understanding of the project. Well played, CodeReady Workspaces.

Explore the CRW IDE

Before proceeding, let's label important parts of the IDE:

  • The file explorer, which is shown in Figure 5 in the previous section.
  • The Debug section, which is shown in Figure 6.
  • The SOURCE CONTROL:GIT section, which is shown in Figure 7:
The CRW Debug section.
Figure 6: The CRW Debug section.">
The CRW Source Control (GitHub) section.
Figure 7: The CRW Source Control (GitHub) section.">

A single click on a file in the file explorer enables editing. In our case, we will wait on the editing until later in this article. For now, let's run the program, which brings up an interesting point: debugging.

Debug your code

To debug our code, we first need to set up a debugging configuration and then set a breakpoint. After all, you (I mean, your colleague) might have introduced an error. Start by selecting View -> Debug Console from the menu bar at the top. Doing this will allow us to see messages as debugging starts. While being able to see this information is not necessary, it is nice to have.

Next, click on the Debug icon on the left to access the Debug section. At the top of the section, open the configuration drop-down. It initially reads No Configurations but we're going to change that setting. Select Add Configuration and then the Go: Launch package option. The file launch.json will be presented in the IDE.

Note: If the Go: Launch project option does not appear, it's probably because you selected the wrong stack when you created the workspace. Don't ask how I know this.

Change the line that reads "program": "${workspaceFolder}" to "program": "${current.project.path}/main.go", as shown in Figure 9:

Edit the launch file to add a project debug configuration.
Figure 9: Edit the launch file to add a project debug configuration.">

Click on the File Explorer icon on the left and open the main.go file. Click in the margin to the right of line number 16 to set a breakpoint, as shown in Figure 10:

Set your breakpoint in the File Explorer.
Figure 10: Set your breakpoint.">

Start the engine

Now, finally, we are ready to run our code. Click on the Debug icon and then click the green right-facing arrow by the configuration drop-down to start the program in Debug mode. Or, just press F5.

When the application starts, you will get messages related to the port number and the service's URL. Select the option offered in each prompt. A small browser window will open in the IDE. If you receive an error stating that the application is not ready, simply refresh the browser until the application starts to run. Note that you can click the small icon to launch your default browser outside of the IDE.

You will see your breakpoint highlighted. Feel free to poke around the debug values to the left, including local variables. When ready, click the Continue button (blue arrow) in the debug control area.

When finished debugging, press the Stop button (red box) in the debug control area.

Go ahead and change a quote in the program, then run in Debug mode again. When you are satisfied that your change works, we're ready to update our repo. For a developer, this feels like home. Edit, run, debug, edit, run, debug, etc. Press F11 at any time to run your browser in full-screen mode and you'll soon forget that you're using the web.

Commit your code

Click on the Source Control icon to view the Source Control area. In the message area, enter text to describe the change you just made. This information is used by the git commit -m command. Then, click the commit checkbox above the message area. This is the git commit command, and it uses the text you entered in the message area.

Push back

Now to fulfill the cycle and push our changes to our GitHub repo. Remember: We're working in a browser, so there is no File -> Save option.

Note: But there could be. We have been doing everything in Ephemeral Mode (as noted at the bottom of your IDE), but CRW does support saving files to storage if you configured a Persistent Volume. That's another article for another time.

Select the ellipses (...) in the source control area and choose the Push option. This action will prompt you for your GitHub username and password. After you have supplied these correctly, the code will be pushed to GitHub to update your repo.

Hop over to your browser and navigate to the GitHub repo, where you'll see your changes. You did it. You pulled down code, edited it, debugged it, and pushed it back to GitHub. And of course, you have a GitHub webhook configured to automatically kick off your CI/CD pipeline now, right?

Right?

That question looks like YABP—Yet Another Blog Post—is in order: GitHub to CI/CD using OpenShift Pipelines.

Note: If you shut down your workspace and then, later, start it again, it will pull down the current code. In other words, if someone else made changes during the interim, you'll see them. It's a small feature, but it's nice to have an automatic git pull before you start work.

What's next?

I briefly mentioned a stack. In the third and final article of this three-part series, I'll show you how to build a custom stack, which is a way to customize workspaces to your specific needs.

Last updated: June 29, 2020