Capstone Projects

Goal: Create a small C program with a library, unit tests, generated version header, and Makefile.

What this module covers

Make-based C project CMake + Ninja library and test project Multi-branch Git collaboration simulation

CI pipeline with cached build and test artifacts Reproducible release pipeline with version tag

Advanced incident: bisect a regression and recover lost work Final assessment and rubric

Project A — Make-based C application

Goal: Create a small C program with a library, unit tests, generated version header, and Makefile.

Required files:

all, test, clean, and help targets.

Compiler and flags configurable through variables.

Header dependencies modeled.

Generated output stored outside source directories.

Parallel build works.

Clean build and incremental build both pass.

Document supported platform assumptions.

Advanced extension: add static analysis, code coverage, a compiler matrix, and deterministic version metadata.

Every capstone runs on your own machine or a sandbox you control. Use test repositories and placeholder credentials; never push lab experiments to a shared production repository.

make-capstone/
├── Makefile
├── include/
├── src/
├── tests/
└── tools/

Project B — CMake + Ninja library

Build a reusable library and one application.

Use target-scoped include directories and compile options.

Add unit tests through CTest.

Add Debug and Release configurations.

Provide CMakePresets.json.

Add installation rules.

Add a documented cross-compilation profile or toolchain file.

Ensure configuration errors are clear.

Advanced extension: export an installable package, validate ABI/API expectations, and measure incremental-build performance.

Project C — Git collaboration simulation

Roles: developer A, developer B, reviewer, release manager.

Initialize and push a shared repository.

Create two feature branches.

Make overlapping edits to produce a conflict.

Resolve conflict and run tests.

Use rebase or merge according to a written policy.

Cherry-pick a critical fix to a release branch.

Tag a release.

Recover an intentionally misplaced local commit using reflog.

Submit a short postmortem explaining what was learned.

Project D — CI build pipeline

Trigger on pull requests and main-branch changes.

Pin toolchain versions.

Restore dependencies from lockfiles.

Run format/lint/static checks.

Build and run tests.

Upload test reports and build artifacts.

Use caching with a correct cache key.

Restrict release secrets to trusted jobs.

Produce a versioned release artifact and checksum.

Project E — Reproducible release

Build from a clean checkout at a specific commit/tag.

Record toolchain and dependency versions.

Generate an SBOM.

Calculate artifact digest.

Sign the release artifact or produce an appropriate attestation.

Verify the signature/digest in a separate step.

Document how to reproduce and verify the release.

Ensure the release process does not depend on untracked local files.

Project F — Advanced incident response

Scenario: a release build fails only in CI; the latest incremental build passes locally; a recent dependency update may be involved.

A minimal reproduction.

A dependency/build graph analysis.

A Git bisect or equivalent commit-range investigation.

Corrective patch and regression test.

A documented preventive control.

Assessment Bank

What is the difference between a build system and version control?

What does git add do?

Why should generated files usually be separated from source files?

What is a build target?

What does a Git commit represent?

Why is .gitignore useful?

What is a compiler toolchain?

What is a dependency graph?

Why might an incremental build use a stale object file?

Explain $@, $<, and $^ in GNU Make.

What does cmake -S . -B build do?

Explain the difference between a merge and a rebase.

What is the role of a lockfile?

What is the difference between git revert and git reset?

Why should tests run after conflict resolution?

What is a CI artifact?

Why are undeclared build inputs dangerous for remote caching?

Explain hermeticity and reproducibility.

How can a missing generated-header dependency cause a parallel-build race?

What is the difference between remote caching and remote execution?

When is rewriting Git history unsafe?

How can git bisect identify a regression?

What metadata should accompany a release artifact?

Why is a checksum not equivalent to a digital signature?

How should CI handle secrets for untrusted pull requests?

What are the trade-offs between monorepo and multirepo?

Why can the same source code produce different binaries?

How can toolchain version changes invalidate a build cache?

What problems do submodules solve, and what workflow costs do they add?

How would you investigate a clean-build-success/incremental-build-failure issue?

Practical grading rubric Build graph correctness Dependencies are complete; incremental builds are correct

Clear targets, variables, variants, and toolchain setup Tests run locally and in CI with useful reports

Clear commits, branches, diffs, and repository hygiene Conflict resolution and review process are documented

CI runs reliably and artifacts are retained Toolchain/dependencies are pinned and inputs documented

Secrets, permissions, signatures, and dependencies handled responsibly

A new contributor can reproduce the workflow Root cause and regression prevention are demonstrated

Quiz

? Project F: a release build fails only in CI. What is a good first step?
+ Reproduce it with the same pinned toolchain and a clean checkout. :: Environment drift is the usual suspect.
- Retry until it passes. :: Retries hide the cause.
- Delete the CI cache permanently. :: Might help once; does not explain anything.
- Disable the failing step. :: That ships an untested artifact.

? Which evidence should a reproducible-release capstone include? (select all that apply)
+ Toolchain and dependency versions :: Needed to rebuild.
+ The artifact digest :: To compare rebuilds.
+ A signature or attestation verified in a separate step :: Proves the verification works.
- The local machine's home-directory path :: That is exactly what must not leak in.

? In the grading rubric, which two areas carry the highest weight (15% each)?
+ Build graph correctness and automation :: Each is weighted 15%.
- Documentation and troubleshooting :: 5% each.
- Testing and Git fundamentals :: 10% each.
- Security and reproducibility :: 10% each.