Now you've created your pull request and you're ready to continue the process. In this section, we're going to cover how to deal with the built in checks failing, and how to submit code to an active pull request. You'll learn to read the logs generated by the check system, and how to take that information and apply it to fixing your code.

Many of the Adafruit repos have a built in checks system called Travis CI, which does what is called continuous integration testing (the CI in Travis CI). This check will verify your code for style and syntax, and make sure that the everything builds with your code included.

The fact is, you're going to run into these checks failing, no matter how many times you go over your code before submitting. So, it's important to be able to read the log generated by Travis. It will contain any errors found and allow you to more easily find them in your code.

Once you've clicked the Create pull request button, it will automatically take you to your newly created PR. Let's take a look.

Pull Request Explored

The title of the PR will be what you entered into the message title when you created it, followed by the PR number.

The next section tells you the current status of the PR. This PR is Open. I am currently requesting to merge 3 commits into adafruit:master from kattni:play-file-stop-tone-fix. Remember, I'm asking to take the code from my branch and add it to the master branch of the original repo.

The next section includes the body of the message you submitted with your pull request. The tabs at the top lead you to different sections of the PR. You can view a list of the commits, the checks, and the files changed in a diff format like included when you created your PR. Click on each one to view its contents.

The upper right of this section includes some green and red numbers and boxes. These indicate the number of lines of code added and removed. You'll find they reflect the color coding found in the Files Changed section.

Next is a list of the commits included with the initial PR. You'll notice the last commit has a yellow dot next to it. This is because the checks have not yet completed.

After the PR is created, Travis will begin it's testing. Depending on the size of the repo, this can take anywhere from a few seconds to several minutes. Until it's completed, you'll see the final commit has a yellow dot and the beginning of the next section will be yellow and say "Some checks haven't completed yet".

The second part of this section should say "This branch has no conflicts with the base branch". If you created your pull request when it didn't say "Able to merge" in green at the top, then this might look different.

The last part is the merge button, which won't turn green until everything is set. I have merge permissions on this repo, so the Merge pull request button shows up for me.

If you don't have merge permissions on a repo, the end of this section may look like either of the following.

In the event that a repo is setup to require a review before merging is allowed, the last section may include something similar to the following warning in place of the section that says "This branch has no conflicts..."

All Checks Have Failed

Travis testing completed, and it has failed. This means my PR is not yet ready for review. If your checks fail, you need to work that out before the review process can begin.

The most recent commit shows a red X next to it indicating the same.

This is going to happen to you. Consider it to be a normal part of the process. We've all dealt with it. The more you go through it, the more you'll learn, and eventually it will happen less. But inevitably you'll miss something, and Travis is here to let you know. Let's take a look at how to get that information from Travis.

Click on the Details link found in the section letting you know that the checks have failed.

This will take you to the Travis CI log for this check.

The first section outlines the details of the check. It tells you the PR on which it was run, the status of the check, the current commit, how long the check took, when it was run, what branch you're requesting to merge with, and who authored and committed to this PR. The build number is a Travis-specific number.

This check has failed, and I need to know why. The next section is the log generated during Travis' check process. I'm going to scroll down until I see red text, which will indicate the check process exiting on a failure.

Travis has failed during the linting process. A linter is a tool that checks code for things like errors in syntax or style. Travis uses the pylint tool to check code. It is possible to run pylint on your computer. You can run it before you even push to your fork and fix any issues ahead of time. This involves some setup. More information can be found here.

Here, the issue lies in the module express. This might seem obvious in this case, since I only edited one file. However, often a PR consists of many files. In that event, the Travis log may contain a list of multiple files with errors in them. Each one will have the errors listed under the file name. Don't be afraid to ask for help with this! Sometimes the errors are not obvious and it's entirely okay to need assistance sorting them out.

In this log, listed under Module express is the following line:

C:690, 0: Trailing whitespace (trailing-whitespace)

This is telling me that on line 690 in the file express, I have trailing whitespace. Whitespace is any spaces not containing characters in your file. It's super necessary for CircuitPython to work! However, it shouldn't exist at the end of lines or on blank line, so this is considered an error.

The (trailing-whitespace) is not Travis or pylint being repetitive. It's the exact nomenclature of the pylint error. This would be used in the event that you chose to deliberately go against the linter, and needed to disable the pylint error in your code.

I checked my file, and sure enough, I have added a space after pass on line 690. So, I need to fix that. This means I will be going through all of the steps in the Status, Add, Commit, Push section again, starting with deleting the trailing whitespace from my file. Once I've fixed the issue, I'm ready to commit again. First, I'll check the status and diff.

I'm satisfied I've made the necessary changes. So, I'm going to add, status, commit, status, and push.

When you push a branch already involved with a pull request, it will automatically update the pull request with your new changes.

You do not need to make a new PR or do anything special to get the current PR to update. All you have to do is push your branch. This is true for the entire duration of an open pull request, regardless of the reason for submitting updates.

This will trigger Travis to run the check again. The status will return to Some checks haven't completed yet during this time.

Note that the previous commit still shows a red X. This is because it failed. GitHub works by tracking a timeline, and that timeline involves a failure. So this commit will always show that it failed even when the fix is applied through a new commit.

Remember, depending on the size of the repo, this can take anywhere from a few seconds to several minutes.

This time, it passes! The status changes to All checks have passed and there's a green check mark next to my last commit.

My pull request is now ready for someone to review it. The next section will cover the process of receiving a review.

This guide was first published on Jun 29, 2018. It was last updated on Jun 29, 2018.

This page (Open Pull Request) was last updated on Nov 06, 2020.