Continuous Integration with CodeBuild

Project 4 of the 6 Day DevOps Challenge - learn what Continuous Integration means, and how to set it up using AWS CodeBuild!

Introduction

⚡️ 30 second Summary

Welcome to Day FOUR of the 6 Day DevOps Challenge!

Today, we're working with AWS CodeBuild to automate the build process for your web app.

Get ready to:

🛠️ Create and configure a CodeBuild project from scratch.
🔗 Connect your CodeBuild project to your GitHub repository.
⚙️ Define your build process using a buildspec.yml file.
💎 Automate testing using CodeBuild too!

Why am I learning about AWS CodeBuild?

When you're developing software, you need to regularly "build" your code, which is the process of turning the code into a package that can be deployed.

AWS CodeBuild is a continuous integration service that automates this entire build process for you. When a developer pushes new code, CodeBuild automatically compiles the code, runs the tests, and packages everything up. This saves enormous time, eliminates human error, and helps you deliver better software faster! That's why CodeBuild is an essential part of a CI/CD pipeline - it automatically makes sure your application is always built consistently and correctly.

Wait, what's the 6 Day DevOps Challenge?

Ooooo, glad you asked 😸

In the 6 Day DevOps Challenge, you'll build from scratch a CI/CD pipeline that automates the build and deployment of a web app. This is a 100% hands-on challenge, so get ready to write documentation and add your work to your portfolio along the way (we'll show you how).

Want a complete demo of how to do this project, from start to finish? Check out our 🎬 walkthrough with Natasha 🎬

If you're up for a bit of a challenge, quiz yourself on the key concepts up ahead in this project.

This project is part of a series:

Before we start Step #1...

Note

This project assumes you've ticked off Days #1-3 of the 6 Day DevOps Challenge!

DAY 1: Set Up a Web App in the Cloud
DAY 2: Connect a GitHub Repo with AWS
DAY 3: Secure Packages with CodeArtifact

Haven't tried those projects yet? That's okay! We still have the steps ready for you - get ready for some extra setup time in Step 1 of this project :)

Set Up Your Development Instance

Let's get started by launching an EC2 instance! This will be our virtual server in the cloud where we'll set up our CI/CD pipeline.

In this step, you're going to:

Launch an EC2 instance using the AWS Management Console.
Understand the benefits of using EC2 for this project.
Troubleshoot common issues during instance launch.

Let's dive right in! We've split up the setup for your development environment into four key milestones.

Note

If you've done projects #1-3 of the 6 Day DevOps Challenge, here's your mini challenge for this step... how many of these milestones can you check off without using the step by step guidance below?

Launch an EC2 instance.
SSH connect to your EC2 instance via VS Code.
Install Maven, Java and Git in your EC2 instance.
Clone your web app code on GitHub.

I haven't done Projects 1-3 yet

Then let's do it all step by step together! Ignore the other tabs, and stay right here.

Set up an IAM Admin User

Do you have an IAM user?

No

Oooo it's the start of a new era!

If you don't have an IAM user yet - here are the steps to create one (this takes less than 10 mins).

What is an IAM user? Why are we setting one up?

In AWS, a user is a person or a computer that can do things on the AWS cloud.

When you create an AWS account for the first time, the login you get is called the root user of the AWS account. AWS actually recommends to not use your root user for everyday tasks to protect it from security breaches.

You should create IAM users instead. If a root user is a master key to your AWS account, think of IAM users as key copies. IAM users have separate usernames and passwords to your root user, and you can set them to have limited access to your account's resources.

Head to your AWS Account as the root user.
Open the AWS IAM console.
From the left hand navigation panel, choose Users.
Choose Create user.
For the User name, name it:

[[YOURNAME="enter your name"]]-IAM-Admin

Make sure to select the checkbox next to Provide user access to the AWS Management Console - optional.‍

Note

This does not apply to all accounts, but if you're prompted with a pop up panel that says Are you providing access to a person?, choose I want to create an IAM user.‍

For the console password, choose Custom password.
Type in a password that you will be able to remember/access in the future.

Top tip

You will use this password for all future projects, so make sure to choose a secure one!

Deselect the checkbox for Users must create a new password at next sign-in - Recommended.

Choose Next.
In the permissions set up page, choose Attach policies directly.
From the list of Permissions policies, select AdministratorAccess.
Choose Next.
Choose Create user.
Voilà - you've just created your new user! Stay on this page.
Choose Download .csv file.

Copy the Console sign-in URL.

Now you're ready to start using your IAM user. 🏁
Log out of your root user's AWS Account.
Paste and go to your copied console sign-in URL.
Open your downloaded .csv file containing your user's access instructions.
Log in using your IAM user's username and password in the .csv file.

Once you're logged in, you're ready to use your IAM user for this project! Make sure to keep the login details safe - you'll need them for the entire 6 Day DevOps Challenge!

Yes

Note

PLEASE make sure you log in to your IAM Admin User instead of the root user - it's truly best practice for account security.

Launch an EC2 Instance

Before we get into the juicy work of building your web app, we need to set up a home for your web app's files.

Since we want your web app to be entirely created and run on the cloud, we'll use a virtual server (EC2 instance) to house our development work.

Head to Amazon EC2.
Switch your Region to the one closest to you.

Tip: We recommend using the following regions

Did you know that not all regions have the same number of AWS services available?

There are only 13 AWS Regions that provide ALL the services we'll use in the 6 Day DevOps Challenge. We'd recommend using one of these regions from the very start of the challenge, so all your resources are in the same place. Even if you don't live in these regions, you can still use them:

us-east-1 (N.Virginia)
us-east-2 (Ohio)
us-west-2 (Oregon)
eu-west-1 (Ireland)
eu-west-2 (London)
eu-central-1 (Frankfurt)
eu-north-1 (Stockholm)
eu-south-1 (Milan)
eu-west-3 (Paris)
ap-southeast-1 (Singapore)
ap-southeast-2 (Sydney)
ap-northeast-1 (Tokyo)
ap-south-1 (Mumbai)

🙋‍♀️ Extra for Experts: How do you know only these regions have all the services we need?

By checking out AWS' guidance on services by region! Once you select a region, you can sift through the list and identify whether it has all the services you need.

In your EC2 console, select Instances from the left hand navigation panel.
Choose Launch instances.

Set up your EC2 instance:
In Name, enter the value:

nextwork-devops-[[YOURNAME="enter your name"]]

Choose Amazon Linux 2023 AMI under Amazon Machine Image(AMI).
Leave t2.micro under Instance type.
Select Create a new key pair and use nextwork-keypair as your key pair's name.
Store nextwork-keypair.pem in a new folder called DevOps in your local computer's Desktop.

Back to our EC2 instance setup, head to the Network settings section.
For Allow SSH traffic from, select the dropdown and choose My IP. This makes sure only you can access your EC2 instance. You can double check your IP by clicking here.

Choose Launch instance.

Didn't see a success message?

Share any errors/questions with the NextWork community!

Install VS Code

Do you have VS Code installed on your computer?

No

Let's goooooo! We'll set up VS Code in just a few minutes, and learn why we use it along the way.

Head to the Visual Studio Code website.

What is VS Code?

Visual Studio Code (VS Code) is one of the most popular tools for creating and managing coding projects. You'll often hear people call VS Code an IDE (Integrated Development Environment), which means software that help you write and edit code. It's similar to how Microsoft Word or Google Docs help you write documents!

VS Code also comes with extra tools that we'll use to connect to virtual servers like EC2 instances.

Install VS Code by following the installation instructions for your OS e.g. Linux, Mac, Windows.

How can I decide which setting/chip option I should pick?

If you're unsure of which chip/settings option to pick for your device:

Mac: Select the Apple icon from the top left hand corner of your computer's menu bar. Select About this Mac, and note whether your Chip says Apple or Intel.
Windows: Click the Start button and search for System Information. Note whether your System Type says x64-based or ARM-based PC.
Linux: Open a terminal and run uname -m. Note whether the output says x86_64 or aarch64/arm64.

Once downloaded, you might need to unzip a zip file to access VS Code.

Open VS Code in your local computer (you'll find it in your Downloads folder).
If a popup asks you to confirm opening VS Code, select Open.

Welcome to VS Code!

Yes

Awesome! You're already set up to use VS Code.
Open VS Code in your local computer.

Select Terminal from the top menu bar.
Select New Terminal from the dropdown.

What is a terminal?

A terminal is where you send instructions to your computer using text instead of clicks. For example, instead of right-clicking on your desktop to create a new folder, you can type a simple text command in your terminal instead. It's like sending text messages to your computer's operating system to tell it what to do.

Every computer has a terminal. On Windows, it's often called Command Prompt or PowerShell, while macOS and Linux systems use Terminal.

Navigate your terminal to the DevOps folder:
- cd ~/Desktop/DevOps (Mac/Linux)
- cd C:\Users\YourUserName\Desktop\DevOps (Windows)
Once you’re in the DevOps folder, you might want to check if your .pem file is there. Use ls (Mac/Linux) or dir (Windows).

Change the permissions of your .pem file:

In the terminal, run the following command to allow access to your .pem file.

Mac/Linux

chmod 400 nextwork-keypair.pem

What is chmod?

This command stands for "change mode", and it changes the permissions of your .pem file. Using 400 makes it readable only by you (the owner) and restricts access for everyone else.

We're changing the permissions of your .pem file so that you have access to it when you connect to your EC2 instance later. Blocking out everyone else keeps your .pem file i.e. your secret key secure.

Windows

icacls "nextwork-keypair.pem" /reset
icacls "nextwork-keypair.pem" /grant:r "[[USERNAME="enter your username"]]:R"
icacls "nextwork-keypair.pem" /inheritance:r

What is icacls?

Icacls (which stands for Integrity Control Access Control Lists) is a tool for Windows that lets you decide who can open or change the files on your system. In these icacls commands, you're using:

/reset to remove default permission settings on the file
/grant:r "USERNAME:R" to give the current user (that's you!) read access to your secret key
/inheritance:r to make sure changes in the permissions of other files and the DevOps folder won't change the permission settings for this file.

Make sure to replace "USERNAME" with your Windows username. If you don't know your username, run whoami in your terminal to find out.

Connect to your EC2 Instance

Let's use the terminal in VS Code to set up a 🔌 connection 🔌 to your EC2 instance. Once we're connected, we can work inside your EC2 instance to set up that web app.

Head back to your AWS Management Console.
Click on Instances from the left hand navigation panel.
Click on the checkbox next to your EC2 instance to view its details.
Under the Details tab, look for Public IPv4 DNS. You'll need this in the next instruction!

Head back to VS Code and open your terminal again.
Use the following command to connect to your EC2 instance:

ssh -i nextwork-keypair.pem ec2-user@[[EC2="YOUR PUBLIC IPV4 DNS"]]

I'm getting an error!

Ah, classic! Many students have run into an error at this step, and we'll get you unstuck. Make sure there are no spaces in your folder names (e.g. the DevOps folder cannot be titled Dev Ops).

Still stuck? Share any other errors/questions with the NextWork community!

Your terminal will ask if you want to continue connecting to this EC2 instance. Enter yes to continue connecting.
Congrats! You've connected your EC2 instance via SSH.

Install Apache Maven and Amazon Corretto 8

Connection DONE. This means your terminal has now entered into your EC2 instance and can use it like a computer that's right in front of you!

Now let's install two tools that are going to help us build Java web apps. Introducing Apache Maven and Amazon Corretto 8 🥁

Install Apache Maven using the commands below:

wget https://archive.apache.org/dist/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz

sudo tar -xzf apache-maven-3.5.2-bin.tar.gz -C /opt

echo "export PATH=/opt/apache-maven-3.5.2/bin:$PATH" >> ~/.bashrc

source ~/.bashrc

What is Apache Maven?

Apache Maven is a tool that helps developers build and organize Java software projects. It's also a package manager, which means it automatically download any external pieces of code your project depends on to work.

We're also using Maven today because it's really useful for kick-starting web projects! It uses something called archetypes, which are like templates, to lay out the foundations for different types of projects e.g. web apps.

We'll use Maven later on to help us set up all the necessary web files to create a web app structure, so we can jump straight into the fun part of developing the web app sooner.

Now we're going to install Java 8, or more specifically, Amazon Correto 8.

sudo dnf install -y java-1.8.0-amazon-corretto-devel

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64

export PATH=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64/jre/bin/:$PATH

What is Java? What is Amazon Correto 8?

Java is a popular programming language used to build different types of applications, from mobile apps to large enterprise systems.

Maven, which we just downloaded, is a tool that NEEDS Java to operate. So if we don't install Java, we won't be able to use Maven to generate/build our web app today

Amazon Corretto 8 is a version of Java that we're using for this project. It's free, reliable and provided by Amazon.

💡 Woah! What's all this text popping up in the terminal?

The text you see after these commands is the terminal keeping you updated about it's progress with installing Java. It shows the specific packages it's going to install, downloading status, and even verifying that everything was installed.

To verify that Maven is installed correctly, run mvn -v next. Make sure the output mentions a Maven version 3.5.x.
To verify that you've installed Java 8 correctly, run java -version.

Important

If the Java version command above doesn't return openjdk version 1.8 (=> Java 8), run the following command that allows you to choose the correct Java version: sudo alternatives --config java

🙋‍♀️ Seeing error messages while installing Maven/Java?

Share any errors/questions with the NextWork community!

Create the Application

We've assembled both Maven and Java into our EC2 instance. Now let's cut straight to generating the web app!

Use mvn to generate a Java web app. To do this, use these commands:

mvn archetype:generate \
   -DgroupId=com.nextwork.app \
   -DartifactId=nextwork-web-project \
   -DarchetypeArtifactId=maven-archetype-webapp \
   -DinteractiveMode=false

Break down these commands for me... What is mvn?

When you run mvn commands, you're asking Maven to perform tasks (like creating a new project or building an existing one).

The mvn archetype:generate command specifically tells Maven to create a new project from a template (which Maven calls an archetype). This command sets up a basic structure for your project, so you don't have to start from scratch.

Extra for Experts: Some of the details you've specified in this command are...

-DartifactId=nextwork-web-project names your project
-DarchetypeArtifactId=maven-archetype-webapp specifies that you're creating a web application.
-DinteractiveMode=false runs the command without pausing for user input, so Maven will go ahead and install everything without waiting for your confirmation.

Watch out for a BUILD SUCCESS message in your terminal once your application is all set up.

Connect VS Code with your EC2 Instance

In this step, you'll connect VS Code to your EC2 instance so you can see and edit the web app you've just created.

If you don't have Remote - SSH installed in VS Code already, select the Extensions icon at the side of your VS Code window. Search for Remote - SSH and click Install for the extension.

Why are we installing Remote - SSH?

The Remote - SSH extension in VS Code lets you connect directly via SSH to another computer securely over the internet. This lets you use VS Code to work on files or run programs on that server as if you were doing it on your own computer, which will come in handy when we edit the web app in your EC2 instance!

Click on the double arrow icon at the bottom left corner of your VS Code window. This button is a shortcut to use Remote - SSH.
Select Connect to Host...
Select + Add New SSH Host...
Enter the SSH command you used to connect to your EC2 instance:

ssh -i [[PEMPATH="PATH TO YOUR .PEM FILE"]] ec2-user@[[EC2="YOUR PUBLIC IPV4 DNS"]]

I'm getting an error!

Ah, classic! Many students have run into an error at this step, and we'll get you unstuck. Make sure there are no spaces in your folder names (e.g. the DevOps folder cannot be titled Dev Ops).

Still stuck? Share any other errors/questions with the NextWork community!

Select the configuration file at the top of your window. It should look similar to /Users/username/.ssh/config

A Host added! popup will confirm that you've set up your SSH Host - yay!
Select the blue Open Config button on that popup.
Confirm that all the details in your configuration file look correct:
- Host should match up with your EC2 instance's IPv4 DNS.
- IdentityFile should match up to nextwork-keypair.pem's location in your local computer.
- User should say ec2-user

Now you’re ready to connect VS Code with your EC2 instance.
Click on the double arrow button on the bottom left corner and select Connect to Host again.
You should now see your EC2 instance listed at the top.

Select the EC2 instance and off we gooooooooooo to a new VS Code window ✈️
Check the bottom right hand corner of your new VS Code window - it should show your EC2 instance's IPV4 DNS.

Now that VS Code is connected to your EC2 instance, let's open up your web app's files.

From VS Code's left hand navigation bar, select the Explorer icon.
Select Open folder.
Enter /home/ec2-user/nextwork-web-project.
Press OK.

VS Code might show you a popup asking if you trust the authors of the files in this folder. If you see this popup, select Yes, I trust the authors.
Check your VS Code window's file explorer again - a folder called nextwork-web-project is here!

Try expanding all the subfolders in the file explorer. All folders have a > icon next to their name.

What are all these files and subfolders?

All the files and subfolders you see under nextwork-web-project are parts of a web app! You can start working right away on the content you want to display on your web app, since Maven's taken care of the basic structuring and setup.

Let's get to know some of these web app files/folders:

The src (source) folder holds all the source code files that define how your web app looks and works.
src is further divided into webapp, which are the web app's files e.g. HTML, CSS, JavaScript, and JSP files, and resources, which are the configuration files a web app might need e.g. connection settings to a database.
pom.xml is a Maven Project Object Model file. It stores information and configuration details that Maven will use to build the project. We'll use pom.xml later in this project series!

From your file explorer, click into index.jsp.

Let's try modifying index.jsp by changing the placeholder code to the code snippet below. Don't forget to replace {YOUR NAME} from the following code with your name:

<html>

<body>

<h2>Hello [[YOURNAME="enter your name"]]!</h2>

<p>This is my NextWork web application working!</p>

</body>

</html>

Save the changes you've made to index.jsp by selecting Command/Ctrl + S on your keyboard.

Let's connect our local web app to a remote repository on GitHub. This will let us track changes to our code and collaborate with others!

Install Git

To start using Git, we need to install it on your EC2 instance.

Open a new terminal in VS Code (if you don't already have one open in the remote session) by selecting Terminal > New Terminal. This terminal is now connected to your EC2 instance.
Run the following commands in the terminal to update the package list and install Git:

sudo dnf update -y

sudo dnf install git -y

Why install Git on the EC2 instance?

Git is a version control system that we'll use to manage our web app's code. We need to install Git on the EC2 instance so we can initialize a Git repository in our project directory, track changes, and push our code to GitHub in the next steps.

Off we goooo! Git is installed - you should see a Complete! message like this:

To check that Git was installed correctly, run the following command in the terminal:

git --version

This command will show you the installed version of Git if it's installed correctly.

Nice, Git is installed! You're ready to track the changes you make to your web app. We're also going to set up a remote repository on GitHub, so your web app code is also stored in the cloud.

Set up your GitHub repository

Do you have a GitHub account?

Yes - I'm ready to go!

No - I need to set up a GitHub account

Oooo exciting let's get you set up 🤘 Signing up is free and takes just 5 minutes!

Head to GitHub's signup page.

What is Github?

GitHub is a place for engineers to store and share their code and projects online. It's called GitHub because it uses Git to manage your projects' version history.

Follow the prompts to create your account by entering your email, creating a password, and choosing a username.

Complete one of their bot verification tasks. Switch the task type to Audio if the Visual task crashes your website.
Once your account is created, confirm your email address with a verification code sent to your inbox.

Log into your GitHub account once you've verified your email.

Welcome to your GitHub account!

Click on the "+" icon in the top right corner of the page, next to your profile icon.
From the dropdown menu, select "New repository".

Nice! We're ready to create a new repository. Fill out the Create a new repository page.
In the Repository name field, enter nextwork-web-project
In the Description (optional) field, add a description like: Java web app set up on an EC2 instance. This web app was set up as a part of the NextWork's CI/CD Pipeline series.
Choose Public for the repository visibility.

Leave the Initialize this repository with: options unchecked.
Click the Create repository button.

What is GitHub?

GitHub is like a social network for code! It's where developers store their projects, track changes, and collaborate with others. At its heart, GitHub uses Git (a version control system) to keep track of every change made to your code. This means you can see who changed what, when they changed it, and even roll back to previous versions if something breaks.

GitHub is also where many companies look when hiring developers - your GitHub profile is essentially your coding portfolio. For our project, we're using GitHub to safely store our code and track all the changes we make as we build our CI/CD pipeline. Plus, you can keep this repository to show off this project to potential employers later!

Go back to VS Code, and open the terminal connected to your EC2 instance.
Make sure you're in your web app directory - run pwd and make sure it returns /home/ec2-user/nextwork-web-project.
Initialize a new Git repository in this directory by running:

git init

What does git init do?

To start using Git for your project, you need to create a local repository on your computer.

When you run git init inside a directory e.g. nextwork-web-project, it sets up the directory as a local Git repository which means changes are now tracked for version control.

💡 What's a local repository?

The local repository is where you use Git directly on your own EC2 instance. The edits you make in your local repo is only visible to you and isn't shared with anyone else yet

This is different to the GitHub repository, which is the remote/cloud version of your repo that others can see.

WOAH! I got a bunch of yellow text when I ran this command

This yellow text is just Git giving you a heads-up about naming your main branch master and suggesting that you can choose a different name like 'main' or 'development' if you want.

💡 What is a main branch?

You can think of Git branches as parallel versions or 'alternate universes' of the same project. For example, if you wanted to test a change to your code, you can set up a new branch that lets you diverge from the original/main version of your code (called master) so you can experiment with new features or test bug fixes safely. We won't create new branches in this project and we'll save all new changes directly to master, but it's best practice to make all changes in a separate branch and then merge them into master when they're ready.

Add remote origin

Now let's connect your local project folder with your Github repo!

Head back to your terminal in VS Code.
Add the remote repository as the origin with the following command, replacing <repository_url> with your repository's URL:

git remote add origin [[REPOURL="<repository_url>"]]

What does 'remote add origin' mean?

Your local and GitHub repositories aren't automatically linked, so you'll need to connect the two so that updates made in your local repo can also reflect in your GitHub repo.

When you set remote add origin, you're telling Git where your GitHub repository is located. Think of origin as a bookmark for your GitHub project's URL, so you don't have to type it out every time you want to send your changes there.

To find the URL of your GitHub repository, head back to your Git repository page.
In the blue section of the page titled Quick setup - if you've done this kind of thing before, copy the HTTPS URL to your repository page. It will look like https://github.com/username/nextwork-web-project.git

To verify that the remote origin has been set up correctly, run the command:

git remote -v

This command lists all configured remote repositories!
You should see origin listed, with both fetch and push URLs pointing to your GitHub repository URL.

Add, commit, and push your code to GitHub

Now, let's add all the files in your project to the Git repository. To do this, there are three commands you need to run...

First, run this command in your terminal:

git add .

What does this command do?

git add . stages all (marked by the '.') files in nextwork-web-project to be saved in the next version of your project.

💡 What does staging mean?

When you stage changes, you're telling Git to put together all your modified files for a final review before you commit them. This is incredibly handy because you get to see all your edits in one spot, which means its much easier to check if there were are mistakes or unwanted changes before you commit.

Run this command next in your terminal:

git commit -m "Updated index.jsp with new content"

What does this command do?

git commit -m "Updated index.jsp with new content"saves the staged changes as a snapshot in your project's history. This means your project's version control history has just saved your latest changes in a new version. -m flag lets you leave a message describing what the commit is about, making it easier to review what changed in this version.

Finally, run this command:

git push -u origin master

What does this command do?

git push -u origin master uploads i.e. 'pushes' your committed changes to origin, which you've bookmarked as your GitHub repo. 'master' tells Git that these updates should be pushed to the master branch of your GitHub repo. By using -u you're also setting an 'upstream' for your local branch, which means you're telling Git to remember to push to master by default. Next time, you can simply run git push without needing to define origin and master.

When you run git push, you might get asked for your GitHub username and password.

Why is Git asking for my username?

Git needs to double check that you have the right to push any changes to the remote origin your local repo is connected with. To do this, Git is now authenticating your identity by asking for your GitHub credentials.

Enter your Github username, and press Enter on your keyboard.
Next, enter your password. You'll notice that as you type this out, nothing shows on your terminal. This is totally expected - your terminal is hiding your input for your privacy. Press Enter on your keyboard when you've typed out your password, even if you don't see it printed out in your terminal.
Hmmmm, now Git is letting us know that it can't actually accept our password.

What does this mean?

GitHub phased out password authentication to connect with repositories over HTTPS - there are too many security risks and passwords can get intercepted over the internet 🤺 You need to use a personal access token instead, which is a more secure method for logging in and interacting with your repos.

💡 What is a token?

A token in GitHub is a unique string of characters that looks like a random password. For example, a GitHub token might look like ghp_xHJNmL16GHSZSV88hjP5bQ24PRTg2s3Xk9ll. As you can imagine, tokens are great for security because they're unique and would be very hard to guess.

Set up and use a GitHub Personal Access Token (PAT)

To create a PAT, go back to your GitHub account in your web browser.
Click on your profile icon in the top right corner.

Select Settings from the dropdown menu.

In the left sidebar, scroll down and click on Developer settings.

Under Developer settings, click on Personal access tokens.

Click on Tokens (classic).

Click on Generate new token (classic).

Now you're on the New personal access token (classic) page!
In the Note field, enter the reason why you're generating this token, like Generated for EC2 Instance Access. This is a part of NextWork's 6 Day DevOps Challenge.

For Expiration, you can set it to 7 days for this project, or choose a different duration as per your preference.

What is a token expiration limit?

A token expiration limit means how long your personal access token would work for. After this time period, the token expires and no longer grants access, so you'll need to generate a new token. GitHub does this to make sure any tokens that are left lying around for months or years can't get picked up and used by someone else.

Under Select scopes, select the checkbox next to repo.

What do all these scopes mean?

We use scopes to decide what kind of permissions your token will grant. Each scope you pick gives the token the ability to do even more things with your GitHub account. In our case, we picked the repo scope, which means the token can even access and control private repositories in your account.

Scroll down and click the Generate token button at the bottom of the page.

Copy and use your Personal Access Token

Nice, a new token (a long string of random letters) is generated!
Make sure to copy the generated token right away - you won't be able to see it again after you leave this page 🍵
Click the Copy to clipboard icon next to your new token to copy it, and paste it somewhere safe now.

Go back to your VS Code terminal.
Re-run the git push -u origin master command - you can use the up ⬆️ key on your keyboard to re-run a previous command.

When asked for your username, enter your GitHub username again.

✋ PAUSE
Do you remember what the GitHub token was generated for?
When Git asks for your password, paste in your token instead.
When you paste, it'll look like nothing is happening. That's because your terminal won't show your token for privacy reasons.

Press Enter on your keyboard once you've pasted your token (even if you don't see it on screen).
You'll see output in the terminal telling us that the push was successful, such as "Enumerating objects...", "Writing objects...", and "Branch 'master' set up to track remote branch 'master' from 'origin'".

What do these messages mean?

These messages show the progress of transferring objects (like files and commits).

Once the push is done, you also get messages that tell you that your local branch is now tracking the remote branch after the push. This means you only have to run git push next time, instead of the full git push origin master.

Well done! Looks like Github recognises your token and pushed your changes to your repository.

Important Secufrity Note

Treat your Personal Access Token like a password. Keep it secure and do not share it with anyone or commit it into your code. If you accidentally share your token, make sure to delete it straight away and generate a new one.

Verify code in GitHub repository

To confirm that your code has been successfully pushed to GitHub, let's refresh your GitHub repository page in your browser.
You should now see all your web app files listed in your GitHub repository. SO good!

Congratulations! You've successfully connected your web app to GitHub. Your code is now safely stored in a remote repository, and you can track changes and collaborate more effectively.

To avoid having to enter your username and PAT every time you push to GitHub, you can configure Git to store your credentials.

This is optional but can make your workflow smoother!

YES - let's configure Git

Run the following command to configure Git to use the store credential helper:

git config --global credential.helper store

After running this command, try pushing again: git push. You might be asked for your credentials one last time. Once entered, Git will store them for future pushes.

Refresh your GitHub repository page in your browser again.
Open the index.jsp file in your repository on GitHub.
Verify that the changes you made (<h2>Hello {YOUR_NAME}!</h2> and the new paragraph) are now visible in the file on GitHub.

Nope - skip configuration

No problem, onwards and upwards! You can continue without configuring the credential helper.
You'll just need to enter your GitHub username and personal access token each time you push changes to GitHub. Make sure to keep the token safe!

Let's GO! Your web app is now fully connected to GitHub, and you're ready for the next steps in setting up your CI/CD pipeline.

Launch EC2 Instance

To kick things off, we'll need to set up our development EC2 instance and connect to it via SSH!

Launch an EC2 Instance

Log in to the AWS Management Console as your IAM Admin user.
Switch your Region to the one closest to you.

Tip: We recommend using the following regions

Did you know that not all regions have the same number of AWS services available?

us-east-1 (N.Virginia)
us-east-2 (Ohio)
us-west-2 (Oregon)
eu-west-1 (Ireland)
eu-west-2 (London)
eu-central-1 (Frankfurt)
eu-north-1 (Stockholm)
eu-south-1 (Milan)
eu-west-3 (Paris)
ap-southeast-1 (Singapore)
ap-southeast-2 (Sydney)
ap-northeast-1 (Tokyo)
ap-south-1 (Mumbai)

Head to the EC2 console.

What is Amazon EC2?

Amazon EC2 (Elastic Compute Cloud) gives you virtual servers in the cloud that you can spin up whenever you need them. Think of it like renting computers in AWS's data centers that you can configure and use without having to worry about the physical hardware.

For this project, we're using EC2 as both the place where we'll deploy our application and the environment where we'll build it initially. It's perfect for this because you can easily SSH into it to make changes and see your application running in real-time.

Launch an EC2 instance with the following settings:

Name: nextwork-devops-enter your name
Application and OS Images (Amazon Machine Image): Amazon Linux 2023
Instance type: t2.micro
Key pair: nextwork-keypair
Network settings: Allow SSH traffic from is set to My IP.

Finally, click Launch instance at the bottom right of the page.

Getting an "InsufficientInstanceCapacity" error when launching your EC2 instance?

Don't worry - this is a common issue that many NextWork students encounter! It simply means AWS doesn't have enough capacity for your chosen instance type in that specific data center (Availability Zone) right now. Here's how to fix it:

Try a different Availability Zone: Launch your instance in a different Availability Zone within the same region. Each zone is like a separate data center, and some might have more available capacity than others.
Choose a different instance type: If you're still having trouble, try selecting a different instance type. Some types are in higher demand than others.

Success!

EC2 instance LAUNCHED 🚀

Next up, let's connect to the EC2 instance. Jump to the next tab for the next step!

SSH to Instance

Now that your EC2 instance is running, let's connect to it securely use SSH so we can start setting up our environment.

Prepare Your Private Key File

Let's get your private key file ready for secure authentication.

Locate the private key file (nextwork-keypair.pem) that you downloaded when creating the key pair in the previous step.
Move this .pem file to a dedicated folder on your local computer for better organization. For example, create a folder named DevOps on your Desktop and move the .pem file into it: ~/Desktop/DevOps/.

Configure SSH in VS Code

Open VS Code on your local machine.
Click on the Remote Explorer icon in the Activity Bar on the side (it looks like a double arrow).
If you don't see the Remote Explorer icon, you might need to install the Remote - SSH extension.
You can do this by going to the Extensions view (Ctrl+Shift+X or Cmd+Shift+X) and searching for "Remote - SSH".
In the Remote Explorer, click on the Configure SSH Hosts... icon (it looks like a gear or settings icon).

Select SSH configuration file. Choose the existing config file path (e.g., ~/.ssh/config) from the dropdown menu.

What is SSH Configuration File?

The SSH configuration file (config) is a text file that allows you to define and save settings for SSH connections. By editing this file, you can store connection details for your EC2 instance, making it easier to connect in the future.

VS Code will open your SSH config file.
Edit the SSH config file - delete the existing setup.
Add the following configuration, replacing <your_instance_public_ipv4_dns> with the Public IPv4 DNS of your EC2 instance.
Make sure <path_to_pem_file> points to your private key file (.pem file you downloaded when launching the EC2 instance).

Host [[EC2="YOUR PUBLIC IPV4 DNS"]]
    HostName [[EC2="YOUR PUBLIC IPV4 DNS"]]
    User ec2-user
    IdentityFile [[PEMPATH="PATH TO YOUR .PEM FILE"]]

What is SSH (Secure Shell)?

SSH (Secure Shell) is a secure way to connect to and control your remote servers. Think of it like having a super-secure, encrypted phone line directly to your server where you can talk to it using text commands.

When you use SSH, everything you send (commands, passwords, data) is encrypted, so even if someone is eavesdropping on your internet connection, they can't see what you're doing. For developers, SSH is the go-to tool for managing servers remotely, transferring files securely, and running commands on distant machines without having to be physically present.

Need help finding your EC2 instance's IPv4 DNS?

In the EC2 console, navigate to Instances and select your running instance.
Under the Details tab, find and note down the Public IPv4 DNS. We'll need this to connect to our instance remotely.

What is Public IPv4 DNS?

The Public IPv4 DNS is basically your EC2 instance's address on the internet. It's like your server's phone number or home address - it's how other computers know where to find it when they want to connect. You'll use this address whenever you need to connect to your instance from your local machine.

Save your updated SSH config file. Save the updated config file in VS Code by pressing Ctrl+S (Windows/Linux) or Cmd+S (Mac).
Make sure no unsaved changes indicator (a white circle) is present on the file tab. If you see a white circle, it means your changes are not saved yet.

Connect to EC2 via SSH

In VS Code, click on the Remote Explorer icon again.
Select Connect to Host.
Your EC2 instance's Public IPv4 DNS (which you set as HostName in the config file) should now appear as a configured host in the Remote Explorer panel (under SSH TARGETS).

Select your configured EC2 instance.
VS Code will open a new window and attempt to connect to your EC2 instance.
Continue SSH connection. If prompted with a host key verification, click Continue. This is a security measure to ensure you are connecting to the correct server.

If the connection went well, you'll see a new VS Code window connected to your EC2 instance. The bottom left corner of the window should say that you are connected to SSH: ec2-instance.

Seeing a "Permission denied (publickey)" error when trying to connect?

Oops! SSH connections can sometimes be a bit finicky. This usually happens when your private key file has incorrect permissions or you're using the wrong key file. Let's solve this together:

Fix your key file permissions: SSH requires secure permissions on your private key
- Open your terminal
- Go to where your .pem file is stored
- Run chmod 400 nextwork-keypair.pem (replace nextwork-keypair.pem with your actual key file name if different). This command sets the permissions so that only the owner (you) can read the file.
Make sure you're using the correct key: Double-check that the key file you're using matches the one you selected when creating your EC2 instance

After adjusting the permissions and verifying your key pair, try connecting again. You should now be able to establish an SSH connection to your EC2 instance successfully!

Woop woop! Do you know what's next?

It's time to install your development instance's key tools - Maven, Java and Git! Jump to the next tab for the next step!

Install tools

Now that you're connected to your EC2 instance, let's set up the necessary tools and environment to build our web application. We'll install Maven, Java, and Git!

Question: Why do we need to install Maven, Java, and Git on the EC2 instance?

We're installing these three tools because they're the foundation for our Java web application development:

Maven is our project builder and package manager - it handles compiling our code, pulling in all the libraries we need, and packaging everything up neatly. Without it, we'd be doing a lot of manual work to build our application.

Java is the runtime environment our application needs to actually run. It's like the engine that powers our code. Since we're building a Java web app, this is non-negotiable - no Java, no application!

Git is our version control system, which lets us download our project code from GitHub, track any changes we make, and collaborate with others. It's essential for modern development because it keeps a history of our code and helps prevent conflicts when multiple people work on the same project.

Together, these tools create a complete environment where we can build, test, and deploy our web application as part of our CI/CD pipeline.

Install Maven

In the new VS Code window, open a new terminal (Terminal > New Terminal). The terminal prompt should say that you are now working within your EC2 instance (e.g., ec2-user@your-instance-id ~ $).
Run the following commands one by one to download and install Maven:

wget https://archive.apache.org/dist/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz
sudo tar xzf apache-maven-3.5.2-bin.tar.gz -C /opt
echo 'export PATH=/opt/apache-maven-3.5.2/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

What is Apache Maven?

Apache Maven is like a smart assistant for your Java projects. It helps you build your project, manage all the libraries your code depends on, and generate helpful documentation - all using simple commands.

When you're working on a Java project (like we are), Maven saves you from the headache of manually downloading and configuring all those JAR files your application needs. Instead, you just tell Maven what you need in a simple XML file, and it handles the rest. It's a huge time-saver that lets you focus on writing code rather than managing dependencies.

Run the command mvn -v to check if Maven is installed correctly and to see its version.
Confirm Maven version 3.5.2 is displayed in the output.

Install Java

Run the following commands to install Java 8 Amazon Corretto:

sudo dnf install -y java-1.8.0-amazon-corretto-devel
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64
export PATH=$JAVA_HOME/jre/bin/:$PATH

What is Java?

Java is one of the world's most popular programming languages, known for its "write once, run anywhere" capability. You write your code once, and it can run on any device that has a Java Virtual Machine (JVM) - whether that's a laptop, server, or even a smart TV!

Amazon Corretto is AWS's free, production-ready version of Java. It's basically Java with AWS's stamp of approval, meaning they've tested it extensively and support it themselves. We're using it as the foundation for running our web application because it's reliable and doesn't cost a thing.

Run the command java -version to check if Java is installed and to see its version.
Confirm Java version 1.8.0_442 (or similar Java 8 version) is displayed.

Install Git

Run the following commands to update the package manager and install Git:

sudo dnf update -y
sudo dnf install git -y

What is Git?

Git is like a time machine for your code. It keeps track of all the changes you make, lets you rewind to previous versions if something breaks, and helps teams collaborate without overwriting each other's work.

In our project, we'll use Git to grab our web application code from GitHub (a popular service built on Git) and bring it to our EC2 instance. This means you can easily update your code, track changes, and work with others on the same codebase without stepping on each other's toes.

Check that you've installed Git by running git -version - you should see a version number!

I don't see a version number

Aha! Check the terminal response - turns out, git -version is not the right command to see your Git version number. Can you tell what is the proper command to find it?

Now that Git is installed, it's ⏰ time ⏰ to set up your web app's code! Jump to the next tab for the next step!

Web App Code

Clone Web App Repository

In the EC2 terminal, run the following command, replacing <repository_url> with the URL you just copied:

git clone [[REPOURL="<repository_url>"]]

Not sure where to find the repository URL?
Navigate to your GitHub repository for the web application in your web browser.

On your GitHub repository page, click on the green Code button.
A dropdown menu will appear. Copy the HTTPS URL provided in the dropdown.

Paste and run the repository URL in your command.

Getting a "git: command not found" error?

No worries - this just means Git isn't installed on your EC2 instance yet. This is super easy to fix:

Run this command to install Git: sudo dnf install git -y
After installation completes, verify it worked by running: git --version

Open Project Folder in VS Code

In VS Code, click Open Folder in the Explorer panel (top left corner).

Select the cloned project folder (nextwork-web-project) in your home directory and click OK.

You should now see the files and folders of your web application project in the VS Code Explorer.
If VS Code prompts Do you trust the authors of the files in this folder?, click Yes, I trust the authors.
Close any popup that you might get about installing another extension.

To verify that your web app code is present, open src/main/webapp/index.jsp by double-clicking it and check its content.

With Maven, Java, and Git installed and your project opened in VS Code, you're all set to move on to the next step!

Set up CodeArtifact Repository

Let's set up AWS CodeArtifact, a fully managed artifact repository service. This will help us securely store and share software packages used in our CI/CD pipeline.

In this step, you're going to:

Set up a CodeArtifact repository to store your web app's packages.
Create an IAM policy and role for CodeArtifact access.
Configure Maven settings to use CodeArtifact.
Build your web app with Maven and verify the connection with CodeArtifact.

Just like the previous step, we've broken down CodeArtifact set up into four key milestones.

How far can you go in each milestone without looking at the step by step instructions?

Create your CodeArtifact repository.
Set up an IAM policy and role for CodeArtifact access.
Give your development EC2 instance access to CodeArtifact.
Complete the connection settings between CodeArtifact and Maven.

Create repository

Let's get started with CodeArtifact!

Navigate to CodeArtifact

Open the CodeArtifact service. You can search for "CodeArtifact" in the search bar and select CodeArtifact under Services.

What is AWS CodeArtifact?

AWS CodeArtifact is like a secure, private locker for all your software packages and dependencies. Instead of having developers download packages from the public internet (which can be risky and unreliable), you store trusted versions in CodeArtifact.

It works seamlessly with tools you're already using like Maven, npm, and pip. In our CI/CD pipeline, CodeArtifact gives us a central, secure place to store our Maven artifacts so our build and deployment processes can always access exactly what they need. No more "works on my machine" problems because everyone's using different package versions!

Create CodeArtifact Repository

In the CodeArtifact console, click Create repository.
On the Create repository page, configure the following:
- Repository name: nextwork-devops-cicd
- Description: Repository for NextWork CI/CD artifacts.
- Package format: Select Maven.
- Public upstream repositories: Enable Include public upstream repositories and select maven-central-store. This allows CodeArtifact to fetch packages from Maven Central if they are not found in your repository.
- If prompted to set a domain, set the domain name to nextwork. If a domain already exists, you can use the existing domain.

Click Create repository.
The CodeArtifact repository nextwork-devops-cicd should be created successfully. You should see it listed in the repositories dashboard.

With your CodeArtifact repository set up and connection details noted, we're ready to configure our EC2 instance to access it.

Jump to the next tab for the next step!

IAM Policy and Role

Create IAM Policy for CodeArtifact Access

First, we'll create an IAM policy that defines the permissions needed to access CodeArtifact.

Navigate to the IAM console in a new tab.
In the IAM console, click Policies in the left-hand menu.
Click Create policy.
Switch to the JSON tab.
Replace the existing content in the JSON editor with the following policy document. This policy grants permissions to get authorization tokens, repository endpoints, and read from CodeArtifact repositories:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codeartifact:GetAuthorizationToken",
        "codeartifact:GetRepositoryEndpoint",
        "codeartifact:ReadFromRepository"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sts:GetServiceBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "sts:AWSServiceName": "codeartifact.amazonaws.com"
        }
      }
    }
  ]
}

Click Next.
On the Review policy page, enter the following:
- Policy name: codeartifact-nextwork-consumer-policy
- Description: Policy for EC2 instances to access CodeArtifact
Click Create policy.
Nice! The codeartifact-nextwork-consumer-policy should be created and listed in your IAM policies.

Create IAM Role for EC2 Instance

In the IAM console, click Roles in the left-hand menu.
Click Create role.
Select AWS service as the trusted entity type.
Choose EC2 as the service that will use this role.
Click Next.
In the Attach permissions policies page, search for and select the codeartifact-nextwork-consumer-policy you just created.
Click Next.
On the Name, review, and create page, enter the following:
- Role name: ec2-instance-nextwork-cicd
- Description: IAM role for EC2 instances to access CodeArtifact
Click Create role.
The ec2-instance-nextwork-cicd-role should be created and listed in your IAM roles.

Attach IAM Role to EC2 Instance

Now, let's associate the IAM role with your EC2 instance.

Navigate back to the EC2 service console and go to the Instances dashboard.
Select your running instance (nextwork-devops-yourname).
Click Actions at the top, then select Security, and then Modify IAM role.
In the Modify IAM role dialog, from the IAM role dropdown, select the ec2-instance-nextwork-cicd-role you just created.
Click Update IAM role to apply the changes.

Too cool - your EC2 instance's permissions are all set up.

Time to make the connection between CodeArtifact and your web app happen 🤝

Jump to the next tab for the next step!

Connect CodeArtifact and Maven

Get Connection Instructions

We'll need to get the connection instructions to configure Maven to use this repository.

Click on the newly created repository nextwork-devops-cicd to view its details.
Click on Connection instructions in the repository details page.
In the Connection instructions dialog, select Mac and Linux as the operating system and Maven as the package manager.
🚨 Double check that you're using Mac and Linux as the operating system. Even if you're doing this project on a Windows computer, Mac and Linux is the right choice. Your EC2 instance is an Amazon Linux 2023 instance!- Copy the command in Step #3 - this command stores an authorization token to your CodeArtifact repository!

Export CodeArtifact Auth Token

Finally, let's verify that your EC2 instance can now access CodeArtifact using the attached IAM role.

Go back to your VS Code remote window connected to your EC2 instance.
In the terminal, run the command in Step #3 of your CodeArtifact connection instructions window.
This should export the CodeArtifact authorization token as an environment variable.

Excellent work! You've successfully configured IAM permissions to allow your EC2 instance to access CodeArtifact. Let's move on to configuring Maven to use CodeArtifact in the next step.

Create settings.xml

Let's create the settings.xml file in your Maven project. If you already have settings.xml in your GitHub repository, you can go straight to building the project!

What is settings.xml?

The settings.xml file in Maven is used to configure Maven's execution environment. It allows you to customize settings like repository locations, server credentials, and proxy configurations. In our case, we are using it to tell Maven to use our CodeArtifact repository for managing dependencies and deploying artifacts.

In your VS Code Explorer, navigate to the root directory of your cloned project (nextwork-web-project).
Create a new file named settings.xml in the project root directory.
Add settings tags in the file:

<settings>

</settings>

Copy and paste the code from steps #4-6 of CodeArtifact's connection instructions between the <settings> tags.
Save settings.xml.

Question: What is the purpose of configuring settings.xml for Maven?

The settings.xml file is like Maven's address book and passport for accessing repositories. We're setting it up for a couple of important reasons:

First, it tells Maven where to find your AWS CodeArtifact repository - essentially giving Maven the address of your private package library. Without this, Maven would only look in public repositories like Maven Central.

Second, it provides the authentication details Maven needs to access your private repository. The CODEARTIFACT_AUTH_TOKEN environment variable works like a temporary password that proves Maven has permission to access your CodeArtifact repository.

By configuring this file correctly, you're ensuring that Maven can seamlessly download dependencies from and upload artifacts to your private CodeArtifact repository. This creates a secure, controlled environment for your project's packages, which is essential for reliable builds in your CI/CD pipeline.

Build the Project with Maven

In the EC2 terminal, navigate to your root project directory (nextwork-web-project) if you are not already there.
Run the command to build your project using Maven and the settings.xml file you configured:

mvn compile -s settings.xml

Getting "UnauthorizedException" or "AccessDeniedException" during your Maven build?

Many students encounter this error - it means your EC2 instance doesn't have proper permissions to access CodeArtifact. Let's fix it together:

Check your IAM policy: Make sure the codeartifact-nextwork-consumer-policy has all the permissions shown in the steps above
Verify the IAM role is attached: Confirm that the ec2-instance-nextwork-cicd role (with the policy attached) is connected to your EC2 instance
Review your settings.xml file: Double-check that all placeholders like <your_aws_account_id> have been replaced with your actual values
Verify your auth token: Make sure the CODEARTIFACT_AUTH_TOKEN environment variable was exported correctly - run echo $CODEARTIFACT_AUTH_TOKEN to check

You should see a BUILD SUCCESS message at the end of the Maven build output in the terminal.
The first build might take longer (wait 1-3 minutes) as Maven downloads dependencies from CodeArtifact for the first time.

Verify Artifact Upload to CodeArtifact

Go back to the CodeArtifact console.
Navigate to Repositories and select your nextwork-devops-cicd repository.
Check that packages are uploaded to your CodeArtifact repository. Don't forget to hit the refresh button!

Create a CodeBuild Project

Ready to dive in? Let's create our CodeBuild project!

In this step, you're going to:

Create a new CodeBuild project.

Create a CodeBuild Project

Log in to your AWS Management Console.
In the top search bar, type CodeBuild.
Select CodeBuild from the dropdown menu under Services.

What is AWS CodeBuild?

AWS CodeBuild is a fully build tool for your code. It takes your source code, compiles it, runs tests, and packages it up. Engineers love continuous integration tools like CodeBuild because you don't have to manually set up and manage any build servers yourself, and you only pay for the compute time you use for building your projects (instead of entire servers that are idle most of the time). Think of it as a super-efficient, scalable, and managed service that handles all the heavy lifting of building and testing your applications.

Continuous Integration is like having a quality control checkpoint that automatically kicks in whenever anyone on your team makes changes to your code. Instead of waiting until the end of a project to discover that something broke, CI helps you catch and fix issues early and often. CI helps you constantly check that everything still works as expected - running tests, compiling code, and making sure new changes play nicely with the existing codebase.

In the CodeBuild dashboard, find the left navigation menu.
Select Build projects.

What is a CodeBuild project?

A CodeBuild project is basically the blueprint for your CI process. It's where you tell AWS everything it needs to know about how to build your application. This includes things like where your code lives (like GitHub), what kind of environment you need (Linux or Windows? Java or Python?), exactly what commands to run during the build, and where to store the results when it's done. Think of it as a recipe that CodeBuild follows every time it needs to build your application.

Configure Your Build Project

On the Create build project page, scroll to the Project configuration section.
Under Project name, enter nextwork-devops-cicd.
Under Project type, make sure Default project is selected.

What are the CodeBuild project types?

CodeBuild gives you two main types of projects, each designed for different CI/CD needs:

Default project: This is your standard option that most teams use. It's perfect when you want to manage your entire build process within AWS. You get full control over how your build runs, what goes in, and what comes out - all without leaving the AWS ecosystem.
Runner project: This option is for teams who already have CI systems like GitHub Actions or GitLab CI but want to tap into the power of CodeBuild's build environment. It's like having CodeBuild do the heavy lifting while your existing CI system orchestrates the overall process.

For this project, we're using a Default project to directly manage our CI process within CodeBuild.

Scroll down to the Source section.

Under Source provider, select GitHub.

What does source mean?

CodeBuild doesn't know where your web app's code lives! Source means the location of the code that CodeBuild will fetch, compile, and package into a file you can deploy.

We're choosing GitHub as our source provider because that's where we've stored our web app's code. By connecting CodeBuild directly to GitHub, we're creating a seamless pipeline where code changes automatically flow into our build process.

CodeBuild plays well with lots of different code repositories - AWS CodeCommit, Bitbucket, GitHub, and even plain S3 buckets. This flexibility lets you keep using whichever code storage system your team prefers while still getting all the benefits of AWS's build capabilities.

Awesome! You're doing great. Next, let's connect CodeBuild to your GitHub repository so it can access your code.

Connect CodeBuild to your GitHub Repository

To allow CodeBuild to access your private GitHub repository, we need to establish a connection using AWS CodeConnections.

In this step, you are going to:

Set up a connection between your AWS account and GitHub using AWS CodeConnections.

Let's get started! Connecting to GitHub is crucial for CodeBuild to access your project's code.

In the Source section, under Credential, you might see the message You have not connected to GitHub. Manage account credentials.
Click on Manage account credentials.

You will be taken to the Manage default source credential page.

Ensure GitHub App is selected for Credential type.

What are the Credential types for GitHub?

When connecting to GitHub, CodeConnections gives you a few different options, each with their own trade-offs:

GitHub App: This is generally the simplest and most secure option. AWS manages the application and connection, reducing the need for you to handle tokens or keys directly. It's recommended for most use cases due to its ease of use and enhanced security.
Personal access token: This method uses a personal access token generated from your GitHub account. You might remember using this for authenticating to GitHub from the terminal. While straightforward, it requires you to manage and rotate tokens, which can be less secure and more operationally intensive.
OAuth app: This involves setting up an OAuth application in GitHub and configuring CodeConnections to use it. It provides a more granular control over permissions but is more complex to set up compared to GitHub App.

Select create a new GitHub connection.

On the Create connection page, under Connection details, enter nextwork-devops-cicd as the Connection name.

Click Connect to GitHub.

You will be taken to GitHub to authorize the AWS Connector for GitHub application.
Select your GitHub user account where your repository is located.

Select Select.
After authorization on GitHub, you'll get taken back to the AWS console.

Under GitHub Apps, you'll see that your GitHub username is an option now!.

Select your GitHub username.

Click Connect.

Why these steps to connect to GitHub?

You might be wondering why there are so many steps just to connect to GitHub. The multi-step process ensures that AWS can securely access your repositories without needing your GitHub password or storing sensitive credentials. This method is much more secure than manually managing tokens that need to be rotated regularly.

Awesome! You've successfully connected to GitHub. It might seem like a few steps, but this process securely links your AWS account to your GitHub account using the AWS Connector for GitHub.

You should get redirected back to CodeBuild's Manage default source credential page after successful connection.
On the Manage default source credential page, you should see your newly created connection listed.

Click Save at the bottom of the page.

Why save default source credential?

By saving the GitHub App connection as the default credential, you make it easier to reuse this connection for future CodeBuild projects. This avoids the need to repeat the connection setup process each time you create a new project that uses the same GitHub account.

Now, back in the Create build project page, in the Source section, you should see a success message in green: "Your account is successfully connected by using an AWS managed GitHub App."

Still seeing "You have not connected to GitHub"?

This happens sometimes! If you still see this error, it might be due to a temporary issue or browser cache.

Here's how to fix it:

Try refreshing the page completely
Carefully repeat the steps to create a GitHub App connection
Make sure you authorize the AWS Connector for GitHub in your GitHub account when prompted
If needed, clear your browser cache or try using a different browser

Well done! So... which service do you think connected 🤝 your AWS environment to GitHub? 🤝

When we were taken to different pages to connect to GitHub, that was CodeBuild passing us to another Code service (called AWS CodeConnections) behind the scenes!

What is AWS CodeConnections?

AWS CodeConnections is like a secure bridge between AWS and your external code repositories. Instead of dealing with the headache of managing API keys, tokens (like GitHub's Personal Access Tokens!), or SSH credentials, CodeConnections handles all that authentication complexity for you - so you can focus on building your application.

If you'd like, you can open the left hand navigation menu, expand Settings at the bottom of the list, and open the Connections page. You can manage all connections you set up with CodeConnections there!

Let's get itttttt! Just like that, you've connected CodeBuild to your GitHub repository. You're making excellent progress. Let's get back to setting up CodeBuild.

You can now select your GitHub repository nextwork-web-project as the source.

Finish Setting Up Your CodeBuild Project

Next, we need to define the environment where our builds will run. This includes the operating system, runtime, and compute resources.

In this step, you are going to:

Configure CodeBuild's environment settings.
Configure Amazon S3 to store build artifacts.
Enable CloudWatch logs for monitoring build processes.

Ready to configure your build environment? Let's dive in!

Scroll down to the Primary source webhook events section.
Untick the Webhook checkbox that says "Rebuild every time a code change is pushed to this repository."* Scroll down to the Environment section.
Under Compute, for Provisioning model, choose On-demand.

Why did we pick on-demand?

Provisioning model determines how AWS will set up and manage everything needed for your build. Choosing On-demand means AWS will create the resources you need for your build only when you start it, and tear them down when the build is done. This is cost-effective and efficient!

Reserved capacity gives you dedicated build resources always at your disposal. It costs more overall but gives you consistent performance and no wait times. Great for teams that are building constantly throughout the day. If on-demand is like ordering a taxi, reserved capacity is like renting your own car that you can access anytime you need it.

For Environment image, choose Managed image.

Why did we pick managed image?

Environment image is like a template for your build environment (just like how AMI's are templates for your EC2 instances). In more technical terms, environment images are pre-configured versions of the build environment so you won't need to install all the software/tools/settings required to build a project. We choose Managed image here, which means we're using a template that AWS has already created for us. The next few settings we pick underneath this will then tell CodeBuild what kind of image we're looking for.

Custom image lets you bring your own Docker image with exactly the tools and configurations your project needs. It's like designing your own custom workspace from scratch - more work to set up, but perfectly tailored to your specific requirements.

For Compute type, choose EC2.

Why did we pick EC2?

Compute sets up the servers that will actually run the commands and do the work for your project's build! Your project's build will run on Amazon EC2 instances, which are more flexible and powerful than AWS Lambda functions.

Note: Lambda is optimized for speed and faster startup times. Our web app is fairly simple and doesn't require a lot of resources, but it's also built in Java Corretto 8, which is a language that's not supported by Lambda.

Under Environment, for Operating system, select Amazon Linux.

For Runtime(s), select Standard.
For Image, choose aws/codebuild/amazonlinux-x86_64-standard:corretto8.

Keep Image version as Always use the latest image for this runtime version.

Under Service role, select New service role.

Excellent! You've configured the build environment. Check that you've configured the environment settings as described, choosing Amazon Linux, Standard runtime, Corretto 8 image, and a new service role.

Now, let's define how CodeBuild will actually build your application using a buildspec.yml file.

Scroll down to the Buildspec section.
Under Buildspec format, select Use a buildspec file.

Leave Buildspec name as default buildspec.yml.

What is buildspec.yml?

The buildspec.yml file is like a detailed instruction manual for CodeBuild. Placed in the root of your repository, it tells CodeBuild exactly what to do at each stage of the build process - what tools to install, what commands to run, and what files to package up when it's done.

CodeBuild automatically looks for a file named buildspec.yml in the root directory of your source code. If it finds one, it uses it to execute the build. If not, the build will fail (as we'll see later) 👀

Scroll down to the Batch configuration section.

What is Batch configuration?

Batch configuration lets you run multiple builds at once as part of a single batch job. It's like being able to cook several dishes simultaneously instead of one after another.

This becomes super useful when you need to test your code across different environments (like various operating systems or browser configurations) or when you want to parallelize parts of your build process to save time. While we won't use it in this project, it's a powerful feature for more complex workflows.

Configure Build Artifacts

Scroll down to the Artifacts section. We need to configure where CodeBuild will store the build artifacts.

What are build artifacts?

Build artifacts are the tangible outputs of your build process. They're what you'll actually deploy to your servers or distribute to users. That's why storing them properly in S3 is so important - they're the whole reason we're running the build in the first place.

For our project, we want our build process to create one build artifact that packages up everything a server could need to host our web app in one neat bundle. This bundle is called a WAR file (which stands for Web Application Archive, or Web Application Resource) and it works just like a zip file - a server will simply "unzip" your WAR file to find a bunch of files and resources (which are also build artifacts, i.e. a WAR file is a build artifact that bundles up other build artifacts) and host your web app straight away. Notice how you haven't been able to view your web app on a web browser so far in this project series - that's because we haven't created and deployed the WAR file yet!

Note: our build process will create a .war file (a packaged Java web application) as the build artifact, but artifacts could be executables, libraries, documentation, or any output your build creates.

For Type, select Amazon S3.

Why store artifacts in Amazon S3?

Your compiled applications, libraries, or any output files from your build need a safe, accessible home after the build finishes. S3 is perfect for this - it's a highly reliable and scalable storage solution that's also in our AWS environment (which makes the artifact easily accessible for deployment later).

Let's head to the S3 console. In the AWS Management Console search bar, type S3 and select S3 from the dropdown menu under Services.
Make sure you're still in the same region where you set up the CodeBuild build project.

Extra for Experts: Why create S3 bucket in the same AWS region?

Creating your S3 bucket in the same region as your CodeBuild project might seem like a small detail, but it matters for three key reasons:

Speed: When data doesn't have to travel across geographic regions, everything happens faster. Your build artifacts upload more quickly, and any services that need those artifacts can access them without delay.

Cost: AWS charges for data transfer between regions, but transfers within the same region are either free or much cheaper. Keeping everything in one region helps your AWS bill stay lower.

Compliance: Some industries have strict rules about where data can be stored geographically. Keeping your resources in a specific region helps you meet these requirements if they apply to your organization.

On the Buckets page, click Create bucket.
In the Create bucket page, under General configuration, for Bucket name, enter nextwork-devops-cicd-enter your name.

Leave all other settings as default.
Click Create bucket at the bottom of the page.

If you just created the S3 bucket, it might not show as an option in the CodeBuild project configuration.
Refresh the build project page in your browser - you might need to configure your build project again. Challenge yourself to re-do the setup with less guidance!
In your CodeBuild project, head back to the Artifacts section.
For Type, select Amazon S3.
For Bucket name, choose your newly created bucket nextwork-devops-cicd from the dropdown.

S3 bucket not appearing in the dropdown?

This happens to the best of us! When you create a new S3 bucket, AWS sometimes needs a moment to update all its systems. Let's solve it together:

Try refreshing the CodeBuild project creation page to reload the S3 bucket list
Double-check that your S3 bucket and CodeBuild project are in the same AWS region
If it still doesn't appear after refreshing, wait about 30 seconds and try again - AWS is just catching up!

In Name, enter nextwork-devops-cicd-artifact. This names our artifact, so it's easy to spot it in the S3 bucket.

For Artifacts packaging, select Zip.

Why package artifacts as a Zip file?

Packaging artifacts as a Zip file is a small detail that's actually quite useful!

Smaller size: Zip compression can significantly reduce the size of your artifacts, which means faster uploads to S3, less storage costs, and quicker downloads when you need to use them.
Organization: Instead of managing multiple individual files, you get one tidy package. It's like putting all your vacation photos in a single album rather than having them scattered across your phone.
Simplicity: When it comes time to deploy your application or share it with teammates, having a single zip file makes the process much more straightforward - just download one file and you have everything you need.

Look at you go! You've just configured your CodeBuild process' artifact storage.

Finally, let's enable CloudWatch logs to monitor our build process. Logs are essential for tracking build progress, debugging errors, and auditing build activities.

Configure CloudWatch Logs

Scroll down to the Logs section.
Make sure CloudWatch logs is checked.

What are CloudWatch logs?

Amazon CloudWatch Logs is a monitoring service that collects and tracks logs from AWS services. In this project, CloudWatch will record everything that happens during the build process, including the commands that are run, the output of those commands, and any errors that occur. This is incredibly useful for debugging and understanding what went wrong if a build fails.

In Group name, enter /aws/codebuild/nextwork-devops-cicd.

Extra for Experts: Why set a custom Group name?

Setting a custom Group name for CloudWatch logs might seem like a small detail, but it's helpful to keep things organized. By using a specific name like /aws/codebuild/nextwork-devops-cicd, you're essentially creating a dedicated folder for all logs related to this project.

This becomes super helpful as your AWS environment grows. Imagine having hundreds of projects and services to track! With custom group names, you can instantly filter and find the logs you need with this classic naming convention.

Wooooooop woop! You've configured logs for your CodeBuild project. You're all set to create your project and run your first build!

Scroll to the bottom of the page and click Create build project.

Run the Build and Troubleshoot Failures

Now that our CodeBuild project is fully configured, let's initiate our first build and see our CI pipeline in action!

In this step, you are going to:

Start your first build in CodeBuild.
Troubleshoot a build failure by adding a buildspec.yml file to your web app repository.

Let's get ready to run our first build! It's okay if it fails initially – that's part of the learning process.

Navigate to your newly created CodeBuild project nextwork-devops-cicd.
Click the Start build button.

You will be redirected to the build execution page.
You should see the build status change to In progress.

Wait for the build to complete.
Oooo, looks like the build failed!
By checking the logs and phase details, we can pinpoint exactly where and why our build is failing.
Select the Phase details tab to understand the failure.

Aha, the DOWNLOAD_SOURCE phase has failed with the error message YAML_FILE_ERROR: YAML file does not exist.

Why did I see this error?

Good news - this is exactly what we expected to happen! This error simply means CodeBuild couldn't find the buildspec.yml file in your GitHub repository, which makes sense because we haven't created it yet.

This is an important learning moment - without this file, CodeBuild doesn't know how to build your project. We'll create this file in the next steps.

Click on the Build details tab.
Scroll down to the Buildspec section.
Let's make sure that it says Using the buildspec.yml in the source code root directory.

This confirms that CodeBuild is looking for buildspec.yml in the root directory of our web app's nextwork-web-project code repository... we haven't created that file yet!
In fact, let's check our GitHub repository. Select the Repository link in your CodeBuild project.

Welcome back to your GitHub repo!

As you might've noticed, there's no buildspec.yml file - it should be in the root of your web app repository 🙈 Let's create it now.

Remind me: why do we need buildspec.yml?

CodeBuild reads your buildspec.yml file like a step-by-step instruction manual. It goes through each phase in order - install, pre_build, build, then post_build - running the commands you've specified in each section.

The beauty of using buildspec.yml is that your build process is defined as code right alongside your application. This means your build process can be versioned, reviewed, and evolved just like any other part of your codebase. Before the era of continuous integration (CI), you would have to manually run a bunch of commands to build your application - buildspec.yml automates this process!

Open your project in VS Code or your preferred code editor.
Select File > Open Folder...

Open your nextwork-web-project folder.

Select Ok.

In VS Code, in the Explorer pane, create a new file on the project root (nextwork-web-project).

Enter buildspec.yml as the file name.

Double check:

Is your file named exactly buildspec.yml?
Is your file located in the root directory of your project, not inside any subfolders like src or target?

Paste the following code for buildspec.yml:

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto8
  pre_build:
    commands:
      - echo Logging in to AWS CodeArtifact...
      - CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token --domain nextwork --domain-owner <your_aws_account_id> --region us-east-2 --query authorizationToken --output text`
      - export CODEARTIFACT_AUTH_TOKEN
  build:
    commands:
      - echo Build started on `date`
      - mvn clean install -s settings.xml
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Packaging artifacts...
      - mvn package -s settings.xml
artifacts:
  files:
    - target/*.war
  discard-paths: no

What's inside buildspec.yml?

This buildspec.yml file is like a recipe for how to build your Java web app. Let's break it down into simpler terms:

version: 0.2: This just tells AWS which version of the buildspec format we're using.

phases: Think of these as the different stages your build goes through: install is the "prep work" phase - here, we're telling CodeBuild to use Java 8. pre_build are tasks to do before the main building starts. Here, we're grabbing a security token so we can access our dependencies. build is where the actual building happens. We're using Maven (a popular Java build tool) to compile our code. post_build are the finishing touches after the main build is done. Here, we're packaging everything into a WAR file (a format for web applications).

artifacts tells CodeBuild which files to save as the output of the build. In our case, we want that WAR file we created during the post_build phase.

In the buildspec.yml file:
- Replace the placeholder AWS Account ID 123456789012 with your actual AWS Account ID.
- Check that the region code is correct! Update the region section from --region us-east-2 to the AWS region you're using.

Where do I find my account ID?

You can find your Account ID in the AWS Management Console, at the top right corner under your username.

💡 Where do I find my region code?

Expand the region selector on the top right corner of the AWS Management Console. Spot the code right next to your current region!

Save the buildspec.yml file (press Ctrl+S or Cmd+S on the keyboard).

Confirm that the small circle indicator on the buildspec.yml file tab disappears after saving, which means the file is saved.

Now, we need to commit and push the buildspec.yml file to your GitHub repository so CodeBuild can access it.
Open the terminal in VS Code (Ctrl+or Cmd+).
Run the following Git commands:

git add .
git commit -m "Adding buildspec.yml file"
git push

Seeing errors when pushing your code?

Try resetting your Git credentials, and starting over again! Run these commands in your terminal:

git config --global --unset credential.helper
git config --local --unset credential.helper
git remote set-url origin https://[[GITUSERNAME="<github_username>"]]@github.com/[[GITUSERNAME="<github_username>"]]/[[REPONAME="<repository_name>"]].git

Make sure to replace <YOUR_GITHUB_USERNAME> with your GitHub username and <YOUR_REPOSITORY_NAME> with your repository name.
Then try git push again and enter your GitHub PAT when prompted for the password.

Why push buildspec.yml to GitHub?

We need to push our buildspec.yml file to GitHub because CodeBuild doesn't look inside your local computer for build instructions - it looks in your GitHub repository.

When CodeBuild connects to your GitHub repo, it first looks for this special file. Without it, CodeBuild has no idea what to do with your code. By pushing the file to GitHub, we're making sure our instructions travel alongside our code.

Go to your GitHub repository nextwork-web-project in your browser and refresh the page to verify that buildspec.yml is now present in the repository.

Check the terminal output to ensure the changes, including the new buildspec.yml file, have been successfully pushed to your GitHub repository.

Go to your GitHub repository in a web browser and refresh the page.
buildspec.yml should be in your GitHub repo now - yay!

Confirm that you can see the buildspec.yml file listed in your GitHub repository in the browser.

Verify Successful Build and Artifacts

Now that we've fixed our CodeBuild setup, let's re-run the build process. We'll also check our S3 bucket to see if it's storing the build artifact correctly.

In this step, you are going to:

Re-run the build process in CodeBuild.
Troubleshoot a second build failure, this time by giving CodeBuild the permission to access CodeArtifact.
Run and verify a successful build!

Retry your build

Return to the CodeBuild console in your browser.
Retry the build by clicking the Retry build button.

The build status should now show In progress. Wait for this build to complete.

Damn it, we failed again!
Check the Phase details tab again after this retry.
You will likely see that the DOWNLOAD_SOURCE phase succeeded this time, but other phases might have failed!

What does this error mean?

Goooood question. This error typically means CodeBuild still can't access the settings.xml file.

This usually happens because our CodeBuild service role doesn't have permission to access CodeArtifact, which is needed to download project dependencies.

To fix this, we need to grant CodeBuild's IAM role the permission to access CodeArtifact.

Head to the IAM console.

In the IAM console, select Roles in the left navigation menu.

In the roles search bar, type codebuild to filter the roles.

Select the role that starts with codebuild-nextwork-devops-cicd-service-role. This is the new service role that CodeBuild created when we set up our build project.

Select your CodeBuild service role.
Click on the Add permissions button.

Choose Attach policies.

In the Filter policies search bar, type codeartifact-nextwork-consumer-policy.
Check the checkbox next to the policy named codeartifact-nextwork-consumer-policy.

You can even expand the policy name to review the permissions granted by this policy.

After selecting the policy, click the Add permissions button.

You should see a green banner confirming Policy was successfully attached to role. and the policy should now be listed under the Permissions policies of your CodeBuild service role.

Return to the CodeBuild console, navigate to your nextwork-devops-cicd project.
Retry the build one more time by clicking Retry build.

The build status should again be In progress. With the added permissions, this time the build should proceed successfully! 🙏

NICE - the build status should now be Succeeded with a green checkmark, indicating a successful CI pipeline run!

Let's check if our build process has successfully created and stored the artifact 🏃‍♀️

To verify the successful build, let's check if the build artifact was correctly uploaded to our S3 bucket.
Head to the S3 console.
Select Buckets from the left navigation menu.
Select the nextwork-devops-cicd bucket you created earlier.

Initially, the bucket might be empty. Click Refresh to update the bucket content.

Why check for build artifacts in S3?

By confirming that an artifact exists in your S3 bucket, you know that:

Your code was successfully compiled and packaged
The build process completed without errors
The artifact was properly uploaded to its destination
The artifact is now available for the next step in your process (like deployment)

Think of it as the final proof that your CI process is delivering what it promised!

Click Refresh again if needed.
You should now see the artifact nextwork-devops-cicd-artifact.zip listed in your bucket 👀

If you choose to download and inspect the artifact, you should find the nextwork-web-project.war file inside the downloaded zip archive, confirming the build process produced the expected output.

Secret mission

Want to experience the full power of CodeBuild?

Here's your chance to go beyond just continuous building!

Your secret mission, should you choose to accept it, is to automate testing with CodeBuild.

In this secret mission, you're going to:

Create a simple unit test for your Java web application
Trigger a build to see your tests run automatically
Showcase advanced continuous integration skills in your documentation!

Automate Testing Too!

Delete your resources

Now that we've configured our CI pipeline, it's time to clean up the resources we created. This is important to avoid getting charged for unused resources.

Resources to delete:

Delete the CodeBuild project.
Delete the S3 bucket.
Delete the EC2 instance.
Delete the IAM roles and policies.
Delete the CodeArtifact domain and repository.
Delete your local files.
Delete the GitHub personal access token.

CodeBuild

Head to the CodeBuild console.
Select Build projects from the left hand menu.
Select the nextwork-devops-cicd project.
Click Actions and select Delete build project.
Type delete in the confirmation field.
Select Delete.

CodeConnection

Expand the Settings arrow at the bottom of the left hand navigation panel.
Select Connections.
Select your connection.
Select Delete
Confirm the deletion by typing delete and clicking Delete.

S3

Head to the S3 console.
Select Buckets from the left hand menu.
Select your S3 bucket (nextwork-devops-cicd).
Select Empty.
Type permanently delete in the confirmation field.
Select Empty to confirm emptying the bucket.
Once the bucket is empty, select it again and select Delete.
Type nextwork-devops-cicd in the confirmation field.
Confirm the deletion.

EC2

Head to the EC2 console.
Select Instances from the left hand menu.
Select your instance (nextwork-devops-yourname).
Select Instance state > Terminate instance.
Select Terminate to confirm.
Wait for the instance to show "Terminated" status before proceeding with other cleanup tasks.

Why terminate your EC2 instance?

EC2 instances continue to incur charges as long as they're in the "running" state. By terminating the instance (not just stopping it), you ensure you won't be billed for compute resources you're no longer using.

IAM

Head to the IAM console.
Select Roles from the left hand menu.
Search for EC2-instance-nextwork-cicd.
Select the role.
Select Delete.
Confirm the deletion by typing Delete and selecting Delete.
Delete codebuild-nextwork-web-build-service-role next.

Next, select Policies from the left hand menu.
Search for codeartifact-nextwork-consumer-policy
Select the policy.
Select Delete policy.
Confirm the deletion by typing Delete and selecting Delete.

Why clean up IAM resources?

While IAM roles and policies don't incur direct costs, maintaining unused permissions increases your security risk surface area and complicates access management. Following the principle of least privilege means removing access rights when they're no longer needed.

CodeArtifact

Head to the CodeArtifact console.
Select Repositories from the left hand menu.
Select nextwork-devops-cicd.
Select Delete repository.
Confirm the deletion by typing delete and selecting Delete repository.
After deleting the repository, select Domains from the left hand menu.
Select nextwork.
Select Delete domain.
Confirm the deletion by typing delete and selecting Delete domain.

Why delete CodeArtifact resources?

CodeArtifact charges are based on storage and API requests. Even if you're not actively using your repository, you'll continue to pay for storing any packages that were cached during your project work.

Local Files

Go to your Desktop or wherever you stored your project files.
Delete the DevOps folder containing the nextwork-keypair.pem file.
You can also delete any local copies of the web app code.

Why delete key pair files?

The .pem file is essentially a private key that provides access to your EC2 instance. Even though the instance is terminated, it's a security best practice to delete private keys when you no longer need them to prevent any unauthorized access if you ever reuse the key name.

GitHub PAT

Head to your GitHub account.
Select your profile icon in the top right corner of the screen.
Select Settings from the dropdown menu.
In the left sidebar, select Developer settings.
Select Personal access tokens, then Tokens (classic).
Find the PAT you created for this project.
Select Delete next to the token.
Confirm the deletion.

Why delete GitHub PATs?

It's a security best practice to delete tokens when you no longer need them to prevent any unauthorized access to your GitHub account and repositories. Even if the token has an expiration date, it's better to explicitly delete it when you're done with a project.

Get your documentation!

Nice work! 🚀 You've just configured a CI pipeline using AWS CodeBuild.

You've learned how to:

⚙️ Set up a CodeBuild project and connect it to a GitHub repository.
📝 Define a build process using buildspec.yml.
📦 Store build artifacts in Amazon S3.
🔑 Update CodeBuild's IAM roles to allow permissions to CodeArtifact.
🛠️ Troubleshoot common build errors and ensure successful builds.
💎 Set up CodeBuild to go beyond the build process - and automate testing too!

Ready to quiz yourself? You got this! 💪

Next up, we're going to continue the journey of our web app by setting up CodeDeploy to deploy our web app to an EC2 instance. Are you ready to get your web app live and public for the world to see?!

See you in the next project of the 6 Day DevOps Challenge - Deploy a Web App with CodeDeploy!

p.s. Does it say "Still tasks to complete!" at the bottom of the screen?

This means you still have screenshots left to upload, or questions left to answer!

Press Ctrl+F (Windows) or Command+F (Mac) on your keyboard.
Search for the text Return to later.
Jump straight to your incomplete tasks!
🙋‍♀️ Still stuck? Ask the community!