CI CD Wiki

CI/CD Pipeline Phase 1 Status

1. Linting and code style enforcement (Using super-linter)

   • Triggers on all pushes, and pull requests to main
   • Does syntax and style checking for HTML, CSS, JS
   • User must manually make any fixes that super-linter catches
   • STATUS: Done

2. Code quality (Using Code Inspector)

   • ISSUE: CAN’T BE USED ON PRIVATE REPO WITHOUT UPGRADING
   • Already tested on Bryant’s personal public repo
   • Triggers on all pushes except on the docs branch, and pull requests to main.
   • Scans through code to determine code quality with metrics such as defect ratios, # of long/complex functions, etc.
   • STATUS: Not yet implemented due to paywall, but functionality already verified on a separate, public repo. Looking into other free code quality tools, changing repo to public, or asking for a free education upgrade.

3. Code quality via human review

   • Triggers when trying to merge with main
   • Coder requests a PR and tags their request as PR: Needs Review.
   • Another individual in the group--the reviewer--will review the request
   • If the reviewer sees no issues, they can approve the request by changing the label to PR: Ready to Merge.
   • If they see bugs/issues they can add comments overall or line-by-line and change the label to PR: Reviewed with Comments.
   • The coder will receive an email notifying them of the change in status of their PR
   • If it was approved, they can change the label to PR: Ready to Merge and initiate the merge themselves
   • If comments were added, they need to modify the code and start the PR over
   • STATUS: Done

4. Unit tests (Using Jest)

   • Triggers on all pushes except on the docs branch, and pull requests to main
   • User must first write unit tests with the format nameGoesHere.test.js.
   • Finds and runs all Javascript unit tests and reports back pass/fail and code coverage
   • STATUS: Done

5. Documentation (Using JSDocs)

   • Triggers on pull requests to main to minimize # of commits, because a commit is needed in the pipeline to save the generated documentation.
   • User needs to manually comment Javascript code according to JSDocs requirements
   • Scans through Javascript files, automatically generating clean documentation for commented functions and classes that is easily accessible and understandable by the team
   • STATUS: Done

Demo Video

GitHub Pipeline Walkthrough

1. Features are divided into issues in the Issue Tab of the Github. Each Issue has a specified title, description, images (if necessary), and label for the importance (e.g. "Important Feature"). Each Issue is assigned to a team pair and labeled with a story point count (e.g. Story Point 3 for moderately difficult to implement).

2. When developing, the member/pair should start by creating a new branch off of master, and naming it with a general description of what that branch will be used for (e.g. timer-fixes if they were addressing a bug in the timer).

3. All commits should be made to that branch. When they are done coding, they should open a Pull Request (PR). The PR description should contain the phrase “Resolves #XX.” where the XX is replaced with the issue number that corresponds with the task that they’ve worked on. The member/pair should assign the issue to themselves, label the PR as needing review, and request review from at least one other member/pair.

4. The requested reviewing party should review the code changed in the PR, and ensure that it addresses the issue it is connected to. If the reviewing party deems the PR to be good to go, they should both label the PR as approved, and approve it through GitHub. If they don’t approve the changes, they should mark the PR as reviewed with comments, and comment their concerns using either GitHub’s reviewal option or by commenting on the PR.

5. After a PR is reviewed, the owner(s) of the PR should merge it into the master branch.