DEV Community: Kyle Y. Parsotan

End-to-End (E2E) testing pipeline

Kyle Y. Parsotan — Sat, 23 May 2026 21:02:29 +0000

Let’s build a real End-to-End (E2E) testing pipeline like teams use in production using Playwright (recommended) and GitHub Actions.

I’ll show you:

🧪 What E2E testing is
⚙️ Playwright setup (React app example)
🚀 GitHub Actions CI pipeline
📸 Test reports + screenshots on failure
🧠 Production best practices

🧠 0. What is E2E testing?

E2E (End-to-End) testing means:

“Test your app like a real user would use it.”

Instead of testing functions, you test:

Clicking buttons
Filling forms
Navigation
API + UI together

⚔️ Playwright vs Cypress (quick decision)

Feature	Playwright	Cypress
Speed	🚀 Faster	متوسط
Multi-browser	✅ Yes	Limited
CI friendly	⭐ Excellent	Good
Modern apps	⭐ Best choice	Good

👉 We’ll use Playwright (industry standard in 2025)

🧱 1. Install Playwright (React project)

```bash id="pw1"
npm init playwright@latest




When prompted choose:

* JavaScript or TypeScript (TS recommended)
* Tests folder: `tests`
* GitHub Actions: YES

---

# 📁 2. Project structure



```plaintext id="pw2"
my-app/
 ├── tests/
 │    ├── example.spec.ts
 ├── playwright.config.ts
 ├── package.json

🧪 3. First E2E test (real user flow)

Example: Login flow test

```ts id="test1"
import { test, expect } from '@playwright/test';

test('user can login successfully', async ({ page }) => {
await page.goto('http://localhost:3000/login');

await page.fill('input[name="email"]', 'test@example.com');
await page.fill('input[name="password"]', 'password123');

await page.click('button[type="submit"]');

await expect(page).toHaveURL(/dashboard/);
});




---

# 🚀 4. Run tests locally



```bash id="run1"
npx playwright test

Open UI mode (very useful):

```bash id="ui1"
npx playwright test --ui




---

# 📸 5. Auto screenshots on failure

Playwright automatically captures:

* screenshots
* videos
* traces

Enable in config:



```ts id="cfg1"
use: {
  screenshot: 'only-on-failure',
  video: 'retain-on-failure',
  trace: 'on-first-retry'
}

⚙️ 6. GitHub Actions CI pipeline (E2E automation)

📁 `.github/workflows/e2e.yml`

```yaml id="ci1"
name: E2E Tests (Playwright)

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
test:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Setup Node
    uses: actions/setup-node@v4
    with:
      node-version: 20

  - name: Install dependencies
    run: npm install

  - name: Install Playwright browsers
    run: npx playwright install --with-deps

  - name: Run Playwright tests
    run: npx playwright test




---

# 🧠 7. What happens in CI



```plaintext id="flow1"
Push code
   ↓
GitHub Actions starts
   ↓
Install dependencies
   ↓
Install browsers (Chromium, Firefox, WebKit)
   ↓
Run E2E tests
   ↓
Pass → allow merge
Fail → block PR + show report

📊 8. Add HTML test report

Enable report:

```ts id="rep1"
reporter: [['html'], ['list']]




Then in CI:



```yaml id="rep2"
- name: Upload Playwright report
  uses: actions/upload-artifact@v4
  if: always()
  with:
    name: playwright-report
    path: playwright-report

🌐 9. Test real deployed app (PRO setup)

Instead of localhost:

```ts id="prod1"
await page.goto('https://your-app.vercel.app/login');




👉 This turns it into **true production E2E testing**

---

# 🧪 10. Advanced real-world test examples

---

## 🟢 UI navigation test



```ts id="nav1"
test('navigate to dashboard', async ({ page }) => {
  await page.goto('/');
  await page.click('text=Dashboard');
  await expect(page).toHaveURL(/dashboard/);
});

🟡 Form validation test

```ts id="form1"
test('shows error for empty email', async ({ page }) => {
await page.goto('/login');
await page.click('button[type="submit"]');

await expect(page.locator('.error')).toContainText('Email is required');
});




---

## 🔵 API + UI combined test



```ts id="api1"
test('data loads after API call', async ({ page }) => {
  await page.goto('/dashboard');

  await expect(page.locator('.loading')).toBeHidden();
  await expect(page.locator('.chart')).toBeVisible();
});

🔐 11. CI best practices (IMPORTANT)

✔ Run E2E after build

```yaml id="bp1"

run: npm run build
run: npm start & ```

✔ Use staging environment

staging.example.com
production.example.com

✔ Retry flaky tests

```ts id="rt1"
retries: 2




---

# ⚠️ 12. Common mistakes

### ❌ Testing implementation instead of behavior

Bad:



```ts id="bad1"
expect(component.state).toBe(true)

Good:

```ts id="good1"
expect(page).toHaveText('Welcome')




---

### ❌ No stable selectors

Use:



```html id="sel1"
data-testid="login-button"

Then:

```ts id="sel2"
page.getByTestId('login-button')




---

### ❌ Running E2E without CI

Always run in GitHub Actions

---

# 🧠 Final architecture



```plaintext id="final1"
Push / PR
   ↓
CI (unit tests)
   ↓
E2E tests (Playwright)
   ↓
Build app
   ↓
Deploy to staging/production
   ↓
Report + screenshots stored in GitHub

🚀 What you just built

You now have:

🧪 Real user simulation testing
🚀 CI/CD integrated E2E pipeline
📸 Failure screenshots + videos
🌍 Production-ready test system
🔒 Safe deployment gating system

Auto versioning + changelog generation using Github Action

Kyle Y. Parsotan — Sat, 23 May 2026 21:01:19 +0000

Auto versioning + changelog generation is a very real production pattern used in open-source and SaaS teams to avoid messy release notes and manual tagging.

We’ll build a clean system using:

🧠 Conventional commits (rules for commit messages)
🤖 Semantic versioning automation
📜 Auto-generated CHANGELOG
🚀 GitHub Actions workflow

🧠 0. What we’re building

```plaintext id="flow0"
commit → push → GitHub Action
↓
analyze commits
↓
bump version (patch/minor/major)
↓
generate changelog
↓
create git tag
↓
create GitHub release




---

# 📦 1. Install required tool (standard approach)

We’ll use:

👉 **semantic-release** (industry standard)



```bash id="inst1"
npm install --save-dev semantic-release @semantic-release/changelog @semantic-release/git @semantic-release/github

🧠 2. Use Conventional Commits (VERY important)

Your commits MUST follow this format:

✅ Examples

Feature (minor version bump)

```bash id="c1"
feat: add user login system




### Fix (patch version bump)



```bash id="c2"
fix: resolve navbar bug on mobile

Breaking change (major version bump)

```bash id="c3"
feat!: redesign API structure




or



```bash id="c4"
BREAKING CHANGE: remove old auth system

⚙️ 3. Create semantic-release config

📁 `.releaserc.json`

```json id="r1"
{
"branches": ["main"],
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/changelog",
"@semantic-release/github",
[
"@semantic-release/git",
{
"assets": ["package.json", "CHANGELOG.md"],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
}
]
]
}




---

# 📜 4. Create CHANGELOG file



```bash id="ch1"
touch CHANGELOG.md

Start empty:

```md id="ch2"

Changelog

All notable changes will be documented here.




---

# 🚀 5. GitHub Actions workflow (AUTO VERSION + CHANGELOG)

## 📁 `.github/workflows/release.yml`



```yaml id="w1"
name: Auto Version & Changelog

on:
  push:
    branches:
      - main

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm install

      - name: Run semantic release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

🧠 6. What this does automatically

When you push to main:

It will:

Analyze commits
Decide version bump:
- fix → 1.0.1
- feat → 1.1.0
- breaking → 2.0.0
Generate changelog
Create Git tag
Create GitHub Release
Update CHANGELOG.md

📜 7. Example auto-generated changelog

```md id="log1"

1.2.0 (2026-05-23)

Features

add user authentication system
add dashboard analytics

Bug Fixes

fix navbar alignment on mobile
fix API timeout issue ```

🏷️ 8. Example GitHub releases

GitHub will automatically create:

```plaintext id="rel1"
v1.2.0 - Production Release

Features:

user auth system
analytics dashboard

Fixes:

mobile navbar bug ```

🔐 9. GitHub Secrets needed

Make sure this exists:

```plaintext id="sec1"
GITHUB_TOKEN (auto provided by GitHub Actions)




No extra setup required.

---

# 🧪 10. Real workflow in action

### Developer flow:



```plaintext id="flow1"
git commit -m "feat: add dashboard UI"
git push origin main

GitHub automatically:

Detects commit type (feat)
Bumps version → minor update
Updates CHANGELOG.md
Creates git tag (v1.3.0)
Publishes GitHub release

🔥 11. Pro upgrades (used in companies)

🟢 Auto publish npm package

```yaml id="npm1"

run: npm publish ```

🟡 Slack release notification

```yaml id="slack1"

name: Notify Slack run: curl -X POST $SLACK_WEBHOOK ```

🔵 Multi-branch releases

```json id="branch1"
"branches": ["main", "next"]




---

## 🟣 Changelog formatting customization

You can group commits like:

* Features
* Fixes
* Performance
* Breaking changes

---

# ⚠️ 12. Common mistakes

### ❌ Not using conventional commits

→ versioning won’t work properly

### ❌ Pushing messy commit messages



```bash id="bad1"
fix stuff
update

❌ Forgetting fetch-depth: 0

→ release history breaks

🧠 Final architecture

```plaintext id="final1"
Commit (feat/fix/breaking)
↓
GitHub Action triggers
↓
semantic-release analyzes commits
↓
bumps version automatically
↓
updates CHANGELOG.md
↓
creates git tag + GitHub release




---

# 🚀 What you just built (REAL DEVOPS LEVEL)

You now have:

* 🤖 Automated versioning
* 📜 Auto changelog generation
* 🏷️ Git tags + GitHub releases
* 🚀 CI/CD-ready release pipeline

Auto PR + Auto Deploy workflow using CI/CD Pipline

Kyle Y. Parsotan — Sat, 23 May 2026 21:00:37 +0000

Here’s a real production-style Auto PR + Auto Deploy workflow using GitHub Actions. This is the kind of setup used in teams to keep main stable and deployments automatic.

We’ll build it in 3 parts:

🤖 Auto-create Pull Requests (from feature → main)
🧪 Run CI checks on PRs
🚀 Auto-deploy when merged to main

🧠 0. What we are building

```plaintext id="flow1"
feature branch push
↓
Auto PR created (GitHub Action)
↓
CI runs (tests, lint)
↓
PR merged to main
↓
Auto deploy to production




---

# 🤖 1. Auto Create Pull Request Workflow

This automatically creates a PR when you push a feature branch.

## 📁 `.github/workflows/auto-pr.yml`



```yaml id="pr1"
name: Auto Create Pull Request

on:
  push:
    branches-ignore:
      - main

jobs:
  create-pr:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Create Pull Request
        uses: repo-sync/pull-request@v2
        with:
          destination_branch: main
          github_token: ${{ secrets.GITHUB_TOKEN }}
          pr_title: "Auto PR: ${{ github.ref_name }}"
          pr_body: |
            ## 🤖 Auto-generated PR

            Branch: `${{ github.ref_name }}`
            Please review changes before merging.

🧠 What this does:

Push to feature/login
GitHub Actions triggers
Automatically opens PR → feature/login → main

🧪 2. CI Pipeline (runs on PRs)

This ensures only clean code gets merged.

📁 `.github/workflows/ci.yml`

```yaml id="ci1"
name: CI Checks

on:
pull_request:
branches: [ main ]

jobs:
test:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Setup Node
    uses: actions/setup-node@v4
    with:
      node-version: 20

  - name: Install dependencies
    run: npm install

  - name: Run lint
    run: npm run lint

  - name: Run tests
    run: npm test




---

## 🧠 What this does:

Before merge:

* Runs lint checks
* Runs tests
* Blocks bad code from merging

---

# 🚀 3. Auto Deploy on Merge to Main

This deploys your app when PR is merged.

## 📁 `.github/workflows/deploy.yml`

### Example: Deploy React + Node (Vercel + Render)



```yaml id="deploy1"
name: Auto Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy-frontend:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install frontend
        working-directory: client
        run: npm install

      - name: Build frontend
        working-directory: client
        run: npm run build

      - name: Deploy to Vercel
        run: npx vercel --prod --token=${{ secrets.VERCEL_TOKEN }}

  deploy-backend:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install backend
        working-directory: server
        run: npm install

      - name: Deploy backend (Render webhook)
        run: curl -X POST ${{ secrets.RENDER_DEPLOY_HOOK }}

🔐 4. GitHub Secrets Setup

Go to:

👉 Repo → Settings → Secrets → Actions

Add:

```plaintext id="sec1"
VERCEL_TOKEN=your_vercel_token
RENDER_DEPLOY_HOOK=https://api.render.com/deploy/xxx




---

# 🧭 5. Full Workflow in action

## Developer flow:



```plaintext id="flow2"
git checkout -b feature-login
git push origin feature-login

Then GitHub automatically:

🤖 Creates Pull Request
🧪 Runs CI checks
👀 Waits for review (optional)
🔀 Merge to main
🚀 Auto deploys frontend + backend

🔥 6. Upgrade (what real companies add)

🟢 Add approval rule (recommended)

In GitHub:

Require 1–2 reviewers
Require CI to pass before merge

🟡 Add branch protection

Settings → Branches → main

Enable:

Require PR before merging
Require status checks
Block direct pushes

🔵 Add notifications (Slack/Discord)

```yaml id="notif1"

name: Notify Slack run: | curl -X POST -H 'Content-type: application/json' \ --data '{"text":"New deployment to production 🚀"}' \ ${{ secrets.SLACK_WEBHOOK }} ```

🟣 Add version tagging

```bash id="tag1"
git tag v1.0.0
git push origin v1.0.0




---

# ⚠️ Common mistakes

### ❌ Auto-deploy without tests

→ leads to broken production

### ❌ No branch protection

→ anyone can push to main

### ❌ Missing secrets

→ deployment fails silently

---

# 🧠 Final Architecture (Pro level)



```plaintext id="final1"
Feature Branch
   ↓
Auto PR Created
   ↓
CI (tests + lint)
   ↓
Review + Approval
   ↓
Merge to main
   ↓
CD Pipeline
   ↓
Frontend deploy (Vercel)
Backend deploy (Render/AWS)
   ↓
Slack/Discord notification

CI/CD Pipline

Kyle Y. Parsotan — Sat, 23 May 2026 20:58:51 +0000

Here’s a real-world CI/CD pipeline setup for a React frontend + Node.js backend + deployment using GitHub Actions**. This is very close to what startups actually use.

🚀 Full CI/CD Pipeline (React + Node + GitHub Actions)

🧱 Architecture

Frontend (React)  →  Backend (Node/Express)  →  Deployment (Vercel / Render / AWS)
        ↑                    ↑
     CI tests            CI tests
        ↓                    ↓
   GitHub Actions runs everything automatically

📁 Example Project Structure

```plaintext id="7p0k1m"
my-app/
├── client/ # React app
├── server/ # Node.js API
├── .github/
│ └── workflows/
│ └── ci-cd.yml
├── package.json




---

# ⚙️ CI Pipeline (Testing both React + Node)

This workflow runs on every push and pull request.



```yaml id="ci1234"
name: Full CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test-frontend:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install frontend dependencies
        working-directory: client
        run: npm install

      - name: Run frontend tests
        working-directory: client
        run: npm test

  test-backend:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install backend dependencies
        working-directory: server
        run: npm install

      - name: Run backend tests
        working-directory: server
        run: npm test

🚀 CD Pipeline (Deployment)

Now we deploy when everything passes.

Example: Deploy backend + frontend

```yaml id="cd5678"
name: Deploy Pipeline

on:
push:
branches: [ main ]

jobs:
deploy-backend:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Install backend
    working-directory: server
    run: npm install

  - name: Build backend
    working-directory: server
    run: npm run build

  - name: Deploy backend to Render
    run: |
      curl -X POST ${{ secrets.RENDER_DEPLOY_HOOK }}

deploy-frontend:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Install frontend
    working-directory: client
    run: npm install

  - name: Build React app
    working-directory: client
    run: npm run build

  - name: Deploy to Vercel
    run: |
      npx vercel --prod --token=${{ secrets.VERCEL_TOKEN }}




---

# 🔐 GitHub Secrets (IMPORTANT)

You must store sensitive keys in:

👉 GitHub Repo → Settings → Secrets and Variables

Example secrets:



```plaintext id="sec123"
VERCEL_TOKEN=your-vercel-token
RENDER_DEPLOY_HOOK=https://api.render.com/deploy/xxx

🧪 What happens when you push code?

Example flow:

```plaintext id="flow123"

You push code to GitHub
GitHub Actions starts CI
Runs:
- React tests
- Node API tests
If ALL pass:
- Builds frontend
- Builds backend
CD triggers:
- Deploy backend (Render/AWS)
- Deploy frontend (Vercel) ```

🧠 What real companies add on top

🔥 1. Linting

```yaml id="lint1"
run: npm run lint




---

### 🔥 Code formatting check



```yaml id="fmt1"
run: npm run format:check

🔥 Caching (faster builds)

```yaml id="cache1"
uses: actions/cache@v4




---

### 🔥 Database migrations (backend)



```yaml id="db1"
run: npm run migrate

🔥 Parallel jobs

Frontend + backend run at the same time (already shown above)

🚀 Real-world deployment options

Frontend

Vercel (most common)
Netlify
AWS S3 + CloudFront

Backend

Render
Railway
AWS EC2 / ECS
DigitalOcean

⚠️ Common mistakes in CI/CD

❌ No environment variables

→ app works locally but fails in CI

❌ Missing build step

→ deployment breaks

❌ Not separating frontend/backend

→ messy pipeline

❌ No test stage

→ broken code gets deployed

🧭 Production-grade CI/CD flow

```plaintext id="prod1"
Push → CI Tests → Build → Approval (optional) → Deploy → Monitor




---

# 💡 Final Summary

A real CI/CD pipeline:

* Tests frontend + backend automatically
* Builds apps only if tests pass
* Deploys without manual work
* Prevents broken code from reaching users

Github Action Core part of Automation

Kyle Y. Parsotan — Sat, 23 May 2026 20:57:14 +0000

GitHub Actions is GitHub’s built-in system for automating tasks in your repo—like testing code, building apps, and deploying projects.

It’s a core part of CI/CD (Continuous Integration / Continuous Deployment) used in real software companies.

🚀 GitHub Actions (CI/CD Automation Basics)

🧠 What is CI/CD?

CI = Continuous Integration

Automatically tests your code every time you push changes.

CD = Continuous Deployment

Automatically deploys your app when code is ready.

👉 In simple terms:

Push code → GitHub runs checks → If everything passes → deploy or approve

⚙️ What are GitHub Actions?

GitHub Actions lets you create workflows that run automatically when something happens in your repo.

Examples:

Push code → run tests
Open Pull Request → check code quality
Merge to main → deploy website
Schedule task → run every day

🧩 Key Concepts

🟡 Workflow

A full automation process (YAML file)

Example:

“Run tests and deploy app”

🟢 Event

What triggers the workflow

Examples:

push
pull_request
schedule

🔵 Job

A group of steps that run on a machine

🟣 Step

Individual command or action

🖥️ Runner

The machine that executes your workflow (Linux, Windows, Mac)

📁 3. Where GitHub Actions live

They are stored in:

```plaintext id="g7m3tq"
.github/workflows/




Example file:



```plaintext id="2kqz91"
.github/workflows/nodejs.yml

🛠️ First Simple GitHub Action (Hello World CI)

Create this file:

```yaml id="7xkq1p"
name: Basic CI

on:
push:
branches: [ main ]

jobs:
build:
runs-on: ubuntu-latest

steps:
  - name: Checkout code
    uses: actions/checkout@v4

  - name: Say Hello
    run: echo "Hello, GitHub Actions!"




### What happens?

Every time you push to `main`, GitHub prints:



```plaintext
Hello, GitHub Actions!

🧪 Real CI Example (Node.js project)

This is what real developers use:

```yaml id="k3n8dj"
name: Node.js CI

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
test:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Setup Node
    uses: actions/setup-node@v4
    with:
      node-version: 20

  - name: Install dependencies
    run: npm install

  - name: Run tests
    run: npm test




---

# 🚀 Simple CD (Deployment Example)

Example: Deploy to server or hosting after push



```yaml id="8v2q9m"
name: Deploy App

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm install

      - name: Build project
        run: npm run build

      - name: Deploy
        run: echo "Deploying app..."

(Real deployments would connect to Vercel, AWS, etc.)

🔥 Common GitHub Actions Use Cases

🧪 Testing

Run unit tests
Run lint checks

🏗️ Build automation

Compile code
Build React/Next.js apps

🚀 Deployment

Deploy to Vercel, AWS, Firebase, Netlify

🔐 Security checks

Scan dependencies
Check vulnerabilities

🤖 Automation

Auto-label PRs
Auto-comment on issues
Run scheduled jobs

🧠 GitHub Actions in real life

A real workflow looks like:

Developer pushes code
GitHub runs tests automatically
If tests pass → PR allowed
Merge to main
App is automatically deployed

👉 This removes manual work completely.

⚠️ Common beginner mistakes

❌ Wrong YAML spacing

YAML is sensitive—indentation matters.

❌ Missing checkout step

You must include:

```yaml id="f1p9sl"
uses: actions/checkout@v4




### ❌ Not specifying trigger (on:)

Without it, workflow won’t run.

### ❌ Overcomplicating workflows

Start simple → add complexity later.

---

# 🧭 Basic GitHub Actions structure



```plaintext id="c7m2kf"
on: (trigger event)

jobs:
  job-name:
    runs-on: machine-type
    steps:
      - action
      - run command

💡 Final Summary

GitHub Actions = automation for your GitHub repo

You use it to:

Test code automatically
Build projects
Deploy apps
Save time
Prevent bugs

Here are the most common Git mistakes beginners make and exactly how to fix them. Think of this as your “Git emergency guide.”

Kyle Y. Parsotan — Sat, 23 May 2026 20:25:25 +0000

🚨 Committed to the wrong branch

❌ Mistake

You meant to work on feature-login, but accidentally committed to main.

🔧 Fix

Check where you are:

git branch

Move commit to a new branch:

git branch feature-login
git reset --soft HEAD~1
git checkout feature-login

Now your commit is safely on the correct branch.

🚨 Forgot to add files before committing

❌ Mistake

You committed but changes are missing.

🔧 Fix

Add missing files and amend commit:

git add .
git commit --amend

🚨 Wrong commit message

❌ Mistake

git commit -m "fix"

🔧 Fix

git commit --amend -m "Fix login validation error"

If already pushed:

git push --force

🚨 Pushed to GitHub accidentally

❌ Mistake

You pushed messy or wrong commits.

🔧 Fix (safe undo)

Reset locally:

git reset --soft HEAD~1

Then force update remote:

git push --force

⚠️ Only do this if you're sure nobody else pulled the code.

🚨 Merge conflict confusion

❌ Mistake

Git shows:

CONFLICT (content): Merge conflict in file.js

🔧 Fix

Open the file
Look for:

<<<<<<< HEAD
your code
=======
incoming code
>>>>>>> branch

Manually choose correct code
Then:

git add .
git commit

🚨 Accidentally deleted files

❌ Mistake

You removed a file and need it back.

🔧 Fix

Restore file:

git checkout -- filename

Or newer Git:

git restore filename

🚨 Lost commits (panic moment 😱)

❌ Mistake

You reset or switched branches and “lost” work.

🔧 Fix

Recover using reflog:

git reflog

Find commit ID, then:

git checkout <commit-id>

Or restore branch:

git reset --hard <commit-id>

🚨 Wrong branch pushed to GitHub

❌ Mistake

You pushed feature work to main.

🔧 Fix

Create correct branch from commit:

git checkout -b feature-branch

Then reset main:

git checkout main
git reset --hard origin/main

🚨 Forgot to pull before pushing

❌ Mistake

rejected - non-fast-forward

🔧 Fix

Pull first:

git pull origin main

Then push again:

git push

If conflicts happen, fix them then commit.

🚨 Messy commit history

❌ Mistake

Too many “fix fix fix” commits.

🔧 Fix (clean history)

Use interactive rebase:

git rebase -i HEAD~3

Then:

squash commits
edit messages
clean history

🚨 11. Stuck in Vim editor (VERY common 😭)

❌ Mistake

Git opens strange screen and you can’t exit.

🔧 Fix

Exit Vim:

ESC → :wq → Enter   (save & exit)

Or:

ESC → :q! → Enter   (exit without saving)

🚨 Accidentally staged wrong files

❌ Mistake

You added too many files:

git add .

🔧 Fix

Unstage everything:

git reset

Or specific file:

git restore --staged filename

🧠 Quick “panic commands” cheat sheet

If something goes wrong, try:

git status
git log --oneline
git reflog
git reset --hard HEAD
git restore .

💡 Final Advice

Most Git mistakes are not permanent.

Rule of thumb:

Git almost always has a way back if you use reflog or commits properly.

Here’s a structured Git command guide from basic advanced, so you can grow step-by-step instead of memorizing random commands.

Kyle Y. Parsotan — Sat, 23 May 2026 20:22:33 +0000

🟢 Beginner Git Commands (Must Know First)

These are the commands you’ll use every day.

⚙️ Setup (one-time)

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Check config:

git config --list

📁 Start a project

Create new repo:

git init

Clone existing repo:

git clone https://github.com/user/repo.git

📌 Basic workflow (core Git loop)

Check status:

git status

Add files:

git add .

Commit changes:

git commit -m "your message"

Send to GitHub:

git push

Get updates:

git pull

🟡 Intermediate Git Commands (Real Development Work)

This is where Git starts becoming powerful.

🌿 Branching (VERY important)

Create branch:

git branch feature-branch

Switch branch:

git checkout feature-branch

Create + switch at once:

git checkout -b feature-branch

List branches:

git branch

Delete branch:

git branch -d feature-branch

🔀 Merging

Switch to main:

git checkout main

Merge branch:

git merge feature-branch

🌐 Remote repositories

Add remote:

git remote add origin https://github.com/user/repo.git

Check remotes:

git remote -v

Push branch:

git push origin main

Push new branch:

git push -u origin feature-branch

🔄 Sync with remote

Fetch changes (no merge):

git fetch

Pull changes (fetch + merge):

git pull

🔵 Advanced Git Commands (Professional Level)

These are used in real teams, open source, and production systems.

⏪ Undo changes (VERY important)

Undo last commit (keep changes):

git reset --soft HEAD~1

Undo last commit (remove changes):

git reset --hard HEAD~1

Undo file changes:

git checkout -- filename

Restore file from commit:

git restore filename

🧠 Stashing (save work temporarily)

Save changes without committing:

git stash

List stashes:

git stash list

Apply stash:

git stash apply

Remove stash:

git stash drop

🔍 Inspect history

View commits:

git log

Compact log:

git log --oneline

Graph view:

git log --graph --oneline --all

See file changes:

git diff

🧩 Rewriting history (advanced)

Edit last commit message:

git commit --amend

Squash commits (interactive):

git rebase -i HEAD~3

🚨 Conflict handling

When merge conflict happens:

git status

Fix files manually → then:

git add .
git commit

🌍 Advanced remote control

Change remote URL:

git remote set-url origin NEW_URL

Remove remote:

git remote remove origin

🧪 Cherry-picking (select commits)

Apply specific commit:

git cherry-pick commit-id

🧭 Rebase (clean history)

Rebase branch:

git rebase main

Continue after conflict:

git rebase --continue

Cancel rebase:

git rebase --abort

🧠 Git mastery workflow (real-world pattern)

This is what developers actually do:

git checkout -b new-feature
# work on code
git add .
git commit -m "add feature"
git push -u origin new-feature

Then open a Pull Request on GitHub.

🚀 Beginner → Advanced roadmap

🟢 Beginner

git init
add / commit / push / pull
status

🟡 Intermediate

branches
merge
remote repos
fetch

🔵 Advanced

rebase
stash
cherry-pick
reset / revert
conflict resolution

💡 Final Advice

Don’t try to memorize everything.

Instead focus on:

branch → commit → push → pull request

Everything else builds on that.

Here’s a beginner-friendly guide to GitHub, especially focused on forks and pull requests, which are the core of real-world collaboration

Kyle Y. Parsotan — Sat, 23 May 2026 20:20:42 +0000

🚀 GitHub for Beginners (Forks, Pull Requests, and Collaboration)

GitHub is where developers store code, collaborate, and contribute to projects. If Git is the engine, GitHub is the social platform built on top of it.

Let’s break it down simply.

🌍 1. What is GitHub?

GitHub is a website that hosts Git repositories online.

It lets you:

Store your code in the cloud
Collaborate with others
Contribute to open-source projects
Track changes and history

👉 Think of Git as your local notebook and GitHub as Google Drive for code.

🍴 2. What is a Fork?

A fork is a copy of someone else’s repository under your own GitHub account.

Why fork a repo?

You don’t have permission to edit the original project
You want to experiment safely
You want to contribute to open-source projects

How it works:

You click Fork on GitHub
GitHub creates a copy in your account
You can edit freely without affecting the original project

🔄 3. What is a Pull Request (PR)?

A Pull Request is how you suggest changes to someone else’s project.

Think of it like:

“Hey, I made improvements—please review and add them to your project.”

🧠 Simple Flow:

Fork a repo
Clone it to your computer
Make changes
Push changes to your fork
Open a Pull Request

🛠️ 4. Step-by-Step Workflow

Step 1: Fork a repository

On GitHub:

Open any repo you want to contribute to
Click Fork (top right corner)

Step 2: Clone your fork

```bash id="f8c1g2"
git clone https://github.com/your-username/repo-name.git
cd repo-name




---

## Step 3: Create a branch (important!)

Never work directly on main.



```bash id="b9k3m1"
git checkout -b my-feature

Step 4: Make changes

Edit files normally in your code editor.

Step 5: Add and commit changes

```bash id="q2r7t9"
git add .
git commit -m "Add new feature or fix bug"




---

## Step 6: Push to your GitHub fork



```bash id="l4x8n3"
git push origin my-feature

Step 7: Open a Pull Request

Go to your fork on GitHub:

Click “Compare & pull request”
Add a title and description
Click “Create Pull Request”

🔍 5. What happens after a Pull Request?

Once you submit a PR:

Maintainers review your code
They may request changes
You can update your PR with more commits
If approved → it gets merged 🎉

🔁 6. Keeping your fork updated

Original repos change over time. You need to sync your fork:

Add original repo as upstream:

```bash id="u1p9v5"
git remote add upstream https://github.com/original-owner/repo.git




### Pull latest changes:



```bash id="k7s2m8"
git fetch upstream
git merge upstream/main

🧠 7. GitHub Concepts Cheat Sheet

Term	Meaning
Repo	Project folder on GitHub
Fork	Your personal copy of a repo
Clone	Download repo to your computer
Branch	Separate working version
Commit	Saved change
Pull Request	Request to merge changes
Merge	Combine changes into main project

⚠️ 8. Common Beginner Mistakes

❌ Working on main branch

Always use a feature branch.

❌ Forgetting to fork first

You usually cannot push directly to someone else’s repo.

❌ One huge commit

Break work into small, meaningful commits.

💡 9. Real-world example

Imagine you fix a typo in a website:

Fork repo
Clone it
Fix typo
Push change
Submit PR
Maintainer merges it

🎉 You just contributed to open source!

🧭 Final Thoughts

GitHub is all about collaboration and contribution. Once you understand forks and pull requests, you unlock the ability to:

Work on real projects
Contribute to open source
Build a developer portfolio
Work like professionals in tech companies

If you want next, I can show you:

🧪 A practice open-source project to try your first PR
💼 How companies actually use GitHub (real workflow)
🧠 How to write a perfect pull request description
⚡ GitHub Actions (CI/CD automation basics)

Just tell me 👍

A Beginner’s Guide to Git: What It Is and Why It Matters

Kyle Y. Parsotan — Sat, 23 May 2026 20:19:38 +0000

If you’ve ever worked on a coding project and found yourself saving files like final_version, final_version_v2, or final_really_final, you’ve already experienced the problem Git was designed to solve.

Git is a tool that helps you track changes in your code, collaborate with others, and safely experiment without fear of breaking your project.

Let’s break it down in a simple, beginner-friendly way.

What is Git?

Git is a version control system. That means it records changes to files over time so you can:

Go back to previous versions of your project
See what changed and who changed it
Work on multiple features at the same time
Collaborate with other developers without conflicts

Think of it like a time machine for your code.

Why Git is So Important

Without Git, development looks like this:

You edit files directly
You overwrite things by mistake
You struggle to combine work from teammates
You lose track of what changed and why

With Git, you get:

A complete history of your project
Safe experimentation using branches
Easy collaboration with others
Confidence that you can always recover your work

Key Git Concepts You Should Know

1. Repository (Repo)

A repository is your project folder that Git is tracking. It contains all your files and their history.

You create one using:

git init

2. Commit

A commit is like a snapshot of your project at a point in time.

Each commit includes:

What changed
When it changed
Who changed it

Example:

git commit -m "fix login bug"

3. Staging Area

Before saving changes (committing), you place them in a staging area.

git add .

This tells Git: “I’m ready to save these changes.”

4. Branches

Branches let you work on new features without affecting the main project.

For example:

main → stable version
feature-login → new login system

Create a branch:

git checkout -b feature-login

5. Merge

Once your feature is ready, you combine it back into the main project:

git merge feature-login

Basic Git Workflow

Here’s what developers typically do every day:

git status
git add .
git commit -m "describe changes"
git push

And when working with others:

git pull

This keeps your local project updated.

Git + GitHub (Important Difference)

Git = tool on your computer
GitHub = website that stores Git repositories online

GitHub allows you to:

Backup your code
Collaborate with others
Share projects publicly or privately

Common Beginner Mistakes

❌ Not committing often enough

Fix: commit small changes regularly.

❌ Confusing Git and GitHub

Git works locally; GitHub is online storage.

❌ Ignoring branch usage

Branches keep your work clean and organized.

Why Developers Love Git

Git is used by almost every developer because it:

Prevents code loss
Makes teamwork easier
Tracks project history clearly
Supports professional development workflows

Once you understand Git, you can work on real-world software projects confidently.

Final Thoughts

Git might feel confusing at first, but once you start using it daily, it becomes second nature. The key is not memorizing every command—it’s understanding the workflow:

Edit → Stage → Commit → Push → Repeat

If you’re learning to code, Git is not optional—it’s essential.

If you want next steps, I can also help you with:

GitHub for beginners (pull requests, forks)
Real-world Git workflows used in companies
Practice projects to master Git fast

🚨 Common React & npm Bugs (and How to Fix Them Like a Pro)

Kyle Y. Parsotan — Wed, 22 Apr 2026 01:58:32 +0000

Every developer hits weird errors. The difference between struggling for hours vs fixing things fast comes down to pattern recognition.

This post breaks down well-known bugs, why they happen, and how to fix them quickly—especially in projects using Create React App and the Node ecosystem.

🧨 1. `react-scripts: command not found`

❌ Error

sh: react-scripts: command not found

💥 Why it happens

react-scripts isn’t installed
node_modules is missing/corrupted
Wrong project directory

✅ Fix

rm -rf node_modules package-lock.json
npm install

If still broken:

npm install react-scripts

🔐 2. EACCES Permission Denied

❌ Error

EACCES: permission denied, mkdir 'node_modules/.cache'

💥 Why it happens

You used sudo npm install
Files are owned by root

✅ Fix

sudo chown -R $(whoami) .
rm -rf node_modules package-lock.json
npm install

🚫 Never use:

sudo npm install

📦 3. `node_modules` Hell (Corrupted installs)

❌ Symptoms

Random errors after install
Missing packages
App won’t start

💥 Why it happens

Interrupted installs
Lockfile conflicts
Cache issues

✅ Fix (golden reset)

rm -rf node_modules package-lock.json
npm cache clean --force
npm install

⚠️ 4. Version Mismatch (Node issues)

❌ Symptoms

Packages fail to install
Build crashes
Strange syntax errors

💥 Why it happens

Some tools don’t support newer Node versions.

✅ Fix

node -v

Use:

Node 18 or 20

Use a version manager if needed.

🔄 5. Mixing Package Managers

❌ Symptoms

Duplicate dependencies
Lockfile conflicts
Install failures

💥 Why it happens

Using npm + yarn together.

✅ Fix

Use ONE:
- package-lock.json → npm
- yarn.lock → yarn

🌐 6. Port Already in Use

❌ Error

Something is already running on port 3000

💥 Why it happens

Another process is using the port.

✅ Fix

lsof -i :3000
kill -9 <PID>

🧪 7. ESLint Permission Errors

❌ Error

EACCES: permission denied

💥 Why it happens

Same root cause: ownership issues.

✅ Fix

sudo chown -R $(whoami) .

⚡ 8. `Module not found` Errors

❌ Error

Module not found: Can't resolve 'xyz'

💥 Why it happens

Package not installed
Wrong import path
Case-sensitive file systems

✅ Fix

npm install xyz

Or fix import:

import Component from "./Component" // not ./component

🔥 9. Environment Variables Not Working

❌ Symptoms

process.env is undefined

💥 Why it happens

In CRA, env vars must start with:

REACT_APP_

✅ Fix

REACT_APP_API_URL=https://api.com

Restart dev server after changes.

🧠 10. Outdated Tooling Problems

❌ Symptoms

Random build errors
Slow dev server
Weird dependency issues

💥 Why it happens

Older tools like Create React App rely on aging dependencies.

🚀 Modern Fix (Long-Term)

Instead of constantly patching bugs:

Switch to:

⚡ Vite
🔥 Next.js

Example (Vite setup)

npm create vite@latest my-app
cd my-app
npm install
npm run dev

👉 Faster, fewer bugs, better DX.

🧠 Final Thoughts

Most “React bugs” are actually:

⚙️ environment problems, not code problems

Once you recognize patterns like:

permissions
missing dependencies
version mismatches

You’ll debug 10x faster.

💬 What bug are you stuck on?

Drop your error below 👇
I’ll help you debug it step-by-step.

🚨 Fix “sh: react-scripts: command not found” (Complete Guide)

Kyle Y. Parsotan — Tue, 21 Apr 2026 16:42:20 +0000

If you’re working on a React project and suddenly see:

sh: react-scripts: command not found

Don’t panic — this is a very common issue, especially in projects created with Create React App.

This guide breaks down:

✅ Why this happens
🧨 Common mistakes
⚡ Proven fixes
🚀 Long-term solutions

🧠 Why this error happens

This error means your system can’t find the react-scripts binary.

react-scripts is the tool that powers:

npm start
npm build
npm test

If it’s missing or broken → your app won’t run.

🧨 Common causes

Here’s what usually triggers the issue:

❌ node_modules folder is missing or corrupted
❌ react-scripts not installed in dependencies
❌ Wrong working directory
❌ Mixing package managers (npm, yarn, pnpm)
❌ Broken install or cache
❌ Node version incompatibility

⚡ Fix #1: Reinstall dependencies (Most Effective)

Start with a clean slate:

rm -rf node_modules package-lock.json
npm install
npm start

👉 This alone fixes most cases.

📦 Fix #2: Install react-scripts manually

Check your package.json:

"dependencies": {
  "react-scripts": "5.0.1"
}

If it’s missing:

npm install react-scripts

📁 Fix #3: Make sure you're in the right folder

Run:

ls

You should see:

package.json
src/
public/

If not → navigate to your project:

cd your-project-name

🧪 Fix #4: Run with npx

Quick workaround:

npx react-scripts start

👉 This bypasses local binary issues.

⚙️ Fix #5: Run the binary directly

On Mac/Linux:

./node_modules/.bin/react-scripts start

If this works → your PATH is misconfigured.

🔥 Fix #6: Clear npm cache (if installs fail)

npm cache clean --force
npm install

🧠 Fix #7: Check Node version

Some versions break compatibility.

node -v

Recommended:

Node 18, 20, 22, 25

Use a version manager if needed.

⚠️ Fix #8: Don’t mix package managers

If you see:

package-lock.json → use npm
yarn.lock → use yarn

🚫 Don’t mix them — it causes dependency conflicts.

🚀 The bigger issue (and better solution)

Let’s be real:
Projects using Create React App and react-scripts are aging.

Modern alternatives are faster and more reliable:

⚡ Vite
🔥 Next.js

🆕 Bonus: Create a new app with Vite

If you’re starting fresh:

npm create vite@latest my-app
cd my-app
npm install
npm run dev

👉 Much faster startup, fewer issues.

🧠 Final thoughts

This error isn’t really about React — it’s about your environment setup.

Once you understand that:

You stop guessing… and start fixing things fast.

💬 Have you hit this bug?

Drop your setup (Node version, package manager, error logs), and I’ll help debug it with you 👇

🎧 SpinTicket – DJ Ticket Management System

Kyle Y. Parsotan — Wed, 18 Mar 2026 22:40:37 +0000

🌟 Inspiration Managing event tickets as a DJ or event organizer is often chaotic—spreadsheets, screenshots, scattered guest lists, and last‑minute changes. I wanted a system that felt simple, fast, and built for real‑world nightlife workflows, not corporate event software. SpinTicket was born from the idea of giving DJs and promoters a clean, modern, and secure way to manage ticketing without friction.

🎟️ What It Does SpinTicket is a full-featured ticket management platform designed specifically for DJs, promoters, and small event organizers. It provides:

Ticket creation & management

Real‑time notifications using WebSockets

Secure ticket storage using encrypted data

Instant email confirmations via Resend

LocalStorage persistence for fast client-side access

A clean, responsive UI built with TailwindCSS

QR code ticket validation (optional future feature)

It’s built to be fast, intuitive, and reliable during high‑pressure event situations.

🛠️ How I Built It SpinTicket is built with a modern, scalable stack:

Next.js – for routing, server actions, and API endpoints

TailwindCSS – for rapid UI development

Resend – for sending ticket confirmations and updates

WebSockets – for real‑time ticket status updates

LocalStorage – for client-side session persistence

Custom encryption layer – to protect sensitive ticket data

The architecture focuses on speed, security, and simplicity, making it ideal for DJs who need tools that work instantly.

⚠️ Challenges I Ran Into Designing a real-time system that stays lightweight

Ensuring secure encryption without slowing down performance

Handling email deliverability and formatting across devices

Creating a UI that works well in dark club environments

Managing state between server actions and client-side storage

Each challenge pushed the system to become more polished and reliable.

🏆 Accomplishments That I’m Proud Of Building a fully functional real-time ticketing workflow

Implementing industry-level encryption for ticket data

Creating a smooth, mobile-first interface

Integrating instant email notifications that feel professional

Making a system that DJs can actually use during live events

It’s a project that solves a real problem in a clean, modern way.

📚 What I Learned How to architect real-time WebSocket systems

Best practices for secure data handling and encryption

How to design UX for fast-paced environments

Advanced Next.js server actions and API routes

Email templating and delivery optimization with Resend

This project pushed my full-stack skills to a new level.

🚀 What’s Next for SpinTicket QR code scanning for ticket validation

Multi‑DJ / multi‑event dashboards

Analytics for event attendance

Stripe integration for paid ticketing

Mobile app version

Role-based access for promoters, staff, and DJs

SpinTicket is just getting started—there’s a lot of room to grow into a full event‑management ecosystem.

Demo it today
Spin Ticket

DEV Community: Kyle Y. Parsotan

End-to-End (E2E) testing pipeline

🧠 0. What is E2E testing?

⚔️ Playwright vs Cypress (quick decision)

🧱 1. Install Playwright (React project)

🧪 3. First E2E test (real user flow)

Example: Login flow test

⚙️ 6. GitHub Actions CI pipeline (E2E automation)

📁 .github/workflows/e2e.yml

📊 8. Add HTML test report

🌐 9. Test real deployed app (PRO setup)

🟡 Form validation test

🔐 11. CI best practices (IMPORTANT)

✔ Run E2E after build

✔ Use staging environment

✔ Retry flaky tests

🚀 What you just built

Auto versioning + changelog generation using Github Action

🧠 0. What we’re building

🧠 2. Use Conventional Commits (VERY important)

✅ Examples

Feature (minor version bump)

Breaking change (major version bump)

⚙️ 3. Create semantic-release config

📁 .releaserc.json

Changelog

🧠 6. What this does automatically

It will:

📜 7. Example auto-generated changelog

1.2.0 (2026-05-23)

Features

Bug Fixes

🏷️ 8. Example GitHub releases

🔐 9. GitHub Secrets needed

GitHub automatically:

🔥 11. Pro upgrades (used in companies)

🟢 Auto publish npm package

🟡 Slack release notification

🔵 Multi-branch releases

❌ Forgetting fetch-depth: 0

🧠 Final architecture

Auto PR + Auto Deploy workflow using CI/CD Pipline

🧠 0. What we are building

🧠 What this does:

🧪 2. CI Pipeline (runs on PRs)

📁 .github/workflows/ci.yml

🔐 4. GitHub Secrets Setup

Then GitHub automatically:

🔥 6. Upgrade (what real companies add)

🟢 Add approval rule (recommended)

🟡 Add branch protection

🔵 Add notifications (Slack/Discord)

🟣 Add version tagging

CI/CD Pipline

🚀 Full CI/CD Pipeline (React + Node + GitHub Actions)

🧱 Architecture

📁 Example Project Structure

🚀 CD Pipeline (Deployment)

Example: Deploy backend + frontend

🧪 What happens when you push code?

Example flow:

🧠 What real companies add on top

🔥 1. Linting

🔥 Caching (faster builds)

🔥 Parallel jobs

🚀 Real-world deployment options

Frontend

Backend

⚠️ Common mistakes in CI/CD

❌ No environment variables

❌ Missing build step

❌ Not separating frontend/backend

❌ No test stage

🧭 Production-grade CI/CD flow

Github Action Core part of Automation

🚀 GitHub Actions (CI/CD Automation Basics)

🧠 What is CI/CD?

CI = Continuous Integration

CD = Continuous Deployment

⚙️ What are GitHub Actions?

📁 `.github/workflows/e2e.yml`

📁 `.releaserc.json`

📁 `.github/workflows/ci.yml`