Configure the build

[github-learning-lab]

In this pull request, I've added some tests to help ensure the project builds. This is just one example of how you can customize specific validations that will be ran when your CI starts a build. I need you to add a script to build our project in the .travis.yml file.

[github-learning-lab]

Step 4: Add validation

Build your site.

⌨️ Activity: Add some automated validation to your project

1. In this pull request, add the following code to the REPLACE-ME-WITH-BUILD-SCRIPT placeholder in your .travis.yml file

 bundle exec jekyll build

2. Commit your change.

You can do this by editing the file from the Files changed tab, or by scrolling down and accepting the suggested change.

---

I'll respond below with your next step.

[github-learning-lab]

Now that you've added some validation tests to your CI build, it's time to turn on some branch protections. Protected branches ensure that collaborators cannot make irrevocable changes to specific branches. This also allows you to enable CI required status checks to pass before merging.

Why use protected branches?

Protected branches allow contributors to create branches and pull requests in your repository, while making sure those changes are throughly vetted before merging. When a repository employs a continuous integration service like Travis CI, branches can be protected based on their build statuses so the review process can be largely automated, giving contributors self-efficacy. Project maintainers also benefit by focusing their attention on gray areas and processes that can't be easily automated.

I've changed the protections for the main branch throughout the course so far to help keep you on track. Now, it's time for you to make some changes.

Step 5: Protect the main branch

⌨️ Activity: Protect a branch based on the CI build status

1. Navigate to the Branches section of the Settings for this repository.
2. Under Branch protection rules, click the Edit button next to main.
3. Select Require status checks to pass before merging.
4. Uncheck Require branches to be up to date before merging.
   • This is automatically checked, and can be a good idea. For this project, we'll uncheck it to reduce the extra commits and builds.
5. Select the Travis CI - Branch and Travis CI - Pull Request options
6. Click Save changes.
7. Return to your pull request and Approve the pull request.

---

I'll respond below with your next step.

[github-learning-lab]

Now that you've added some validation tests to your CI build, it's time to turn on some branch protections. Protected branches ensure that collaborators cannot make irrevocable changes to specific branches. This also allows you to enable CI required status checks to pass before merging.

Why use protected branches?

Protected branches allow contributors to create branches and pull requests in your repository, while making sure those changes are throughly vetted before merging. When a repository employs a continuous integration service like Travis CI, branches can be protected based on their build statuses so the review process can be largely automated, giving contributors self-efficacy. Project maintainers also benefit by focusing their attention on gray areas and processes that can't be easily automated.

I've changed the protections for the main branch throughout the course so far to help keep you on track. Now, it's time for you to make some changes.

Step 5: Protect the main branch

⌨️ Activity: Protect a branch based on the CI build status

1. Navigate to the Branches section of the Settings for this repository.
2. Under Branch protection rules, click the Edit button next to main.
3. Select Require status checks to pass before merging.
4. Uncheck Require branches to be up to date before merging.
   • This is automatically checked, and can be a good idea. For this project, we'll uncheck it to reduce the extra commits and builds.
5. Select the Travis CI - Branch and Travis CI - Pull Request options
6. Click Save changes.
7. Return to your pull request and Approve the pull request.

---

I'll respond below with your next step.

[github-learning-lab]

Awesome, nice work getting those branch protections in place 🎉

But, right before you enabled your branch protections, something happened. A contributor committed invalid syntax on main and broke your CI build. Luckily, your new test caught it and you turned on branch protections. These types of errors won't make it into future builds.

Note: If your build is still processing, you may not see the failed test yet. If you wait a few minutes, it should be done soon.

Looking at your build status, click on the Details link as shown below in one of your builds:

Navigate to the Build Failed section and click on the build failed link:

Notice that you get the following error:

  Liquid Exception: Liquid syntax error (line 1): Unknown tag 'site' in docs/01_getting_ready_for_class.md

Jekyll uses Liquid, an open-source templating language. Liquid loads data dynamically and implements conditional logic. Some of the Liquid syntax in one of the files is incorrect.

Step 6: Fix the broken build

Let's find the broken syntax and fix the build!

⌨️ Activity: Fix the build in your codebase

1. Apply the suggested change.

---

I'll respond below with your next step.

[github-learning-lab]

Nice job finding and fixing that Liquid syntax!

It might take a moment, but notice as your build is complete that all checks have passed.

Step 7: Merge code with a successful build

Now that your pull request has a successful build, let's merge it!

⌨️ Activity: Merge the pull request

1. Click Merge pull request, and delete your branch.

---

I'll respond below with your next step.

[github-learning-lab]

---

Navigate to your new pull request for next steps.