Updated website. TODO: deployment page

Author: wvmillen

docs/A_using_verviz.md

@@ -1,32 +1,32 @@
-# All about Deployment
-
-Veriviz utilizes [UNC Cloud Apps](https://cloudapps.unc.edu/) to host and deploy the service. UNC Cloud Apps runs on OKD(OpenShift Kubernetes Distribution). 
-
-## What is Kubernetes?
-
-ON a high level, Kubernetes is a service that allows your application to be run in a virtual enviroment with its own operating system. You can think of it as what a container is to Docker on your local machine, that's essentially what a pod is on a Kubernetes deployment. This is defined by a Dockerfile in your project which OKD uses to create your pod and which your code is processed in run on.
-
-## How does deploying on Kubvernetes work
-
-The OKD Deployment process works as follow:
-
-1. Being notified of CI successfully passing all tests on main and receiving a webhook callback
-2. A BuildConfig begins a new Build by pulling repository and building a Docker image
-3. The Docker image is pushed to an ImageStream
-4. The ImageStream notifies a Deployment that a new image is available
-5. The Deployment spins up a new Pod (Container) based on the image
-6. Once the new Pod is available, it turns off the old Pod running the previous version
-
-*Credit to Kris Jordan and his [website](https://comp423-25s.github.io/resources/backend-architecture/3-ci-cd/#why-cicd-matters) for this information*
-
-## Continous Inegration, Continous Deployment
-
-CI/CD(Continous Integration/Continous Deployment) refers to the automatied process of re-deploying a service when new changes are made. 
-
-- **Continous Integration** refers to the process of verifying tests are passed ebfore deployment. So for example, after a commit to main is made, Tests you write will be automatically run on your new code. If these tests pass, great! they will now be handed over to continous deployement and if not, your project will not be re-deployed and you will have to iterate on your code until they pass.
-
-- The second step of CI/CD **Continous Deployment**. This referrs to the process of automitcally redploying your service to reflect the changes you made to it. In a full CI/CD pipeline, once your project has passed the tests, it is then deployed. 
-
-**In Veriviz**, **Continous Integration** is **NOT** used. This meand once new changes are refelected in the main branch, it will be redployed to OKD, rebuilt, and up and running. There are no tests to verify your work. This can be added in the future but is not nessarily needed. What this means in a nutshell is, when you make changes to the verviz repo or any of the other services such as SEIF or Sylvia, the changes will automitically be reflected in the service with no need for manual deployment but also, no tests will verify what you did is correct. Don't worry though, if your code results in a failed deployment, OKD will revert to the last built pod and the service will still run on the old code.
-
-
+# All about Deployment
+
+Veriviz utilizes [UNC Cloud Apps](https://cloudapps.unc.edu/) to host and deploy the service. UNC Cloud Apps runs on OKD(OpenShift Kubernetes Distribution). 
+
+## What is Kubernetes?
+
+ON a high level, Kubernetes is a service that allows your application to be run in a virtual enviroment with its own operating system. You can think of it as what a container is to Docker on your local machine, that's essentially what a pod is on a Kubernetes deployment. This is defined by a Dockerfile in your project which OKD uses to create your pod and which your code is processed in run on.
+
+## How does deploying on Kubvernetes work
+
+The OKD Deployment process works as follow:
+
+1. Being notified of CI successfully passing all tests on main and receiving a webhook callback
+2. A BuildConfig begins a new Build by pulling repository and building a Docker image
+3. The Docker image is pushed to an ImageStream
+4. The ImageStream notifies a Deployment that a new image is available
+5. The Deployment spins up a new Pod (Container) based on the image
+6. Once the new Pod is available, it turns off the old Pod running the previous version
+
+*Credit to Kris Jordan and his [website](https://comp423-25s.github.io/resources/backend-architecture/3-ci-cd/#why-cicd-matters) for this information*
+
+## Continous Inegration, Continous Deployment
+
+CI/CD(Continous Integration/Continous Deployment) refers to the automatied process of re-deploying a service when new changes are made. 
+
+- **Continous Integration** refers to the process of verifying tests are passed ebfore deployment. So for example, after a commit to main is made, Tests you write will be automatically run on your new code. If these tests pass, great! they will now be handed over to continous deployement and if not, your project will not be re-deployed and you will have to iterate on your code until they pass.
+
+- The second step of CI/CD **Continous Deployment**. This referrs to the process of automitcally redploying your service to reflect the changes you made to it. In a full CI/CD pipeline, once your project has passed the tests, it is then deployed. 
+
+**In Veriviz**, **Continous Integration** is **NOT** used. This meand once new changes are refelected in the main branch, it will be redployed to OKD, rebuilt, and up and running. There are no tests to verify your work. This can be added in the future but is not nessarily needed. What this means in a nutshell is, when you make changes to the verviz repo or any of the other services such as SEIF or Sylvia, the changes will automitically be reflected in the service with no need for manual deployment but also, no tests will verify what you did is correct. Don't worry though, if your code results in a failed deployment, OKD will revert to the last built pod and the service will still run on the old code.
+
+

docs/B_veriviz.md

@@ -1,50 +1,50 @@
-# How to Deploy
-
-## Setting up CD for a service
-
-In the root of your project, set up a `.github/workflows` directory and make a file called `cicd.yml` result in a full path of `ROOT/.github/workflows/cicd.yml`
-
- ### "What is cicd.yml"
-
-This file tells github a few things. We have not gotten to secrets yet but we will soon. IN a nutshell, a secret is seomthing we will give to our OKD deployment and define in our Github Repo.
-- The `.github/workflow` directory is a special directory that when github sees, it knows to look in here for rules for CD
-- ```
-on:
-  push:
-    branches: [ main ]
-  pull_request:
-    branches: [ main ]
-```
-Tells github to send our secret to OKD on a push to` main`(commit) or a pull request to `main`. We will later define this in our deployment but for now this is all you need to know
-
-
-Below is an example from verviz of the `cicd.yml` file. As you can see `.yml` files are very human readable and easy to follow.
-``` { .yaml .copy}
-name: NAME-OF-YOUR-PROJECT-HERE
-
-on:
-  push:
-    branches: [ main ]
-  pull_request:
-    branches: [ main ]
-
-jobs:
-  cd-frontend:
-    name: "Continuous Deployment - Veriviz"
-    runs-on: ubuntu-latest
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Trigger OKD Build for Veriviz
-        run: |
-          curl -X POST ${{ secrets.CD_BUILD_WEBHOOK_FRONTEND}}
-  cd-backend:
-    name: "Continuous Deployment - Backend"
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - name: Trigger OKD Build for Veriviz Backend
-        run: |
-          curl -X POST ${{ secrets.CD_BUILD_WEBHOOK_VERIVIZ_BACKEND }}
+# How to Deploy
+
+## Setting up CD for a service
+
+In the root of your project, set up a `.github/workflows` directory and make a file called `cicd.yml` result in a full path of `ROOT/.github/workflows/cicd.yml`
+
+ ### "What is cicd.yml"
+
+This file tells github a few things. We have not gotten to secrets yet but we will soon. IN a nutshell, a secret is seomthing we will give to our OKD deployment and define in our Github Repo.
+- The `.github/workflow` directory is a special directory that when github sees, it knows to look in here for rules for CD
+- ```
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+```
+Tells github to send our secret to OKD on a push to` main`(commit) or a pull request to `main`. We will later define this in our deployment but for now this is all you need to know
+
+
+Below is an example from verviz of the `cicd.yml` file. As you can see `.yml` files are very human readable and easy to follow.
+``` { .yaml .copy}
+name: NAME-OF-YOUR-PROJECT-HERE
+
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+
+jobs:
+  cd-frontend:
+    name: "Continuous Deployment - Veriviz"
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Trigger OKD Build for Veriviz
+        run: |
+          curl -X POST ${{ secrets.CD_BUILD_WEBHOOK_FRONTEND}}
+  cd-backend:
+    name: "Continuous Deployment - Backend"
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Trigger OKD Build for Veriviz Backend
+        run: |
+          curl -X POST ${{ secrets.CD_BUILD_WEBHOOK_VERIVIZ_BACKEND }}
 ```

docs/C_sylvia.md

@@ -0,0 +1,57 @@
+# Contributing
+
+## Contributing to the Verviz Website
+
+### Getting Started
+
+1. **Fork and Clone**: Fork the Veriviz repository and/or clone it locally.
+2. **Devcontainer Setup**: For a consistent development environment, check out [using devcontainers](devcontainers.md).
+3. **Create a Branch**: Work on your feature or bug fix in a new branch, e.g., `git checkout -b feature/amazing-feature`.
+4. **Test and Verify**: Ensure everything runs locally before opening a PR.  
+   - If you’d like to deploy changes or see how deployment works, see [How to Deploy](how_to_deploy.md).
+!!! note "Cloning Sylvia and/or SEIF"
+    While not neseary, it is recommended to run things locally to test the full pipeline and your new code works. To tests the entirerty of the pipeline, it is recommended to clone Sylvia and/or SEIF to run these locally as well. Check out below for how to run these locally.
+
+### Running on your local machine
+
+#### Running Veriviz
+
+1. `cd frontend`
+2. Run `npm install` to verify everything is installed
+3. Run `npm run dev`. Now the frontend is up and running on localhost.
+4. `cd ../backend`
+5. Run `npm install` to verify everything is installed
+6. Run `node server.js`. Now the backend is up and running on localhost.
+
+#### Running Sylvia
+
+1. 
+
+
+## MkDocs and Contributing to Verviz Docs
+
+### What is MkDocs?
+
+**MkDocs** is a static site generator built for project documentation. 
+It uses Markdown files for content and a single `mkdocs.yml` for config. Read more about mkdocs on their [offical documentation website](https://www.mkdocs.org/).
+
+### Contributing to Verviz Docs
+
+1. **Fork or clone** the Veriviz documentation.
+2. `ctrl + shft + p`( `cmd + shft + p` on mac) and select `reopen in devcontainer. For more information or if not working see [using devcontainers](devcontainers.md)
+
+Now automatically, when you commit remotely to the main branch or sucesfully pull request, the website will automatically deploy and reflect your changes. Below are some common tasks that will help you get started.
+
+### Common Tasks
+
+- **Add a new doc**: create `new_topic.md` in `docs/` and link it in `mkdocs.yml`. 
+- **Preview changes**: run `mkdocs serve` to check them locally.
+- **Publish**: push to `main` if the pipeline is set to deploy.
+!!! note "On `mkdocs.yml"
+    The `mkdocs.yml` file defines configuration for the mkdocs site in a human readable format. To add your new file to the view of the website, look in the `mkdocs.yml` file, look for the `nav` section and and your file with a relative path. For example, if i craeted `hello.md` in `/docs/intros/hello.md`, in the `nav` section i would include:
+    ```
+    nav:
+        - intros:
+            - NAME HERE(ex. Hello): intros/hello.md
+    ```
+

docs/D_seif.md

@@ -1,61 +1,70 @@
-# What are Devcontainers and why are they useful?
-
-A Devcontainer utilizes Docker to create a virtual environment while developing your project. For example, I can specify a Dev container to run an Ubuntu Linux environment with python installed and no matter which machine I want to work on the project with(ie. windows, mac, etc.), I will have a consistent enviroment throughout. 
-
-A Dev Container ensures your development environment is consistent and works with whatever machine may be running it. It makes collabration easy and saves a lot of time. It's best practice and in short it solves the issue of "but it works on my machine". Additionally, we want to use the **OKD CLI**, which is incredibly easy and consistent to have form a devcontainer, but complicated and issue prone to dowload on your own machine
-
-## Using DevContainers
-
-As you will see in Veriviz, there is a predefined devcontainer. Running it is the most important thing but if you would like to learn more and how to create one, read the `Creating a Devcontainer` section below.
-
-!!! note "Prerequisties"
-    - **Docker** is strictly nesseary to run a devcontainer and needs to be dowloaded. Check out [here](https://www.docker.com/products/docker-desktop/) for download information(The free version is recommended). 
-    - **VsCode** is highly recommended. This tutorial will assume you are using VsCode and using any other code editor for a devcontainer will require your own research.
-    - The **Dev Containers Extension in VsCode** is needed as well
-
-### Re-opening in a devcontainer
-
-Reopening the project in a dev container can be done with `Ctrl+Shift+P`(or `Cmd+Shift+P` on Mac) and typing "Dev Containers: Reopen in Container" and selecting that option. It's that simple!
-
-!!! note "Pop-Up"
-    You also may see a pop up in VSCode on the bottom right hand side of your screen roughly stating **"Would you like to reopen this project in a dev container?"** which you can **click yes to to achieve the same result.**
-
-## Creating a Devcontainer
-
-As outlined earlier a devcontainer is extremly useful for collaboration and just a good qualit yof life thing to have for a repo.
-
-1. In VS Code, open your project via its root directory
-2. Install Dev Containers extension in VS Code
-3.  create a ```.devcontainer``` directory in the root of your project which is the `rust-intro` directory we just made
-```{.yaml .copy}
-mkdir .devcontainer
-```
-This tells the VsCode devcontainers extension there is a devcontainer and it will know to look here
-4. Use VS Code and create a file named ```devcontainer.json``` inside of the ```.devcontainer``` directory. This is where you will define what your devcontainer's skeleton. Look below for an example for a basic `Rust` container.
-
-``` { .yaml .copy}
-{
-    "name": "Rust Intro",
-    "image": "mcr.microsoft.com/devcontainers/rust:latest",
-    "customizations": {
-        "vscode":{
-            "settings": {},
-            "extensions":["rust-lang.rust-analyzer"]
-        }
-    },    
-    "postCreateCommand": "",
-}
-```
-Here's what everything does
-
-* **```name:```** This is what your dev container will be named
-
-- **```image:```** The docker image to use, in this case we will be using a preconfigured image for rust by microsoft
-
-- **```customizations:```** Adds configurations like VS Code extensions ensuring other developers have them too. ```rust-lang.rust-analyzer``` is the standard language server for rust development in vs code.
-
-- **```postCreateCommand:```** A command to run after the container is created. In our case, we don't include anything but you could create a seperate file with a bash command to run and link it here. When the container is built, that command will be run!
-
-Et Voila, it is done. IN case you wanted to use a custom image form a Dockerfile of your own, no problem, just make the dockerfile and include the path in the json. See [here](https://code.visualstudio.com/docs/devcontainers/containers) for some more documentation on devcontainers.
-
-
+# What are Devcontainers and why are they useful?
+
+A **Devcontainer** uses Docker to create a virtual environment while developing your 
+project. For example, you can run an Ubuntu environment with Python installed, and 
+no matter which machine (Windows, macOS, or Linux) you use, you’ll have a **consistent 
+setup**.
+
+**Benefits**:
+- Avoid "it works on my machine" issues.
+- Simplify collaboration.
+- Effortlessly include tools (like the **OKD CLI**) without manual installs.
+
+## Using DevContainers
+
+As you will see in Veriviz, there is a predefined devcontainer. Running it is the most important thing but if you would like to learn more and how to create one, read the `Creating a Devcontainer` section below.
+
+!!! note "Prerequisties"
+    - **Docker** is strictly nesseary to run a devcontainer and needs to be dowloaded. Check out [here](https://www.docker.com/products/docker-desktop/) for download information(The free version is recommended). 
+    - **VsCode** is highly recommended. This tutorial will assume you are using VsCode and using any other code editor for a devcontainer will require your own research.
+    - The **Dev Containers Extension in VsCode** is needed as well
+
+### Re-opening in a devcontainer
+
+1. Press **Ctrl+Shift+P** (or **Cmd+Shift+P** on Mac) in VS Code.
+2. Choose **"Dev Containers: Reopen in Container"**.
+3. VS Code reopens in your dev environment automatically.
+
+!!! note
+    Sometimes, VS Code prompts **"Reopen folder to develop in a container?"**.
+    Clicking **"Reopen"** achienves the same result.
+
+## Creating a Devcontainer
+
+As outlined earlier a devcontainer is extremly useful for collaboration and just a good quality of life thing to have for a repo. Below is an **Example** devcontainer steup for Rust that is **not used in verviz** but just her eto provide an example of how to set up a devcontainer.
+
+1. In VS Code, open your project via its root directory
+2. Install Dev Containers extension in VS Code
+3.  create a ```.devcontainer``` directory in the root of your project which is the `rust-intro` directory we just made
+```{.yaml .copy}
+mkdir .devcontainer
+```
+This tells the VsCode devcontainers extension there is a devcontainer and it will know to look here
+4. Use VS Code and create a file named ```devcontainer.json``` inside of the ```.devcontainer``` directory. This is where you will define what your devcontainer's skeleton. Look below for an example for a basic `Rust` container.
+
+``` { .yaml .copy}
+{
+    "name": "Rust Intro",
+    "image": "mcr.microsoft.com/devcontainers/rust:latest",
+    "customizations": {
+        "vscode":{
+            "settings": {},
+            "extensions":["rust-lang.rust-analyzer"]
+        }
+    },    
+    "postCreateCommand": "",
+}
+```
+Here's what everything does
+
+* **```name:```** This is what your dev container will be named
+
+- **```image:```** The docker image to use, in this case we will be using a preconfigured image for rust by microsoft
+
+- **```customizations:```** Adds configurations like VS Code extensions ensuring other developers have them too. ```rust-lang.rust-analyzer``` is the standard language server for rust development in vs code.
+
+- **```postCreateCommand:```** An optional script to run on container creation
+
+For more info, see [VS Code’s Devcontainers docs](https://code.visualstudio.com/docs/devcontainers/containers).
+
+