True Continuous Integration with CodeBuild

Automate Java app builds on every GitHub push using CodeBuild webhooks.

Introduction

30 Second Summary

Imagine changing a single line of code and having to manually click a button every time you want to test if it still works. That's what building software looks like without automation.

In this project, you will connect AWS CodeBuild to your GitHub repository using a webhook so that every code push automatically triggers a build. You'll experience the real Continuous Integration loop: push, watch, fix, push again.

What You'll Build

You'll push code to GitHub, switch to the CodeBuild console, and watch the build kick off on its own within seconds. When you deliberately break your code, CI catches the error before it reaches production. When you fix it, the next push goes green automatically.

By the end of this project, you'll have:

  • An automated build pipeline that triggers within seconds of every git push to GitHub, with no manual clicks required.
  • Real CI troubleshooting experience from diagnosing build failures using CodeBuild logs and phase details, then fixing them and watching the next push succeed.
  • A deployment-ready WAR artifact automatically packaged and stored in S3 after every successful build.
  • Secret Mission: Configure SNS email notifications so you get alerted about build results without watching the console.

Are there any prerequisites?

This project is Day 4 of the 6 Day DevOps Challenge. You need Days 1-3 completed: an EC2 instance running with Maven and Java, a GitHub repo with your web app code, and a CodeArtifact repository configured.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. This is the moment you commit to the goal so every hands-on step that follows has a clear purpose.

Create Your CodeBuild Project with Webhook

Right now, every time you want to build your Java web app, you would have to sign in to the AWS Console and manually click a button. That defeats the purpose of automation.

In this step, you will create a CodeBuild project connected to your GitHub repository via a webhook. The webhook is the piece that makes your integration truly continuous. Every time you push code, GitHub will notify CodeBuild to start building automatically.

In this step, get ready to:
  • Create an S3 bucket to store your build artifacts.
  • Create a CodeBuild project connected to GitHub with webhook enabled.
  • Verify the webhook is active in both AWS and GitHub.
Create the S3 bucket for build artifacts

When CodeBuild successfully compiles your app, it produces a packaged artifact (a WAR file). You need somewhere to store that artifact. Amazon S3 is the standard choice for build output storage.

  • Sign in to the AWS Management Console.
  • In the search bar at the top, type S3 and select the S3 service.
  • Click Create bucket.
  • In the Bucket name field, enter nextwork-devops-cicd- followed by your name (e.g., nextwork-devops-cicd-jane).
  • Make sure the AWS Region matches the region you used for your other resources (your EC2 instance and CodeArtifact repository).
  • Leave all other settings as default.
  • Scroll down and click Create bucket.

You should see a green success banner confirming your bucket was created.

Why do I need an S3 bucket for this?

CodeBuild needs a destination for the files it produces. Without an S3 bucket configured, your build output (the WAR file) would disappear after the build completes. Storing artifacts in S3 means you can deploy them later or inspect them anytime.

Create the CodeBuild project with webhook enabled

Now you will create the CodeBuild project itself and connect it to your GitHub repository with a webhook. This is where you configure how CodeBuild builds your code, what environment it uses, and where it stores the results.

  • In the AWS Console search bar, type CodeBuild and select the CodeBuild service.
  • In the left navigation pane, expand Build and select Build projects.
  • Click Create build project.
  • In Project name, enter nextwork-devops-cicd.
  • In the Source section, for Source provider, select GitHub.
  • If prompted, follow the instructions to connect your GitHub account and click Authorize.
  • For Repository, select Repository in my GitHub account.
  • In the GitHub repository dropdown, select your nextwork-web-project repository.

What is a webhook?

A webhook is a notification system between two services. When you enable a webhook here, GitHub will send a message to CodeBuild every time you push code to your repository. CodeBuild then automatically starts a build without you doing anything.

This is what separates true Continuous Integration from manual builds. The build happens on every push, giving you instant feedback about whether your code is healthy.

  • In the Primary source webhook events section, check Rebuild every time a code change is pushed to this repository.
  • For Event type, select PUSH.

Leave other filter settings empty

You do not need to add any filters under "Start a build under these conditions" or "Don't start a build under these conditions". For this project, you want every push to trigger a build.

  • Scroll down to the Environment section.
  • For Provisioning model, select On-demand.
  • For Environment image, select Managed image.
  • For Compute, select EC2.
  • For Operating system, select Amazon Linux.
  • For Runtime(s), select Standard.
  • For Image, select aws/codebuild/amazonlinux-x86_64-standard:corretto8.
  • For Service role, select New service role and leave the auto-generated role name as-is.

Why this environment image?

The aws/codebuild/amazonlinux-x86_64-standard:corretto8 image includes Java Corretto 8 and Maven, which matches the setup on your EC2 instance. This ensures your builds use the same Java version you develop with.

  • Scroll to the Buildspec section.
  • Select Use a buildspec file.
  • Leave the Buildspec name field empty (CodeBuild will look for the default buildspec.yml in your repository root).
  • Scroll to the Artifacts section.
  • For Type, select Amazon S3.
  • For Bucket name, select your nextwork-devops-cicd-yourname bucket from the dropdown.
  • In Name, enter nextwork-devops-cicd-artifact.
  • For Artifacts packaging, select Zip.

What does the Artifacts section do?

The Artifacts section tells CodeBuild what to do with the files it produces after a successful build. By selecting S3 and Zip, you are telling CodeBuild to package your compiled WAR file into a zip archive and upload it to your S3 bucket after each build.

  • Scroll to the Logs section.
  • Make sure CloudWatch logs is checked.
  • In Group name, enter /aws/codebuild/nextwork-devops-cicd.
  • Click Create build project at the bottom of the page.

You should see your new nextwork-devops-cicd project appear in the CodeBuild console.

Don't see your project?

Make sure you clicked Create build project at the very bottom of the page, not the Start build button. If you see a validation error, scroll up to find the field highlighted in red and fix the value.

If the GitHub authorization failed, try disconnecting and reconnecting your GitHub account in the Source section. Help me troubleshoot my CodeBuild project creation.

Verify the webhook is active

CodeBuild automatically creates a webhook in your GitHub repository when you enable the option. You can confirm this from both sides.

  • In the CodeBuild console, click on your nextwork-devops-cicd project.
  • Select the Build details tab.
  • In the Source section, confirm it shows GitHub as the source provider with the webhook enabled.

Before you check GitHub, what do you think you will find in your repository's webhook settings?

  • Open your GitHub repository in a browser tab.
  • Click Settings at the top of the repository page.
  • In the left sidebar, click Webhooks.
  • Confirm that a new webhook from AWS appears in the list with a green checkmark indicating a successful delivery.

The webhook URL points to an AWS endpoint. This is the connection between GitHub and CodeBuild. Every time you push code, GitHub sends a payload to that URL, and CodeBuild starts a new build.

No webhook in GitHub?

If you do not see a webhook listed, your GitHub authorization may not have completed successfully. Go back to your CodeBuild project, click Edit on the Source section, reconnect your GitHub account, and save the changes.

Help me fix my missing webhook.

Your CodeBuild project is wired up and listening to GitHub. Next up, you will push a code change and watch the webhook trigger your first automatic build.

Trigger Your First Automatic Build

Your CodeBuild project is set up and the webhook is wired to your GitHub repo. Now comes the moment of truth: will pushing code to GitHub actually trigger a build automatically?

In this step, you will push a small code change and watch CodeBuild react on its own. No clicking "Start build." The webhook does the work.

In this step, get ready to:
  • Push a code change to GitHub and confirm it triggers a build automatically.
  • Observe the build status in the CodeBuild console.
  • Diagnose why the build failed using Phase details.
Make a small change and push to GitHub

To test the webhook, you need to push any change to your repository. Even a one-word edit is enough to fire the trigger.

  • In your VS Code window (already connected to your EC2 instance via Remote-SSH), open src/main/webapp/index.jsp from the Explorer sidebar.
  • Find a paragraph line in the HTML body and change the text to something different. For example, update the greeting or description text.
  • Save the file.
  • Stage, commit, and push the change by running these commands in the VS Code terminal:
git add .
git commit -m "Testing webhook trigger"
git push

What do these commands do?

These three commands form the standard Git workflow for sharing changes.

  • git add . stages all changed files for commit.
  • git commit -m "..." saves the staged changes as a snapshot with a message.
  • git push uploads the commit to GitHub. This is the action that fires the webhook.

You should see output confirming the push was successful, ending with a line like To https://github.com/... followed by a branch reference.

Push rejected or authentication failed?

  • Make sure your GitHub Personal Access Token is still valid. If it expired, generate a new one and update your remote credentials.
  • Confirm you are on the correct branch by running git branch. You should be on main (or master).

Help me troubleshoot why my git push to GitHub is failing

Watch CodeBuild react automatically

Before you check the CodeBuild console, pause for a moment. Do you think the build will succeed or fail? Why?

  • Switch to the AWS Management Console in your browser.
  • Navigate to CodeBuild, then select Build projects from the left sidebar.
  • Click on your nextwork-devops-cicd project.
  • Look at the Build history section at the bottom of the page.

Within seconds of your push, a new build appears in the history with status "In progress" (then quickly changes to "Failed"). You did not click anything to start it. The webhook fired automatically.

What just happened?

When you pushed to GitHub, GitHub sent an HTTP POST request to the webhook URL that AWS created during your project setup. That request told CodeBuild "new code was pushed" and CodeBuild immediately started a build.

This is what makes it continuous integration. Every push triggers the pipeline automatically. No human needs to remember to click a button.

Diagnose the failure

The webhook worked perfectly. But the build itself failed. Time to find out why.

  • Click on the failed build run in your Build history (it will have a red "Failed" status).
  • Select the Phase details tab.

Look at the DOWNLOAD_SOURCE phase. It shows a failure with this message:

YAML_FILE_ERROR: YAML file does not exist

This tells you exactly what happened. CodeBuild downloaded your source code from GitHub, then looked for a buildspec.yml file in the root directory. It could not find one because you have not created it yet.

Why does CodeBuild need a buildspec.yml?

A buildspec.yml is CodeBuild's instruction file. It tells CodeBuild which runtime to use, which commands to run, and where to find the output artifacts.

Without it, CodeBuild has no idea how to build your project. It is like handing someone a box of ingredients with no recipe.

Don't see a build in the history?

  • Confirm your git push succeeded (check for errors in the terminal output).
  • In your GitHub repo, go to Settings > Webhooks and check that the AWS webhook shows a recent delivery with a green checkmark.
  • Make sure you are looking at the correct region in the AWS console. Your CodeBuild project must be in the same region where you created it.

Help me figure out why my CodeBuild webhook isn't triggering a build

This failure is a good thing. It proves two important points: the webhook is working (builds trigger automatically on every push), and CodeBuild tells you exactly what is missing. In the next step, you will create the buildspec.yml file and push again to see what happens.

Add Your Buildspec and Push Again

Your webhook is working. The moment you pushed code, CodeBuild started a build automatically. But it failed because it had no instructions for how to build your app.

CodeBuild uses a file called buildspec.yml to know what commands to run during a build. In this step, you'll create that file and push it to GitHub. The webhook will fire again, but you'll hit a new obstacle along the way.

In this step, get ready to:
  • Create a buildspec.yml file that tells CodeBuild how to build your Java app.
  • Push the file to GitHub and watch the webhook trigger a new build.
  • Diagnose why the build fails this time with a different error.
Create buildspec.yml in your project root

A buildspec.yml is CodeBuild's instruction manual. It defines the phases of your build: what runtime to install, what commands to run, and what files to output as artifacts.

  • In VS Code (connected to your EC2 instance), right-click in the Explorer sidebar at the root level of nextwork-web-project.
  • Select New File and name it buildspec.yml.
  • Paste the following content into the file:
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 [[AWS_ACCOUNT_ID="123456789012"]] --region [[AWS_REGION="us-east-1"]] --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 does this file do?

  • install phase: tells CodeBuild to use the Java Corretto 8 runtime, matching what's on your EC2 instance.
  • pre_build phase: fetches an authentication token from CodeArtifact so Maven can pull your project's dependencies.
  • build phase: runs mvn clean install to compile your code and run tests.
  • post_build phase: packages your app into a WAR file using mvn package.
  • artifacts section: tells CodeBuild to collect any .war file from the target/ folder and upload it to your S3 bucket.

Where do I find my AWS account ID and region?

Your 12-digit AWS account ID is displayed in the top-right corner of the AWS console when you click your username. Your region (e.g. us-east-1) appears in the region dropdown next to it. Use the same region where you created your other resources in previous days.

  • Replace the placeholder account ID and region with your actual values.
  • Save buildspec.yml.
  • Confirm the file exists in the right location by running this in the VS Code terminal:
ls buildspec.yml

You should see buildspec.yml printed in the output. If you see "No such file or directory", you may have created it inside a subfolder instead of the project root.

Don't see the file?

Make sure you created buildspec.yml at the top level of nextwork-web-project, not inside src/ or any other subfolder. CodeBuild looks for it in the root directory of your source code.

help me figure out why CodeBuild can't find my buildspec.yml file

✔️ Awesome, I've got everything!

Great. Double check you've saved buildspec.yml and it's in the root of nextwork-web-project.

ⓧ I'd like to double check the full code

Here is the complete buildspec.yml for reference. Make sure yours matches this structure, with your own account ID and region substituted in:

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 [[AWS_ACCOUNT_ID="123456789012"]] --region [[AWS_REGION="us-east-1"]] --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
Push buildspec.yml to GitHub

Your buildspec is ready. Now push it to GitHub and let the webhook do its thing.

Before you push, think about this: you fixed the missing file problem. Do you think the build will succeed this time, or is there something else that could go wrong?

  • Commit and push your new file by running these commands in the VS Code terminal:
git add .
git commit -m "Add buildspec.yml for CodeBuild"
git push
  • Switch to the CodeBuild console immediately after pushing.
  • Click on your nextwork-devops-cicd project, then check Build history.

A new build appears automatically. The webhook fired again. Watch it progress through the phases.

This time, the DOWNLOAD_SOURCE phase succeeds. CodeBuild found your buildspec.yml. But wait for the build to finish. It still fails.

Diagnose the new failure

The build failed again, but in a completely different phase. That's progress. The first failure was at DOWNLOAD_SOURCE. This one is further along.

  • Click into the failed build in your Build history.
  • Select the Phase details tab.
  • Look at which phase failed. This time, it's the BUILD phase, not DOWNLOAD_SOURCE.

The error is an authorization failure related to CodeArtifact. CodeBuild's service role doesn't have permission to fetch the authentication token from CodeArtifact.

Why does this make sense?

Your EC2 instance has an IAM role that lets it access CodeArtifact. You set that up on Day 3. But CodeBuild is a completely separate service with its own IAM role.

The service role codebuild-nextwork-devops-cicd-service-role was auto-created with basic CodeBuild permissions only. It knows nothing about CodeArtifact. You need to explicitly grant it access.

Not seeing a BUILD phase error?

If your build failed at DOWNLOAD_SOURCE again with a YAML error, double check that buildspec.yml is in the root of your repository and that your YAML indentation uses spaces (not tabs).

If you see a different error, check the Build logs tab for more detail.

help me understand why my CodeBuild build is failing at an unexpected phase

You've now experienced two different build failures, each one giving you a clear clue about what to fix next. In the next step, you'll grant CodeBuild the permissions it needs and finally get a green build.

Fix Permissions and Achieve a Green Build

Your last build failed because CodeBuild couldn't authenticate with CodeArtifact to pull your project's dependencies.

CodeBuild runs under its own IAM role, completely separate from your EC2 instance. Your EC2 instance already has CodeArtifact access (from Day 3), but CodeBuild doesn't know about that. You need to explicitly grant the CodeBuild service role the same permission.

In this step, get ready to:
  • Attach a CodeArtifact permissions policy to CodeBuild's service role.
  • Push a code change and watch it trigger a fully successful build.
  • Confirm the WAR artifact is stored in your S3 bucket.
Attach CodeArtifact policy to CodeBuild's service role

The fix is straightforward: attach the same CodeArtifact consumer policy to CodeBuild's auto-created service role.

  • In the AWS Management Console, navigate to the IAM service.
  • Select Roles in the left sidebar.
  • Search for codebuild-nextwork-devops-cicd-service-role in the search bar.
  • Click on the role name to open it.
  • Click Add permissions, then select Attach policies.
  • Search for codeartifact-nextwork-consumer-policy.
  • Check the box next to the policy, then click Add permissions.

You should see a success banner confirming the policy was attached to the role.

Why does CodeBuild need its own policy?

Every AWS service that accesses other AWS resources needs explicit IAM permissions. Your EC2 instance has its own role with CodeArtifact access, but CodeBuild is a completely separate service.

Think of it like office key cards. Just because one employee has access to a room doesn't mean everyone does. Each service needs its own key card (IAM policy) to get through the door.

Can't find the policy?

Make sure you're searching for codeartifact-nextwork-consumer-policy exactly as written. This policy was created during Day 3 of the challenge.

If the policy doesn't exist, you may need to revisit your Day 3 setup to create it. Help me find or recreate my CodeArtifact consumer policy

Trigger a new build by pushing a change

The permission fix is in place. Now you need to trigger a new build to test it. The webhook is still active, so any push to GitHub starts a build automatically.

  • Switch back to VS Code (connected to your EC2 instance via Remote-SSH).
  • Open src/main/webapp/index.jsp.
  • Make a small edit to the greeting text (for example, change it to say something new).
  • Save the file.
  • Commit and push your change by running these commands in the terminal:
git add .
git commit -m "Trigger build after fixing permissions"
git push

Before you switch to the CodeBuild console, take a moment to think. Do you expect this build to succeed or fail? Why?

  • Switch to the CodeBuild console immediately after pushing.
  • Watch the build appear in Build history and progress through each phase.

What should I see?

A new build kicks off automatically within seconds. This time, the BUILD phase should succeed because CodeBuild can now authenticate with CodeArtifact to download Maven dependencies.

The build takes roughly 2-3 minutes as Maven downloads dependencies and compiles your WAR file. Watch the phases progress: SUBMITTED, QUEUED, PROVISIONING, DOWNLOAD_SOURCE, INSTALL, PRE_BUILD, BUILD, POST_BUILD, UPLOAD_ARTIFACTS, FINALIZING.

Verify the successful build and artifact

This is the moment of truth. If the permissions are correct, you should see your first green build.

  • Confirm the build status shows Succeeded with a green checkmark.
  • Navigate to S3 in the AWS console.
  • Open your nextwork-devops-cicd-yourname bucket.
  • Confirm nextwork-devops-cicd-artifact.zip is present in the bucket (refresh if needed).

This zip file contains your nextwork-web-project.war file, built entirely by the automated pipeline.

What is a WAR file?

A WAR (Web Application Resource) file is a packaged Java web application ready for deployment to an application server. It contains your compiled code, configuration files, and static assets bundled into a single deployable unit.

Build still failing?

If the build still fails in the BUILD phase with an authorization error, double-check that you attached codeartifact-nextwork-consumer-policy to the correct role: codebuild-nextwork-devops-cicd-service-role.

Also verify that the domain name and account ID in your buildspec.yml match your actual AWS account. Click into the failed build's Build logs tab to see the exact error message.

My CodeBuild build is still failing after I attached the CodeArtifact policy. Help me debug.

You just experienced what a real CI pipeline feels like. You pushed code, and within minutes a fully automated process compiled it, packaged it, and stored a deployment-ready artifact in S3. Next up, you'll test the safety net that makes CI truly powerful: what happens when you push broken code.

Break It, Then Fix It - The CI Safety Net

Your CI pipeline is fully operational. Every push triggers a build, and successful builds produce deployment-ready artifacts in S3.

The real power of Continuous Integration is catching broken code before it reaches production. You'll deliberately introduce a bug to experience the push-break-fix-push loop that developers use every day.

In this step, get ready to:
  • Introduce a deliberate bug in your project's pom.xml.
  • Watch CodeBuild catch the bug automatically without you clicking anything.
  • Fix the bug and watch CI confirm the fix with a green build.
Introduce a deliberate bug

You need a code change that will make Maven fail immediately. Corrupting the XML structure of pom.xml is perfect for this because Maven cannot even start the build if it cannot parse its own configuration file.

  • In VS Code (connected to your EC2 instance), open pom.xml in the root of your nextwork-web-project folder.
  • Find the opening <project> tag near the very top of the file (typically on line 2, right after the XML declaration).
  • It starts like this:
<project
  • Remove the letter e from the word project so the tag now starts with:
<projct
  • Save pom.xml.

Why this specific break?

Maven requires its pom.xml to be valid XML with <project> as the root element. Breaking the root tag name makes it impossible for Maven to parse the file at all. This produces a clear, immediate failure that is easy to diagnose from the build logs.

  • Commit and push the broken code by running these commands:
git add .
git commit -m "Introduce a bug"
git push

Push rejected or authentication error?

Make sure your GitHub Personal Access Token is still valid. If it expired, generate a new one in GitHub under Settings > Developer settings > Personal access tokens.

Help me fix my git push authentication error.

Watch CI catch the bug

Before you switch to the CodeBuild console, think about what you expect to happen. Will this build succeed or fail? At which phase?

  • Switch to the CodeBuild console immediately after pushing.
  • Within seconds, a new build appears in Build history with status In progress.

The webhook triggered the build automatically. Watch it progress through phases until it fails.

  • Click into the failed build.
  • Select the Phase details tab.
  • Confirm the BUILD phase failed. Maven could not parse the broken pom.xml because the root element name is invalid.
  • Select the Build logs tab to see the actual Maven error message. You'll see a Non-parseable POM error pointing at the broken tag.

This is CI doing its job. It caught a bug within seconds of your push, before anyone could deploy broken code to production.

What just happened?

You pushed broken code. The webhook notified CodeBuild. CodeBuild pulled your repo, tried to run Maven, and Maven immediately failed because it could not parse pom.xml. The build status shows Failed in the BUILD phase.

In a real team, this failure would block the broken code from reaching a deployment pipeline. Nobody had to manually check anything.

Fix the bug and watch CI recover

Now you'll fix the typo and push again. The webhook fires again, and this time the build should go green.

  • Return to VS Code and open pom.xml.
  • Find the broken tag that starts with:
<projct
  • Add the letter e back so it reads:
<project
  • Save pom.xml.
  • Commit and push the fix by running these commands:
git add .
git commit -m "Fix pom.xml typo"
git push

Before you check the CodeBuild console, what do you expect to see this time?

  • Switch to the CodeBuild console.
  • Watch the new build progress through DOWNLOAD_SOURCE, INSTALL, PRE_BUILD, BUILD, and POST_BUILD.
  • The build status shows Succeeded with a green checkmark.

Your pipeline recovered on its own. You fixed the code, pushed, and CI confirmed the fix automatically.

  • Navigate to S3 in the AWS console.
  • Open your nextwork-devops-cicd-yourname bucket.
  • Confirm nextwork-devops-cicd-artifact.zip is present with an updated timestamp. This zip contains your nextwork-web-project.war file, rebuilt from your fixed code.

What is the CI feedback loop?

You just completed the full CI loop: push, break, diagnose from logs, fix, push again, confirm green. This is the exact workflow developers on real engineering teams follow every day.

The key insight is that CI caught the broken code in seconds. Nobody had to run a manual build, check a deployment, or review the change first. The automation handled it.

Build still failing after the fix?

Double-check that you restored the exact spelling <project (with the letter e). Open pom.xml and compare the opening tag against the closing </project> tag at the bottom of the file. They must match exactly.

Also confirm your git push completed successfully. If you see no new build in CodeBuild, the push may not have reached GitHub.

Help me figure out why my build is still failing after fixing pom.xml.

Secret mission

Get Email Notifications for Build Results

A truly hands-off CI pipeline does not require you to watch the console. In this secret mission, you will configure Amazon SNS and Amazon EventBridge so that you get an automated email every time a build succeeds or fails. Push code, walk away, and let the notification find you.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses AWS free tier services, so ongoing costs are minimal. However, the EC2 instance from Day 1 is only free-tier eligible for 12 months.

Continuing to Day 5 or Day 6?

If you plan to continue to Day 5 (CodeDeploy) or Day 6 (CodePipeline), keep all your resources running. Before starting Day 6, disable the webhook on your CodeBuild project to avoid double builds. To disable: edit your CodeBuild project, go to the Source section, and uncheck "Rebuild every time a code change is pushed to this repository."

Resources you used:

  • CodeBuild project nextwork-devops-cicd (free for first 100 build minutes/month on build.general1.small).
  • S3 bucket nextwork-devops-cicd-yourname (minimal storage cost for WAR artifacts, effectively free at this scale).
  • EC2 instance (from Day 1, t2.micro is free tier eligible for 12 months).
  • IAM role codebuild-nextwork-devops-cicd-service-role with attached policies.
  • CloudWatch Logs group for build logs (minimal cost).
  • SNS topic codebuild-notifications with email subscription (Secret Mission).
  • EventBridge rule for CodeBuild state changes (Secret Mission).

Keep everything running

No action needed. Choose this if you plan to continue to Day 5 (Deploy an App with CodeDeploy) or Day 6 (CodePipeline).

  • Your CodeBuild project stays ready and will trigger on your next push.
  • Your EC2 instance remains running and accessible via VS Code Remote-SSH.
  • Build artifacts stay in your S3 bucket for future deployment steps.

Pause - I'll come back to this later

Shut down running processes to free up compute costs while keeping your project files and configuration intact.

  • In the EC2 console, select your instance, then choose Instance state and Stop instance.
  • Your CodeBuild project and S3 bucket remain configured and incur no charges while idle.
  • When you restart the EC2 instance later, the Public IPv4 DNS will change. Update your VS Code Remote-SSH configuration with the new address.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below to fully clean up.

  • Delete the CodeBuild project: open the CodeBuild console, choose Build projects, select the radio button next to nextwork-devops-cicd, and choose Delete.
  • Empty and delete the S3 bucket: open the S3 console, select your nextwork-devops-cicd-yourname bucket, choose Empty (confirm by typing permanently delete), then select the bucket again and choose Delete (confirm by typing the bucket name).
  • Delete the IAM role: open the IAM console, choose Roles, search for codebuild-nextwork-devops-cicd-service-role, select it, choose Delete, enter the role name to confirm, and choose Delete.
  • Delete the EventBridge rule (Secret Mission): open the EventBridge console, choose Rules, select your CodeBuild notification rule, choose Delete, then choose Delete again to confirm.
  • Delete the SNS topic (Secret Mission): open the SNS console, choose Topics, select codebuild-notifications, choose Delete, type delete me in the confirmation field, and choose Delete.
  • Terminate the EC2 instance: open the EC2 console, select your instance, choose Instance state, then Terminate instance.
  • Delete the CodeArtifact repository and domain: open the CodeArtifact console, delete your repository first, then delete the domain.
  • Revoke your GitHub Personal Access Token: in GitHub, go to Settings, then Developer settings, then Personal access tokens, find your token, and choose Delete.

That's a Wrap!

That's a Wrap!

Nice work! You just built a fully automated CI pipeline where every git push triggers a build, broken code gets caught immediately, and successful builds produce deployment-ready artifacts in S3.

You've learned how to:

  • Set up a CodeBuild project connected to GitHub via webhook so every push automatically triggers a build without manual intervention.
  • Diagnosed and fixed two different build failures (missing buildspec.yml and missing IAM permissions) using CodeBuild logs and phase details.
  • Experienced the CI safety net by deliberately breaking code, watching CI catch the bug within seconds, fixing it, and confirming the pipeline recovered to green.
  • (Secret Mission) Configured SNS email notifications via EventBridge for hands-off build monitoring.

Ready to quiz yourself?