CI/CD Pipeline Reference with GitHub Actions

A reference implementation of a continuous integration and deployment workflow using GitHub Actions, automated tests, controlled deployments, semantic version tags, and deployment notifications.

The repository contains a React Pokédex application used to demonstrate the complete delivery lifecycle from pull-request validation to production deployment on Render.

Live Application

Open the deployed Pokédex

The application is hosted on Render and may require a short startup period after inactivity.

What This Project Demonstrates

• Continuous integration for pushes and pull requests targeting main.
• Static code analysis with ESLint.
• Component and unit testing with Jest.
• Production builds with Webpack.
• End-to-end browser testing with Playwright.
• Deployment to Render only after successful validation.
• Automatic patch-version tags after deployment.
• Success and failure notifications through Discord.
• Optional deployment skipping through commit-message controls.
• Protected-branch and pull-request workflows.
• Operational health and version endpoints.

Technology Stack

Application

• React
• React Router
• Axios
• Express
• PokeAPI
• JavaScript

Build and Testing

• Webpack
• Babel
• Jest
• React Testing Library
• Playwright
• ESLint

Delivery

• GitHub Actions
• Render
• Git version tags
• Discord deployment notifications

Application Architecture

Browser
   |
   | HTTP
   v
React application
   |
   | REST requests
   v
PokeAPI

For production, Webpack generates the frontend assets in the dist directory. A small Express server serves those static files and exposes operational endpoints.

Delivery Workflow

Pull request to main
        |
        v
Install dependencies
        |
        v
Run ESLint
        |
        v
Run Jest tests
        |
        v
Create production build
        |
        v
Run Playwright E2E tests
        |
        v
Validation complete

For an eligible push to main, the workflow continues:

Successful validation
        |
        v
Trigger Render deployment
        |
        +----------------------+
        |                      |
        v                      v
Create patch version tag   Send success notification

If validation, deployment, or version tagging fails, the workflow sends a failure notification containing repository, commit, branch, workflow, and run information.

Pipeline Behavior

The GitHub Actions workflow runs when:

• A commit is pushed to main.
• A pull request targeting main is opened.
• A pull request targeting main receives new commits.

Pull requests execute the validation pipeline but do not deploy the application.

Deployment, version tagging, and success notifications only execute for eligible pushes to main.

Deployment Control

A commit containing the following token skips deployment and version tagging:

#skip

The validation stages still run, allowing documentation or maintenance changes to be checked without triggering a new deployment.

Example:

docs: improve project documentation #skip

Automated Version Tagging

After a successful production deployment, the pipeline creates a new Git tag using a patch-version increment.

Example:

v1.0.0
v1.0.1
v1.0.2

The workflow uses the repository-provided GITHUB_TOKEN to create and push the tag.

This mechanism creates version tags; it does not currently generate GitHub Release pages or release artifacts.

Notifications

The workflow sends Discord notifications for:

• Successful production deployments.
• Validation, deployment, or version-tagging failures.

Notifications include contextual information such as:

• Repository.
• Commit SHA.
• Branch.
• Workflow.
• Run number.

Required Repository Secrets

The deployment workflow requires:

RENDER_DEPLOY_HOOK
DISCORD_WEBHOOK

RENDER_DEPLOY_HOOK triggers the Render deployment.

DISCORD_WEBHOOK sends success and failure notifications.

Secrets must be configured through GitHub repository settings and must never be committed to source control.

Operational Endpoints

Method	Endpoint	Purpose
GET	/health	Verify that the Express application is running
GET	/version	Return the current application version value

Example health response:

ok

End-to-End Testing

Playwright starts the production application locally before executing the browser tests.

The current E2E suite verifies that:

• The Pokédex front page opens successfully.
• Pokémon information is displayed.
• A user can navigate from the list to an individual Pokémon page.
• Expected details are displayed after navigation.

Running Locally

Prerequisites

• Node.js
• npm

Clone the Repository

git clone https://github.com/dannydj/fullstackopen-cicd.git
cd fullstackopen-cicd

Install Dependencies

npm install

Start Development Mode

npm start

The Webpack development server runs by default at:

http://localhost:8080

Create a Production Build

npm run build

Start the Production Server

npm run start-prod

The Express server runs by default at:

http://localhost:5001

Quality Commands

Run the Jest test suite:

npm test

Run static code analysis:

npm run eslint

Run the Playwright end-to-end suite:

npm run test:e2e

Playwright automatically builds and starts the production application before executing the E2E tests.

Project Structure

fullstackopen-cicd/
├── .github/
│   └── workflows/
│       └── pipeline.yml
├── e2e-tests/
│   └── pokedex.spec.js
├── public/
├── src/
├── app.js
├── package.json
├── playwright.config.js
├── webpack.config.js
└── README.md

Current Limitations

• The /version endpoint is currently maintained independently from the generated Git tags.
• The pipeline creates Git tags but does not create GitHub Releases.
• Deployment verification does not currently include a post-deployment smoke test.
• The application depends on the availability of the external PokeAPI service.
• Discord notifications depend on an externally configured webhook.
• The project is intended as a CI/CD reference and not as a production Pokémon service.

Possible Improvements

• Synchronize the /version endpoint with the generated release tag.
• Add a post-deployment health-check or smoke-test job.
• Replace npm install with deterministic npm ci execution.
• Cache npm and Playwright dependencies between workflow runs.
• Generate deployment artifacts and GitHub Releases.
• Pin every third-party GitHub Action to an immutable commit SHA.
• Add dependency and security scanning.
• Use job-specific minimum GitHub Actions permissions.
• Add workflow concurrency controls to prevent overlapping deployments.

Companion Project

The concepts from this repository were also applied to a separate full-stack application:

Full-Stack Phonebook with CI/CD

That project demonstrates a React, Node.js, Express, and MongoDB application with its own validation and deployment pipeline.

Educational Context

This repository was developed as part of the University of Helsinki's Full Stack Open — Part 11: Continuous Integration / Continuous Deployment.

The application uses the course's Pokédex starter project as the system under delivery. The GitHub Actions workflow, automated deployment, version tagging, notifications, and related delivery controls were implemented as part of the CI/CD exercises.

License

The project retains the ISC license metadata from the original starter project.