Homework 2

Build Fast CI and Prevent Secret Leaks

Turn your HW1 safety net into fast, enforced CI, then contain a secrets incident and add guardrails against future incidents.

Continuous integration Testing Static analysis Secrets management

Release Date Sep 7, 2026

Due Date Sep 20, 2026

Weight 200 pts (+ 20 bonus pts)

Overview

Your HW1 tests help when someone remembers to run them. Now make that evidence part of every proposed change. Put the pipeline design ideas from lecture into practice by building CI that is both fast and effective. In week one, build fast CI that controls merging. In week two, contain a secrets incident in the inherited repository and strengthen your guardrails against future mistakes.

Continue in your HW1 repository. You choose the tools, test design, and enforcement strategy; staff will test whether they deliver the required protection.

🎯 Learning Goals

• Turn local verification into reproducible CI and enforced merge decisions
• Balance protection, false alarms, and feedback time
• Investigate credential exposure and verify containment
• Use experiments to improve guardrails and explain their limits

🚩 Checkpoints

Checkpoint	Points	Due	Last accepted
Checkpoint A: Working CI	70 pts	Sep 13, 2026	Sep 17, 2026
Checkpoint B: Containment and Guardrails	130 pts	Sep 20, 2026	Sep 24, 2026

Due and last-accepted times are 11:59 p.m. Eastern Time.

Checkpoint A: Working CI

Build GitHub Actions CI on standard GitHub-hosted ubuntu-24.04 runners that:

• Automatically checks PRs targeting main when opened or updated, and commits reaching main.
• Works from a fresh checkout: installs from committed lockfiles, builds and type-checks the application, starts the full Compose system, and runs ./scripts/check with all inherited, HW1, and new tests.
• Blocks normal merging unless all required checks succeed for the current proposed revision. Missing checks and hidden failures must not permit merging.

Preserve the application's public interfaces, service topology, data model, Compose interface, and Dev Container. Adapt fixtures and configuration as needed while retaining the behavior protected by existing tests.

Shared Purchase Contract

Your automated checks must establish that a fresh customer can register, activate by email, sign in, find a published paid general-admission event, view its details, and purchase tickets through the supplied TartanPay service. Checkout must report success with the requested ticket count and correct total; the confirmation email must arrive, and authenticated order history must contain the matching order, count, and total.

Use fresh data and exercise customer behavior through public HTTP ingress. Event setup may use the administration API; email is available through Mailpit. The contract covers healthy services, one general-admission ticket type, sufficient capacity, a positive price in cents, and a positive quantity within the order limit. Submit the correct price × quantity total. Staff may vary these valid inputs. Coupons, cancellations, and concurrent purchases are outside this contract.

You may reuse HW1 tests. Additional inherited business-logic repairs are not required.

Feedback Budget — Both Checkpoints

Aim for three minutes; the hard limit is five minutes for the complete required CI evaluation, including setup and runs without dependency or build caches. Measure from the first required job starting to the last required result, excluding only observed waits for GitHub to allocate runners. All required workflows and checks intended to earn bonus credit share this budget. The existing five-minute limit for ./scripts/check still applies. Enforce job timeouts of at most five minutes and cancel superseded PR runs.

Staff measure PR, main, and uncached runs directly from GitHub Actions; no timing report or dedicated timing runs are required. Exceeding five minutes earns no feedback credit for that checkpoint (10 points at A; 15 at B).

Make every minute count

Inspect job timings to find unnecessary work. Explore dependency and build caching and small, focused tests alongside the required purchase journey. Cache reuse must preserve correct verification of the current revision, and all required tests must still run. Run inexpensive checks early and give service startup, requests, and tests short timeouts so failures stop work promptly. Consider total runner time as well as elapsed time when deciding what to parallelize.

Push deliberately

Develop on branches and merge through PRs instead of pushing work directly to main. Run relevant checks locally and push coherent changes; each update to an open PR also triggers CI. Avoid duplicate full evaluations from branch-push and PR triggers while retaining the required checks on PRs and main. Use concurrency controls to cancel superseded runs for the same PR.

Demonstrate Your CI

Create two distinct exercise PRs and link their relevant runs:

Label	Demonstration	Final state
hw2-safe	A harmless application or test change passes.	Merged
hw2-unsafe	An application regression in the shared journey or a build/type error fails a relevant check.	Unmerged

The unsafe exercise must break the application; an intentionally failing assertion or workflow exit alone does not count. Record your design and evidence in hw2/DESIGN.md using the template below.

Checkpoint B: Containment and Guardrails

Keep Checkpoint A working while completing the following.

Contain the Secrets Incident

Investigate credential exposure in the inherited repository, including its history and runtime behavior. Establish which findings grant access and contain them: exposed credentials must no longer authorize access, fresh credentials supplied outside Git must preserve normal operation, and neither tracked files nor captured output may expose them. Justify any findings you classify as harmless.

Record your findings, containment evidence, and fresh-credential setup in hw2/INCIDENT.md using the template below. Keep secret values out of reports and PRs. Preserve the HW1 and Checkpoint A commits; history rewriting is not required.

Expand the Protection

Automatic checks must protect these five categories before merging:

Category	Required outcome
Purchase behavior	Reject regressions in the shared contract and retain the HW1 safety net.
Build, dependencies, and configuration	Reject build/type errors, lockfile inconsistencies, and invalid Compose configuration or service startup failures.
New credential exposures	Reject credentials introduced anywhere in a PR's commits, even if removed before its tip.
Unsafe secret handling	Reject changes that restore insecure credential defaults or disclose configured runtime secrets.
Weakened checks	Prevent passing results obtained by disabling checks, hiding failures, or checking another revision.

Harmless application, fixture, and CI changes must still pass. Any exceptions for inherited exposures or harmless examples must be specific and justified without allowing new exposures. Tool choice and implementation are yours.

Demonstrate Secret Protection

Create an unmerged PR labeled hw2-secret that introduces a synthetic credential exposure, and link the run showing its rejection by a relevant check. Use a disposable value with no access outside the exercise environment.

Update hw2/DESIGN.md in place with your final design and exercise evidence. Complete its Checkpoint B judgment section.

Short Write-ups

Copy the templates below into the named files and replace the bracketed prompts. Use short bullets and aim for roughly 500 words per document. Link directly to code, PRs, and sanitized run evidence; keep logs and copied configuration out of the write-up.

Your thoughts, warts and all

Write these responses yourself. Do not use AI to generate or rewrite them. We want to understand your choices and what you are unsure about. Rough phrasing and sentence fragments are fine; polished prose earns no extra credit.

Template: hw2/DESIGN.md

# HW2 Design

## Checks and enforcement
- [Which checks run, and what does each protect?
  Link to their implementation.]
- [How does CI start from a fresh runner and control merging?]

## Exercise evidence
- hw2-safe: [PR and run links; what changed and what happened.]
- hw2-unsafe: [PR and run links; what changed and which check rejected it.]
- hw2-secret (B only): [PR and run links; what was exposed and which check rejected it.]

## Judgment (B only)
- [What credible alternative did you consider, and why did you choose this approach?]
- [What limitation remains?]

Template: hw2/INCIDENT.md

# HW2 Incident

## Findings and containment
[Repeat this short block for each distinct finding, including harmless findings.]

### [Finding label]
- Location and access: [Where was the exposure, and what access could it grant?
  Identify files, commits, or output locations without including secret values.]
- Decision and action: [What did you change, or why is this finding harmless?]
- Verification: [Link to sanitized evidence supporting your decision.
  Where containment was needed, show old credentials fail, fresh ones work, and current files and output do not expose them.]

## Fresh credentials
- [How should staff supply fresh credentials and run the system?
  Link to relevant configuration; use placeholders for secret values.]

Submission and Deliverables

Submit each checkpoint separately. Staff will find the documents and labeled PRs in your repository.

HW2A: Working CI

Due Sunday, September 13 at 11:59 pm ET.

Last accepted Thursday, September 17 at 11:59 pm ET.

• Working CI and merge restrictions, with the hw2-safe and hw2-unsafe exercises.
• hw2/DESIGN.md using the provided template (roughly 500 words).
• Updated DISCLOSURE.md and the exact checkpoint commit URL on main.

Open HW2A in Canvas→

HW2B: Containment and Guardrails

Due Sunday, September 20 at 11:59 pm ET.

Last accepted Thursday, September 24 at 11:59 pm ET.

• Contained incident and expanded guardrails, with the hw2-secret exercise PR.
• hw2/INCIDENT.md and updated hw2/DESIGN.md using the provided templates (roughly 500 words each).
• Updated DISCLOSURE.md and the exact checkpoint commit URL on main.

Open HW2B in Canvas→

Submit each checkpoint's exact commit URL on main through Canvas after its repository settings and evidence are ready. Include an ## HW2 entry in DISCLOSURE.md describing AI use, or stating none. Keep submitted commits, labeled PRs, and sanitized run evidence available for grading.

Staff snapshot repository settings and evidence separately from the commit. Each checkpoint is graded independently; a resubmission replaces only that checkpoint's snapshot. Resubmit the commit URL after any revision, by its last-accepted time. The course late policy applies.

Evaluation and Bonus

Checkpoint A is worth 70 points. Staff inspect the requirements and confirm that a straightforward build error or purchase regression is detected. Checkpoint B is worth 130 points, including controlled PR changes across the five protection categories. Staff evaluate the submitted revision and settings; changes after seeing grading cases do not count.

Each case requires a working baseline and a relevant, automatic rejection within the time limit, paired with acceptance of a harmless control. Timeouts and unrelated failures earn no detection credit. Staff retry infrastructure failures and replace cases that are inapplicable or do not introduce a new defect in your version.

Checkpoint B offers up to 20 bonus points for fast CI and protection against additional simulated developer mistakes. These mistakes may affect application code, tests, dependencies, configuration, or CI workflows. See the rubric below for scoring; no extra submission is needed.

The assignment is worth 200 points (+ 20 bonus pts).

HW2A — Working CI70 pts

• CI automatically evaluates the correct revision on PR updates and main, with reproducible installation, build/type checks, and application startup.15 pts
• CI runs ./scripts/check with all inherited, HW1, and new tests; failures propagate.10 pts
• Automated checks establish the shared purchase contract through public ingress with fresh, variable data.15 pts
• Normal merging requires successful checks of the current proposed revision; missing or failed evidence blocks merging.10 pts
• Complete CI finishes within five minutes, enforces timeouts, and cancels superseded PR runs.10 pts
• Exercise PRs demonstrate acceptance and rejection; the design record follows the template, and the submitted commit and AI-use disclosure are complete.10 pts

HW2B — Containment and Guardrails130 pts (+ 20 bonus pts)

• Exposed credentials lose access, fresh credentials work without leaking, and INCIDENT.md substantiates containment with sanitized evidence.0–40 pts
• CI correctly classifies harmful changes and harmless controls across the five required categories within the runtime budget.0–50 pts
• Final CI retains reproducibility and merge enforcement, finishes within five minutes, enforces timeouts, and cancels superseded PR runs.15 pts
• The design connects checks to risks and explains a credible alternative, the trade-off, and a remaining limitation.10 pts
• The shared journey, HW1 safety net, interfaces, and development environment remain usable with fresh secrets.10 pts
• The main commit, both checkpoints' exercise evidence, and AI-use disclosure are available; both documents follow the templates.5 pts
• Bonus: Complete final CI meets the speed tier across PR, main, and uncached evaluations, with all required protection working.10 pts
  Scoring levels

  Points	Level	Description
  10	Within two minutes	Every evaluated run type meets the two-minute tier.
  5	Within three minutes	Every evaluated run type meets the three-minute tier.
  0	No speed bonus	CI exceeds three minutes or required protection is incomplete.

• Bonus: Earn one point per correctly classified harmful/control pair across ten additional developer mistakes, with complete final CI within five minutes.0–10 pts