Fork and Modify Repository

In this section, you will fork the upstream sample application repository into your personal GitLab account and make a targeted source code modification. This establishes the foundation for our automated CI/CD pipeline targeting Amazon ECS and Amazon ECR.


Architectural Context

Our target application is a decoupled microservices-ready web application containing two primary components:

  • Frontend: A React single-page application (SPA) located in the frontend codebase, displaying a containerized management dashboard.
  • Backend: A Node.js/Express REST API located in the backend codebase, handling service data and health checks.

Forking creates an isolated, independent copy of the upstream repository under your personal GitLab namespace. This grants you the Maintainer/Owner permissions required to:

  • Configure custom CI/CD variables (AWS credentials, cluster names, service definitions).
  • Register dedicated self-hosted GitLab Runners.
  • Trigger automated build and deployment pipelines on Git tags without impacting other students.

Step 1: Fork the Upstream Repository

  1. Open your browser and navigate to the upstream repository:

  2. In the upper-right corner of the project overview page, click the Fork button.

    Fork Button

  3. On the Fork project configuration page, set the project parameters as described below:

    Configuration FieldRecommended ValueDescription
    Project nameaws-fcaj-container-appKeep the default name for consistency across lab instructions
    Project URL (Namespace)Personal Namespace (Dropdown)Required: Select your personal GitLab username namespace
    Project slugaws-fcaj-container-appAutomatically generated slug for the repository URL
    Branches to includeAll branchesCopies all development and release branches
    Visibility levelPublic (or Private)Public simplifies peer review; Private works if using self-hosted runners

    Fork Configuration

  4. Click Fork project to begin the process. GitLab will take a few seconds to clone the git objects into your account.

Selecting All branches ensures that you retain the full git commit history, release tags, and reference branches. This is best practice for auditing code lineages and testing branch-based deployment triggers.


Verify Successful Fork

Before making any changes, verify that your fork is ready:

  1. Notice the subtitle below the repository title: Forked from thienluhoan / aws-fcaj-container-app.
  2. Verify that the project tree contains the frontend, backend, and .gitlab-ci.yml files and directories.

Fork Result


Step 2: Modify Frontend Source Code

To validate that our automated CI/CD pipeline successfully builds, pushes, and deploys a new container image to Amazon ECS with zero downtime, we will introduce a noticeable visual update to the frontend header.

  1. In the repository file explorer, navigate to the file:

    • Path: frontend/src/components/Menu.jsx
  2. Click Edit, then select Edit single file (or use the GitLab Web IDE).

    Navigate to File

  3. Locate the dashboard title heading inside the component (around line 14):

    • Replace the existing text Dashboard with Dashboard v1.0.0:
    // Before:
    <p>Dashboard</p>
    
    // After:
    <p>Dashboard v1.0.0</p>
    

    Edit Content

  4. Scroll down to the Commit message section and configure the commit details:

    • Commit message: feat(frontend): update dashboard title to v1.0.0
    • Target branch: main
    • Click Commit changes.

    Commit Changes


Verify Git Commit

Confirm that your changes are committed to the main branch:

Verification ItemExpected ValueValidation Steps
BranchmainConfirm the branch dropdown displays main
Latest Commitfeat(frontend): update dashboard title to v1.0.0Navigate to Code → Commits to inspect the top commit
File ContentDashboard v1.0.0Open frontend/src/components/Menu.jsx and confirm the updated string

No pipeline has been triggered yet because our pipeline in .gitlab-ci.yml is configured to trigger on Git release tags (e.g., v1.0.0). In the next sections, we will provision a self-hosted runner and configure IAM permissions before triggering our deployment.