Capstone project for GitHub for Teams

Put partner-api on a team workflow before the festival rush

Mangrove Market's partner-api is the service the Partner app's 1,800 corner shops order stock through, and before the festival rush the team wants it on a proper workflow. Using a small Node project of your own (a discount or VAT module with a few tests is enough), set up a GitHub repository the way this course teaches: a protected main, a PR template and code owners, a bug report form and a Project, and a CI workflow that blocks bad merges. Then run one full cycle: an issue, a feature PR that closes it, a v1.0.0 release, a bug fixed on main and shipped as a v1.0.1 hotfix through a release branch, and a short investigation that uses git bisect run to find a rounding regression you plant on purpose. Write it up so Imran, the Partner app's product manager, could follow every step without reading the code.

What you hand in

A repository link (a public repository is fine, and makes rulesets free) with a README, a PR template, CODEOWNERS, an issue form and the ruleset exported as ruleset.json
A CI workflow in .github/workflows/ci.yml that passes actionlint, is required by the ruleset, and has one red and one green run you can point to
One issue and the squash-merged PR that closed it, with a test plan in the description and at least one review comment or suggestion
Tags v1.0.0 and v1.0.1 with GitHub Releases, where v1.0.1 is a fix merged to main first and cherry-picked onto a release branch
A one-page investigation note in the repository: the planted regression, the check script, the bisect output and the PR and issue trail

Check your work

Tick each item when your project meets it. Be strict: this is the rubric the reviewer uses.

Nobody can push or force-push to main; a merge needs one approval and the required checks, and the check names match the CI job names exactly
The workflow sets least-privilege permissions and timeouts, caches npm by the lockfile, tests on two Node versions, and actionlint prints nothing
The feature PR is small, its closing keyword really closed the issue, and its description has a why, a test plan and a risk note
The hotfix reached main first and was cherry-picked with -x; git log v1.0.0..v1.0.1 shows only the fix and the version bump
The issue form asks for version, where, steps, expected versus actual and impact, and the Project has table, board and roadmap views kept current by workflows
The investigation names the first bad commit, shows a check script with clear exit codes kept outside the repository, and links the PR and issue that explain the change
The README and release notes make sense to a PM or store manager who never opens the code

0 of 7 checked

Model answer

The model answer opens once your capstone passes the review, so you can compare your work with an outline of a strong submission.

Hand in your capstone

Your links are checked automatically, then the work is scored against the rubric above, item by item, with comments. A pass counts toward the course certificate and shows on your profile.

Loading…