Laboratory Welcome App

Learning objectives and prerequisites

Use terminal builds, exact-output tests, branches, pull requests, and GitHub Actions to deliver a reproducible application. Explain your own contribution and review a teammate’s work.

Prerequisites: complete the Engineering Profile template; understand files, main(), output statements, compilation, and basic Git commands. Use output statements only—input, loops, and classes are not required.

Tools: Ubuntu terminal (Linux or Windows with WSL), g++, Git, GitHub, and an optional editor. Verify with g++ --version and git --version.

Course alignment: C++ program development, development tools, testing, teamwork, and technical communication. Official syllabus identifiers are pending confirmation.

Client brief and acceptance criteria

A teaching laboratory needs a console welcome screen. Agree on its exact output before implementation.

• Print a laboratory name and course identifier.
• List every team member and their project role.
• Print three numbered safety reminders and a closing message.
• Build without warnings using the commands below.
• Pass an exact-output test locally and in GitHub Actions.
• Include README instructions and a contribution record.
• Demonstrate a failed test followed by a reviewed correction.

No complete application solution is supplied for this assignment. Your team chooses the text and implements the requirements.

1. Assign and rotate responsibilities

• Implementation lead: prepares the source code.
• Test lead: defines expected output and verifies results.
• Automation lead: configures GitHub Actions.
• Documentation/release lead: checks the README and fresh-clone reproduction. Combine this role for a three-person team.

Every member must make a meaningful commit and review a teammate’s pull request. Roles organize work; they do not replace individual participation.

2. Establish the shared repository

One member creates week01-lab-welcome on GitHub with a README and invites teammates as collaborators. Create issues for application, tests, automation, and documentation. Every member then runs:

git clone https://github.com/TEAM-OWNER/week01-lab-welcome.git
cd week01-lab-welcome
git switch -c feature/YOUR-TASK
mkdir -p src tests .github/workflows

Replace TEAM-OWNER and YOUR-TASK with your actual values. Use a different branch for each task.

3. Agree on a project structure

src/main.cpp
tests/expected.txt
.github/workflows/cpp.yml
.gitignore
README.md
CONTRIBUTIONS.md

Record the agreed output in the requirements issue. The test lead creates tests/expected.txt from that agreement. Ignore the build/ directory. Write your application in src/main.cpp.

4. Build, run, and test in the terminal

mkdir -p build
g++ -std=c++17 -Wall -Wextra -pedantic src/main.cpp -o build/lab-welcome
./build/lab-welcome
./build/lab-welcome > build/actual.txt
diff -u tests/expected.txt build/actual.txt

A successful comparison produces no differences. Each member must run these commands, not only the implementation lead.

5. Submit work for peer review

git status
git add YOUR-CHANGED-FILES
git commit -m "Describe the completed change"
git push -u origin feature/YOUR-TASK

Replace YOUR-CHANGED-FILES with the files you changed. Open a pull request on GitHub and link its issue. Another team member checks correctness, clarity, tests, and accidental build files. Address feedback before merging. Avoid merging your own work without review.

After a merge, each teammate updates their local main branch:

git switch main
git pull --ff-only
git switch -c feature/NEXT-TASK

6. Configure GitHub Actions

Adapt the complete workflow in Class Project into .github/workflows/cpp.yml. It must run on push and pull_request, compile src/main.cpp to build/lab-welcome, execute that program, and compare its output with tests/expected.txt. Commit the workflow through a reviewed pull request.

Check the Actions logs. Both compilation and testing must pass. Intentionally change one output line on a branch to demonstrate a failing check, then correct it before merging. Document what the failure proved.

7. Verify and release

A teammate who did not implement the source performs a fresh-clone check:

cd ..
git clone https://github.com/TEAM-OWNER/week01-lab-welcome.git lab-welcome-verification
cd lab-welcome-verification
mkdir -p build
g++ -std=c++17 -Wall -Wextra -pedantic src/main.cpp -o build/lab-welcome
./build/lab-welcome > build/actual.txt
diff -u tests/expected.txt build/actual.txt

After all reviews and checks pass, the release lead tags the tested main branch:

git switch main
git pull --ff-only
git tag -a v1.0 -m "Week 1 team project release"
git push origin v1.0

Submission and assessment

• Repository and v1.0 tag links.
• Successful Actions run and evidence of the deliberate failure/correction.
• Reviewed pull requests and each member’s contribution in CONTRIBUTIONS.md.
• README with setup, build, run, test commands, example output, and any AI assistance.
• Each member’s terminal screenshot and a short explanation of compilation versus testing.