Merge pull request #16 from Moonbeam69/Pipeline_Test_Branch

Pipeline test branch merge
Moonbeam69 · May 31, 2024 · cb497a5 · cb497a5
2 parents 3f61112 + ef47e87
commit cb497a5
Show file tree

Hide file tree

Showing 4 changed files with 29 additions and 27 deletions.
diff --git a/.github/workflows/CICD_Main_Pipeline -4Test.yml b/.github/workflows/CICD_Main_Pipeline -4Test.yml
@@ -5,9 +5,9 @@ env:
 
 on:
   push:
-    branches: [ "master" ]
+    branches: [ "Pipeline_Test_Branch" ]
   pull_request:
-    branches: [ "master" ]
+    branches: [ "Pipeline_Test_Branch" ]
   workflow_dispatch:
 
 jobs:

diff --git a/Limitations.md b/Limitations.md
@@ -0,0 +1,8 @@
+### Limitations
+
+|   | Description                                              | Mitigation                                                        |
+|---|----------------------------------------------------------|-------------------------------------------------------------------|
+| 1 | Cannot run Safari tests on Linux                         | Webkit is supported                                               |
+| 2 | Browserstack eval license only supports Win/Chromium     | Buy license                                                       |
+| 3 | Matrix strategy auto-combines                            | Care must be taken that all target environments support the tests |
+| 4 | Installtion of Maven is not managed through the workflow | Can be managed in the same way as Java is managed                 |
diff --git a/README.md b/README.md
@@ -3,8 +3,8 @@
 [![CICD workflow - 4Test](https://github.com/Moonbeam69/CICDDemo/actions/workflows/CICD_Main_Pipeline%20-4Test.yml/badge.svg)](https://github.com/Moonbeam69/CICDDemo/actions/workflows/CICD_Main_Pipeline%20-4Test.yml)
 
 ## Description
-
-This project demonstrate the basics principles of a CICD pipeline development. I've used Github Actions, (self-hosted) Runners, Browserstack integration, Junit unit test cases, Playwright browser test cases and the creation of a Docker image.
+ 
+This project demonstrates best-practices of a CICD pipeline development. I've used Github Actions, (self-hosted) Runners, Browserstack integration, Junit unit test cases, Playwright browser test cases and the creation of a Docker image.
 
 ### Environment
 - Local LAN comprising:
@@ -22,20 +22,24 @@ This project demonstrate the basics principles of a CICD pipeline development. I
 ### CICD Pipeline Strategy
 
 1. After a Push or Pull Request into master, CICD_Main_Pipeline.yml is executed. This workflow takes a build through three test levels to a fictional production environment
-3. CICD_Main_Pipeline.yml performs the following steps:
+2. CICD_Main_Pipeline.yml performs the following steps:
    - Setup: JDK 19 (OpenJDK temurin|zulu distribution) is deployed to the runner (self-hosted). THe latest version of the this script:
      - Checks if the correct version of JDK is already installed and if it is, proceeds to build
      - If not, the cache is checked and if present downloaded from there
-     - If not, then is retrived from a prebuilt image provided by GitHub.
+     - If not, the JDK is retrieved from a prebuilt image provided by GitHub.
      - Note I am not convinced this logic is required as the JDK will not change much over the lifespan of a single project but it is included as POC
    - Build: Maven builds the project and runs tests. Maven must be installed on all Runners beforehand. 
    - Tests are Junit tests with and without Playwright running on local or Browserstack browsers 
    - Docker: Docker creates a new Docker image from the project Dockerfile, copies and executes the mainClass from project Jar (no test execution)
    - My workflow yml uses various strategies to test on OS, browsers and platforms. OS and browsers are configured via the strategy syntax and platfoms via Maven profiles 
    - Test Reporting. By default, Junit provides limited test reporting capability. Certainly, for client projects in regulated markets more transparency is necessary. The addition of
-customer reporting classes (DisplayNameReporter.class) or reporting frameworks, e.g. Allure, improve this greatly.
+3. Custom reporting classes (DisplayNameReporter.class) or reporting frameworks, e.g. Allure, improve this greatly.
+
+### Workflow Schedule
 
-#Note:
+[here](WorkflowSchedule.md)
+
+### Note:
 
 Caching is provided by actions/cache but, whilst useful, caches in the cloud. For project dependencies there is a valid usecase to cache in the cloud. OpenJDK packages 
 have proved very slow to sync onto a self-hosted runner and given the lack of need to constantly update, I have added the follow step to my workflow which checks 
@@ -78,24 +82,6 @@ for a local installation of (the correct version) of Java (bashrc version):
           restore-keys: |
             ${{ runner.os }}-java-
 
-
-
-
-### Backlog
-
-These are items I would like to explorer further as they will make useful contributions to my understanding of DevOps CICD:
-
-1. Create DORA metrics. Github Actions does not provide these out of the box (why not). Need to investigate what are freeware solutions to quickly expose these KPIs.
-
-2. Explore GitHub MarketPlace for more useful/interesting actions
-
-3. Integrate my Docker images into Kubernetes
-
 ### Limitations
 
-|   | Description                                              | Mitigation                                                        |
-|---|----------------------------------------------------------|-------------------------------------------------------------------|
-| 1 | Cannot run Safari tests on Linux                         | Webkit is supported                                               |
-| 2 | Browserstack eval license only supports Win/Chromium     | Buy license                                                       |
-| 3 | Matrix strategy auto-combines                            | Care must be taken that all target environments support the tests |
-| 4 | Installtion of Maven is not managed through the workflow | Can be managed in the same way as Java is managed                 |
+Listed [here](Limitations.md)
diff --git a/WorkflowSchedule.md b/WorkflowSchedule.md
@@ -0,0 +1,8 @@
+### Workflow execution schedule
+
+|   | Description               | Purpose                    | Branch               | Trigger |
+|---|---------------------------|----------------------------|----------------------|---------|
+| 1 | CICD_Main_Pipeline        | Main build & test workflow | master               | Push/PR |
+| 2 | CICD_Main_Pipeline-4Test  | Build & test workd         | Pipeline_Test_Branch | Push/PR |
+| 3 | ScheduledTask             | Dummy nightly build        | N/A                  | Cron [Sun-Thu 00:00] |
+