trials

.github/workflows/ci.yml

@@ -0,0 +1,52 @@
+name: ci
+
+on:
+  pull_request:
+    branches: [main]
+
+jobs:
+  tests:
+    name: Tests
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out code
+        uses: actions/checkout@v4
+
+      - name: Set up Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: '18' 
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Run Vitest with coverage
+        run: npm run test -- --coverage
+
+  formatter:
+    name: Style
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out code
+        uses: actions/checkout@v4
+
+      - name: Set up Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: '18' 
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Run Prettier and ESLint fix
+        run: |
+          npm run format:write
+          npm run lint -- --fix
+
+      - name: Check linting
+        run: npm run lint -- --max-warnings=0
+
+
+

.kiro/specs/learn-ci-cd/requirements.md

@@ -0,0 +1,79 @@
+# Requirements Document
+
+## Introduction
+
+This feature focuses on implementing a comprehensive CI/CD (Continuous Integration/Continuous Deployment) pipeline for the current project. The goal is to automate the build, test, and deployment processes to ensure code quality, reduce manual errors, and enable faster, more reliable software delivery. This will include setting up automated testing, code quality checks, security scanning, and deployment automation.
+
+## Requirements
+
+### Requirement 1
+
+**User Story:** As a developer, I want automated testing to run on every code push, so that I can catch bugs early and maintain code quality.
+
+#### Acceptance Criteria
+
+1. WHEN code is pushed to any branch THEN the CI system SHALL automatically trigger a test suite
+2. WHEN tests fail THEN the CI system SHALL prevent merging to main branch
+3. WHEN tests pass THEN the CI system SHALL allow the pull request to be merged
+4. IF the test suite includes unit tests THEN the CI system SHALL run all unit tests and report coverage
+5. WHEN test results are available THEN the system SHALL display results in the pull request interface
+
+### Requirement 2
+
+**User Story:** As a developer, I want code quality checks to run automatically, so that I can maintain consistent code standards across the team.
+
+#### Acceptance Criteria
+
+1. WHEN code is pushed THEN the CI system SHALL run linting checks
+2. WHEN code formatting issues are detected THEN the CI system SHALL report specific violations
+3. IF code quality thresholds are not met THEN the CI system SHALL block the merge
+4. WHEN security vulnerabilities are detected THEN the CI system SHALL flag them for review
+5. WHEN code complexity exceeds defined limits THEN the system SHALL provide warnings
+
+### Requirement 3
+
+**User Story:** As a DevOps engineer, I want automated deployment to staging environments, so that I can test changes in a production-like environment before release.
+
+#### Acceptance Criteria
+
+1. WHEN code is merged to main branch THEN the CD system SHALL automatically deploy to staging environment
+2. WHEN deployment to staging fails THEN the system SHALL notify the development team
+3. IF deployment succeeds THEN the system SHALL run smoke tests against the staging environment
+4. WHEN staging deployment is complete THEN the system SHALL provide a URL for manual testing
+5. IF smoke tests fail THEN the system SHALL rollback the staging deployment
+
+### Requirement 4
+
+**User Story:** As a product manager, I want controlled production deployments, so that I can ensure stable releases with proper approval processes.
+
+#### Acceptance Criteria
+
+1. WHEN staging tests pass THEN the system SHALL create a production deployment candidate
+2. IF manual approval is required THEN the system SHALL wait for authorized approval before production deployment
+3. WHEN production deployment is approved THEN the CD system SHALL deploy to production environment
+4. WHEN production deployment completes THEN the system SHALL run health checks
+5. IF production health checks fail THEN the system SHALL automatically rollback to the previous version
+
+### Requirement 5
+
+**User Story:** As a developer, I want visibility into the CI/CD pipeline status, so that I can quickly identify and resolve issues.
+
+#### Acceptance Criteria
+
+1. WHEN pipeline runs are in progress THEN the system SHALL display real-time status updates
+2. WHEN pipeline failures occur THEN the system SHALL provide detailed error logs
+3. IF build artifacts are generated THEN the system SHALL store them for download
+4. WHEN deployments complete THEN the system SHALL log deployment history with timestamps
+5. WHEN notifications are configured THEN the system SHALL send alerts via email or chat integrations
+
+### Requirement 6
+
+**User Story:** As a security-conscious developer, I want automated security scanning in the pipeline, so that I can identify vulnerabilities before they reach production.
+
+#### Acceptance Criteria
+
+1. WHEN code is pushed THEN the CI system SHALL scan for known security vulnerabilities
+2. WHEN dependencies are updated THEN the system SHALL check for security advisories
+3. IF critical security issues are found THEN the system SHALL block deployment
+4. WHEN security scans complete THEN the system SHALL generate security reports
+5. IF new vulnerabilities are discovered THEN the system SHALL create tickets for remediation

README.md

@@ -1,3 +1,5 @@
+![CI Workflow Status](https://github.com/jojomensah89/learn-cicd-typescript-starter/actions/workflows/ci.yml/badge.svg)
+
 # learn-cicd-typescript-starter (Notely)
 
 This repo contains the typescript starter code for the "Notely" application for the "Learn CICD" course on [Boot.dev](https://boot.dev).

error.md

@@ -0,0 +1,8 @@
+PS C:\Users\EbenezerMensah\Desktop\Test\learn-cicd-typescript-starter> git push
+fatal: The current branch addtests has no upstream branch.
+To push the current branch and set the remote as upstream, use
+
+    git push --set-upstream origin addtests
+
+To have this happen automatically for branches without a tracking
+upstream, see 'push.autoSetupRemote' in 'git help config'.

eslint.config.js

@@ -0,0 +1,19 @@
+import js from "@eslint/js";
+import globals from "globals";
+import tseslint from "typescript-eslint";
+import { defineConfig } from "eslint/config";
+import pluginSecurity from "eslint-plugin-security";
+
+export default defineConfig([
+  {
+    files: ["**/*.{js,mjs,cjs,ts,mts,cts}"],
+    plugins: { js },
+    extends: ["js/recommended"],
+  },
+  {
+    files: ["**/*.{js,mjs,cjs,ts,mts,cts}"],
+    languageOptions: { globals: globals.node },
+  },
+  tseslint.configs.recommended,
+  pluginSecurity.configs.recommended,
+]);

now.md

@@ -0,0 +1,10 @@
+Now that we have setup linting on the project locally, lets get it working on our CI runner.
+
+Assignment
+Add a new step to the same "style" job that currently only checks for formatting issues. Run npm run lint after npm run format:check to make sure that formatting and linting issues are caught by our pipeline.
+
+Commit and push your changes with the unused function to your branch with the open pull request. You should see your CI workflow fail since npm run lint will catch the unused function.
+
+Once you've verified that your CI workflow fails, remove the unused function and commit and push your changes again. Your CI workflow should now pass!
+
+Paste the URL of your GitHub repo into the box and run the GitHub checks.