Added Jenkinsfile to root

Dockerfile

@@ -0,0 +1,50 @@
+FROM openjdk:11
+WORKDIR /app
+
+# get chromedriver& pipenv & unzip then delete cache
+RUN apt-get update && apt-get install -y \
+    chromium chromium-driver \
+    python3 python3-pip pipenv \
+    wget unzip xvfb fonts-liberation && \
+    rm -rf /var/lib/apt/lists/*
+
+# Start Xvfb and set DISPLAY
+ENV DISPLAY=:99
+# Set up Python environment
+RUN pipenv install --python 3 \
+    && pipenv install pytest requests behave behave2cucumber selenium PyHamcrest 
+
+
+
+# gradle copy and set permission
+COPY gradlew .
+COPY gradle ./gradle
+RUN chmod +x ./gradlew
+
+COPY build.gradle .
+
+COPY src ./src
+
+# build project
+RUN ./gradlew clean build
+
+# install tomcat
+RUN wget https://downloads.apache.org/tomcat/tomcat-9/v9.0.100/bin/apache-tomcat-9.0.100.tar.gz \
+    && tar -xzf apache-tomcat-9.0.100.tar.gz \
+    && mv apache-tomcat-9.0.100 tomcat \
+    && rm apache-tomcat-9.0.100.tar.gz
+
+
+
+RUN mkdir -p tomcat/webapps/
+
+# copy war file to tomcat webapps
+RUN cp build/libs/app.war tomcat/webapps/demo.war
+
+
+
+EXPOSE 8080
+
+# run tomcat server
+CMD Xvfb :99 -screen 0 1920x1080x24 & \
+    sh -c "./tomcat/bin/catalina.sh run"

Jenkinsfile

@@ -0,0 +1,211 @@
+// This jenkinsfile is used to run CI/CD on my local (Windows) box, no VM's needed.
+
+pipeline {
+
+  agent any
+
+   environment {
+        // This is set so that the Python API tests will recognize it
+        // and go through the Zap proxy waiting at 9888
+        HTTP_PROXY = 'http://127.0.0.1:9888'
+   }
+
+  stages {
+
+    // build the war file (the binary).  This is the only
+    // place that happens.
+    stage('Build') {
+      steps {
+        sh './gradlew clean assemble'
+      }
+    }
+
+    // run all the unit tests - these do not require anything else
+    // to be running and most run very quickly.
+    stage('Unit Tests') {
+      steps {
+        sh './gradlew test'
+      }
+      post {
+        always {
+          junit 'build/test-results/test/*.xml'
+        }
+      }
+    }
+
+    // run the tests which require connection to a
+    // running database.
+    stage('Database Tests') {
+      steps {
+        sh './gradlew integrate'
+      }
+      post {
+        always {
+          junit 'build/test-results/integrate/*.xml'
+        }
+      }
+    }
+
+    // These are the Behavior Driven Development (BDD) tests
+    // See the files in src/bdd_test
+    // These tests do not require a running system.
+    stage('BDD Tests') {
+      steps {
+        sh './gradlew generateCucumberReports'
+        // generate the code coverage report for jacoco
+        sh './gradlew jacocoTestReport'
+      }
+      post {
+          always {
+            junit 'build/test-results/bdd/*.xml'
+          }
+        }
+    }
+
+    // Runs an analysis of the code, looking for any
+    // patterns that suggest potential bugs.
+    stage('Static Analysis') {
+      steps {
+        sh './gradlew sonarqube'
+        // wait for sonarqube to finish its analysis
+        sleep 5
+        sh './gradlew checkQualityGate'
+      }
+    }
+
+
+    // Move the binary over to the test environment and
+    // get it running, in preparation for tests that
+    // require a whole system to be running.
+    stage('Deploy to Test') {
+      steps {
+      sh './gradlew deployToTestWindowsLocal'
+      // pipenv needs to be installed and on the path for this to work.
+      sh 'PIPENV_IGNORE_VIRTUALENVS=1 pipenv install'
+
+      // Wait here until the server tells us it's up and listening
+      sh './gradlew waitForHeartBeat'
+
+      // clear Zap's memory for the incoming tests
+      sh 'curl http://zap/JSON/core/action/newSession -s --proxy localhost:9888'
+      }
+    }
+
+
+    // Run the tests which investigate the functioning of the API.
+    stage('API Tests') {
+      steps {
+        sh './gradlew runApiTests'
+      }
+      post {
+        always {
+          junit 'build/test-results/api_tests/*.xml'
+        }
+      }
+    }
+
+    // We use a BDD framework for some UI tests, Behave, because Python rules
+    // when it comes to experimentation with UI tests.  You can try things and see how they work out.
+    // this set of BDD tests does require a running system.
+    // BDD at the UI level is just to ensure that basic capabilities work,
+    // not that every little detail of UI functionality is correct.  For
+    // that purpose, see the following stage, "UI Tests"
+    stage('UI BDD Tests') {
+      steps {
+        sh './gradlew runBehaveTests'
+        sh './gradlew generateCucumberReport'
+      }
+      post {
+        always {
+          junit 'build/test-results/bdd_ui/*.xml'
+        }
+      }
+    }
+
+    // This set of tests investigates the functionality of the UI.
+    // Note that this is separate fom the UI BDD Tests, which
+    // only focuses on essential capability and therefore only
+    // covers a small subset of the possibilities of UI behavior.
+    stage('UI Tests') {
+        steps {
+            sh 'cd src/ui_tests/java && ./gradlew clean test'
+        }
+        post {
+            always {
+                junit 'src/ui_tests/java/build/test-results/test/*.xml'
+            }
+        }
+    }
+
+    // Run OWASP's "DependencyCheck". https://owasp.org/www-project-dependency-check/
+    // You are what you eat - and so it is with software.  This
+    // software consists of a number of software by other authors.
+    // For example, for this project we use language tools by Apache,
+    // password complexity analysis, and several others.  Each one of
+    // these might have security bugs - and if they have a security
+    // bug, so do we!
+    //
+    // DependencyCheck looks at the list of known
+    // security vulnerabilities from the United States National Institute of
+    // Standards and Technology (NIST), and checks if the software
+    // we are importing has any major known vulnerabilities. If so,
+    // the build will halt at this point.
+    stage('Security: Dependency Analysis') {
+      steps {
+         sh './gradlew dependencyCheckAnalyze'
+      }
+    }
+
+    // Run Jmeter performance testing https://jmeter.apache.org/
+    // This test simulates 50 users concurrently using our software
+    // for a set of common tasks.
+    stage('Performance Tests') {
+      steps {
+         sh './gradlew runPerfTests'
+      }
+    }
+
+    // Runs mutation testing against some subset of our software
+    // as a spot test.  Mutation testing is where bugs are seeded
+    // into the software and the tests are run, and we see which
+    // tests fail and which pass, as a result.
+    //
+    // what *should* happen is that where code or tests are altered,
+    // the test should fail, shouldn't it? However, it sometimes
+    // happens that no matter how code is changed, the tests
+    // continue to pass, which implies that the test wasn't really
+    // providing any value for those lines.
+    stage('Mutation Tests') {
+      steps {
+         sh './gradlew pitest'
+      }
+    }
+
+    stage('Build Documentation') {
+      steps {
+         sh './gradlew javadoc'
+      }
+    }
+
+    stage('Collect Zap Security Report') {
+      steps {
+        sh 'mkdir -p build/reports/zap'
+        sh 'curl http://zap/OTHER/core/other/htmlreport --proxy localhost:9888 > build/reports/zap/zap_report.html'
+      }
+    }
+
+
+    // This is the stage where we deploy to production.  If any test
+    // fails, we won't get here.  Note that we aren't really doing anything - this
+    // is a token step, to indicate whether we would have deployed or not.  Nothing actually
+    // happens, since this is a demo project.
+    stage('Deploy to Prod') {
+      steps {
+        // just a token operation while we pretend to deploy
+        sh 'sleep 5'
+      }
+    }
+
+  }
+
+}

Proejct_Instruction.md

@@ -0,0 +1,58 @@
+# ENSF 400 - Winter 2025 - Course Project
+
+## Project Overview
+
+In this project, you will work based on a software project by incorporating/extending a complete CI/CD (Continuous Integration/Continuous Deployment) pipeline. This is based on an open-source sample application: https://github.com/7ep/demo
+
+This project can also be any application that requires the project of build, test, and deployment.
+You will leverage GitHub for source control, Docker for containerizing your application, and a CI/CD tool (Jenkins) to automate the build, testing, and verification process. The goal is to validate every code change automatically through container builds, unit tests, code quality checks, and end-to-end functional tests.
+
+
+## Project Requirements
+
+By the end of this project, your group must deliver the following:
+
+1.	Manage your project on GitHub and follow proper Git workflows (branching, pull requests, code reviews). Document the process of how you use Git workflows to collaborate with your team members.
+
+1.	Containerize your application for builds and deployments. Upload and download your container images to a public or private image repository (e.g., Docker Hub or GitHub Container Registry). Ensure a container image is built with unique build tag(s) matching the triggering commit from any branch.
+
+1.	Set up an automated CI/CD with Jenkins in a Codespace environment. Configure the pipeline to trigger upon pull requests merging changes into the main branch.
+
+1.	Document the CI/CD process and provide clear instructions on replicating your environment. Submit a video demo at the end of the project.
+
+### Existing Pipelines
+You will also demonstrate the delivery of the following process and artifacts that come with the project.
+
+1.	Run static analysis quality-gating using SonarQube
+1.	Performance testing with Jmeter
+1.	Security analysis with OWASP's "DependencyCheck"
+1.	Build Javadocs
+
+
+## Evaluation Criteria
+
+Your project will be assessed on the following criteria:
+
+### GitHub Repository & Git Workflow (15%)
+1.	Project on GitHub in a public repository with all team members participating in the development and maintenance of the project (5%).
+1.	Demonstrate the process practicing Git workflows (branching, pull requests, code reviews) (10%).
+
+### Containerization (20%)
+1.	Dockerfile to containerize the project (5%).
+1.	Use of container image repository to upload and download images (5%).
+1.	Effective tagging mechanism for each building matching the commits/branches/pull requests (10%).
+
+### CI/CD Pipeline Automation (40%)
+1.	Jenkins integration with GitHub in Codespace (10%).
+1.	Triggering automated checks upon pull request to the main branch (10%).
+1.	Deployment process to automatically deploy the application in the Codespace environment upon a build (10%).
+1.	Be able to run items 5-8 in **Existing Pipelines** (10%).
+
+### Testing & Code Quality (10%)
+1.	Generate test coverage reports upon each automated build (5%).
+1.	Generate code quality report using SonarQube reports upon each automated build (5%).
+
+### Documentation & Demo (15%)
+1.	Clarity and completeness of README and other documentation. The documentation must demonstrate the team’s collaboration process (5%).
+1.	Demonstration video with a length not exceeding 10 minutes, showing a clear understanding of the pipeline and its benefits. The documentation must demonstrate the team’s collaboration process (10%).
+

build.gradle

@@ -15,7 +15,8 @@ plugins {
 
     // gretty is a gradle plugin to make it easy to run a server and hotswap code at runtime.
     // https://plugins.gradle.org/plugin/org.gretty
-    id 'org.gretty' version '3.0.4'
+
+    id 'org.gretty' version '3.1.5'
 
     // provides access to a database versioning tool.
     id "org.flywaydb.flyway" version "6.0.8"
@@ -219,7 +220,7 @@ cucumberReports {
     // merge together all the cucumber reports with a suffix of "json"
     reports = files(fileTree(dir: "build/bdd", include: '*.json'))
     testTasksFinalizedByReport = false
-    projectNameOverride = "$projectname"
+    projectNameOverride = 'demo-app'
 }
 
 flyway {