### Set Up Local Development Environment with Task

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Commands to initialize the local development environment. These tasks install all necessary dependencies and configure the project for development using `task`.

```bash
task dev:setup-environment
```

```bash
task dev:up
```

--------------------------------

### Execute Specific DevSecOps Pipeline Stages with Task

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Commands to run individual stages of the DevSecOps pipeline, allowing for focused development and testing. Examples include `plan`, `code`, `build`, and `test` stages.

```bash
task plan       # Initial planning
task code       # Development and checks
task build      # Build with security checks
task test       # Run tests
# ... other stages
```

--------------------------------

### Clone The DevSecOps Plugin Repository

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Instructions to clone the project repository from GitLab and navigate into its root directory. This is the first step to begin local development and contribution.

```bash
git clone https://gitlab.com/digital-commons/devsecops/tools/the-devsecops-plugin.git
cd the-devsecops-plugin
```

--------------------------------

### Setup DevSecOps Plugin Development Environment

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Run this command to set up the necessary development environment for the DevSecOps plugin, including dependencies and initial configurations required for local development.

```bash
task dev:setup-environment
```

--------------------------------

### Kubectl Command Example for Environment-Specific Deployment

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Illustrates how to apply a Kubernetes manifest using a specific kubeconfig file for a given environment, ensuring environment isolation and proper authentication for kubectl commands.

```Shell
kubectl --kubeconfig=iac/environment/staging/kubeconfig.yaml apply -f manifest.yaml
```

--------------------------------

### Create and Activate Python Virtual Environment

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Sets up a new Python virtual environment in the user's workspace directory and then activates it, isolating project dependencies and ensuring a clean installation environment.

```bash
mkdir -p ~/workspace
python3 -m venv ~/workspace/venv
```

--------------------------------

### Run Full Project Test Suite

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Executes the complete test suite for the project. All tests must pass before submitting changes, and adherence to Test-Driven Development (TDD) principles is mandatory.

```bash
task test
```

--------------------------------

### Standard Test Directory Structure

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Defines the recommended directory structure for organizing tests within the project, categorizing them into unit, integration, and end-to-end tests.

```text
tests/
├── unit/         # Unit tests
├── integration/  # Integration tests
└── e2e/          # End-to-end tests
```

--------------------------------

### Install Copier in Virtual Environment

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Activates the previously created Python virtual environment and installs the 'copier' package using pip. Copier is a crucial tool for project templating and scaffolding within the DevSecOps Plugin workflow.

```bash
source ~/workspace/venv/bin/activate
pip install copier
```

--------------------------------

### Commit Changes Using Commitizen Tool

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Command to commit your changes using Commitizen. This tool guides you through creating commit messages that comply with the Conventional Commits standard, ensuring consistency.

```bash
task commitizen
```

--------------------------------

### Run Complete DevSecOps Pipeline Locally

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Executes the entire DevSecOps pipeline locally using the `task` runner. This command orchestrates all stages, including security checks and builds, and may take time on the initial run.

```bash
task devsecops
```

--------------------------------

### Install Task Runner for Plugin Operations

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Install the Task runner, a powerful task automation tool essential for the plugin's operation control, by executing the provided shell script. Task manages all plugin-related commands and workflows.

```bash
sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d
```

--------------------------------

### DevSecOps Plugin Project Architecture Overview

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

This snippet illustrates the modular file structure of the DevSecOps plugin, detailing the organization of configuration files, development environment setup, and project-specific task definitions. It highlights how custom tasks can extend base functionality.

```bash
.
├── .config/                  # Tool configurations
│   ├── bun/                 # Bun runtime config
│   ├── commitizen/          # Commit message config
│   ├── devsecops/          # Pipeline stage definitions
│   │   ├── Taskfile.plan.yml
│   │   ├── Taskfile.code.yml
│   │   ├── Taskfile.build.yml
│   │   └── ...
│   ├── docker/             # Docker configuration
│   └── megalinter/         # Linting configuration
├── .devcontainer/          # Dev container setup
├── project/                # Project-specific tasks
│   └── Taskfile.yml       # Custom task definitions
└── Taskfile.yml           # Main task orchestration
```

--------------------------------

### Test-Driven Development (TDD) Cycle Steps

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Illustrates the three core steps of the Test-Driven Development (TDD) cycle, emphasizing the commit types associated with each phase: writing a failing test, implementing minimal code to pass, and refactoring.

```text
🔴 1. Write a Failing Test First
    commit type: test(scope): add failing test for new feature

🟢 2. Write Minimal Code to Pass
    commit type: feat(scope): implement minimal solution to pass test

🔵 3. Refactor While Keeping Tests Green
    commit type: refactor(scope): improve implementation while maintaining test
```

--------------------------------

### YAML Structure for DevOps Testing Phases

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML snippet illustrates the detailed breakdown of testing sub-phases within the 'Test' phase of the DevOps lifecycle. It outlines a comprehensive sequence from dependency installation and infrastructure provisioning to test execution, idempotence checks, and final cleanup, ensuring thorough validation.

```YAML
├── dependency   (Install tools)
├── cleanup      (Remove artefacts)
├── destroy      (Teardown infrastructure)
├── syntax       (Linting)
├── create       (Provision infrastructure)
├── prepare      (Configure testing environment)
├── converge     (Execute tests)
├── idempotence  (Re-run tests)
├── side_effect  (Simulate disruptions)
├── verify       (Ensure stability)
├── cleanup      (Additional cleanup)
└── destroy      (Final teardown)
```

--------------------------------

### Run Specific Test Types with Task

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Command to run specific categories of tests, such as only the TDD (Test-Driven Development) tests. This allows for targeted testing during development.

```bash
task test:tdd      # TDD tests only
```

--------------------------------

### Full Lifecycle Test Sequence for DevSecOps Plugin

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Defines the comprehensive default test execution flow for the DevSecOps plugin, including dependency installation, cleanup, infrastructure teardown, linting, infrastructure provisioning, preparation, test execution, idempotence checks, side-effect simulation, verification, and final cleanup.

```YAML
Full lifecycle sequence:
└── default
    ├── dependency    (Install necessary tools, etc.)
    ├── cleanup       (Remove temporary files and artefacts.)
    ├── destroy       (Teardown infrastructure.)
    ├── syntax        (Perform basic linting.)
    ├── create        (Provision infrastructure on Kubernetes.)
    ├── prepare       (Configure or install the minimum required for testing.)
    ├── converge      (Execute tests.)
    ├── idempotence   (Re-run tests; no changes should occur.)
    ├── side_effect   (Simulate a side effect, for example, disrupt a master node.)
    ├── verify        (Ensure the system remains stable post side-effect.)
    ├── destroy       (Teardown infrastructure.)
    └── cleanup       (Perform additional cleanup.)
```

--------------------------------

### Stage, Commit, and Push Changes to Remote

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Sequence of Git commands to prepare and submit your changes. This involves staging all modifications, committing them using Commitizen, and pushing the branch to the remote repository, ready for a Merge/Pull Request.

```bash
git add .
task commitizen
git push -u origin your-branch-name
```

--------------------------------

### TDD Lifecycle Test Sequence for DevSecOps Plugin

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Outlines the streamlined Test-Driven Development (TDD) specific test execution flow for the DevSecOps plugin, covering dependency installation, linting, infrastructure provisioning, preparation, test execution, side-effect simulation, and verification.

```YAML
TDD lifecycle sequence:
└── default
    ├── dependency    (Install necessary tools, etc.)
    ├── syntax        (Perform basic linting.)
    ├── create        (Provision infrastructure on Kubernetes.)
    ├── prepare       (Configure or install the minimum required for testing.)
    ├── converge      (Execute tests.)
    ├── side_effect   (Simulate a side effect, for example, disrupt a master node.)
    └── verify        (Ensure the system remains stable post side-effect.)
```

--------------------------------

### Create a New Feature or Fix Branch

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Command to create a new local branch for your changes. Branch names should follow specific conventions like `feature/feature-name` or `fix/fix-name` to categorize changes.

```bash
git checkout -b your-branch-name
```

--------------------------------

### Task Variable Override Pattern Example

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML snippet illustrates the pattern for allowing Task variables to be overridden via environment variables. It emphasizes providing sensible default values and using the 'default' function for consistency.

```yaml
vars:
    TASK_PLAN_ENABLED: "{{ default "true" .TASK_PLAN_ENABLED }}"
    TASK_CODE_ENABLED: "{{ default "true" .TASK_CODE_ENABLED }}"
    TASK_BUILD_ENABLED: "{{ default "false" .TASK_BUILD_ENABLED }}"
```

--------------------------------

### Define Taskfile for MailHog TDD Workflow and Cluster Management

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This `Taskfile.yml` defines the core tasks for managing the development and testing lifecycle, specifically for integrating MailHog using Test-Driven Development. It includes environment variable definitions, a comprehensive `test` task for full cycle testing, a `test:tdd` task for focused TDD, and individual tasks for dependency installation, Kind cluster management (creation, destruction), Helm chart deployment, syntax linting, and MailHog verification.

```yaml
---
version: "3"

vars:
  ENVIRONMENT: development
  KUBE_CONFIG: '{{.ROOT_DIR}}/iac/environment/{{.ENVIRONMENT}}/kubeconfig.yaml'
  ROOT_DIR:
    sh: pwd
  HELM_CHART_DIR: '{{.ROOT_DIR}}/iac/helm/mailhog'

tasks:
  test:
    cmds:
    - task: test:dependency
    - task: test:cleanup
    - task: test:destroy
    - task: test:syntax
    - task: test:create
    - task: test:prepare
    - task: test:converge
    - task: test:idempotence
    - task: test:side_effect
    - task: test:verify
    - task: test:cleanup
    - task: test:destroy

  test:tdd:
    cmds:
    - task: test:dependency
    - task: test:syntax
    - task: test:create
    - task: test:prepare
    - task: test:converge
    - task: test:side_effect
    - task: test:verify

  test:verify:
    desc: Verify MailHog deployment and functionality
    cmds:
    - ./tests/verify/mailhog.sh {{.KUBE_CONFIG}}

  test:converge:
    desc: Deploy and initialise MailHog utilising Helm
    cmds:
    - helm upgrade --install mailhog {{.HELM_CHART_DIR}} --wait --kubeconfig={{.KUBE_CONFIG}}

  test:create:
    desc: Initialise Kind cluster for testing
    cmds:
    - mkdir -p iac/environment/{{.ENVIRONMENT}}
    - kind create cluster --name mailhog-test --kubeconfig={{.KUBE_CONFIG}}

  test:destroy:
    desc: Finalise and remove Kind cluster
    cmds:
    - kind delete cluster --name mailhog-test
    - rm -f {{.KUBE_CONFIG}}

  test:dependency:
    desc: Install and initialise required tools
    cmds:
    - command -v kubectl >/dev/null 2>&1 || curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
    - command -v kind >/dev/null 2>&1 || go install sigs.k8s.io/kind@latest
    - command -v helm >/dev/null 2>&1 || curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

  test:syntax:
    desc: Analyse Helm chart syntax
    cmds:
    - helm lint {{.HELM_CHART_DIR}}
```

--------------------------------

### Root Taskfile Configuration: DevOps Phase Enablement

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML example illustrates how the root Taskfile uses variables like TASK_DEVSECOPS_PLAN_ENABLED to control which DevOps phases are active. These variables can be overridden, defaulting to 'true' unless specified otherwise.

```yaml
TASK_DEVSECOPS_PLAN_ENABLED: '{{.TASK_PLAN_ENABLED | default "true"}}'
TASK_DEVSECOPS_CODE_ENABLED: '{{.TASK_CODE_ENABLED | default "true"}}'
# ... other phase toggles
```

--------------------------------

### Standard Commit Message Format (Conventional Commits)

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/CONTRIBUTING.md

Defines the required commit message format for the project, adhering to Conventional Commits specifications. This structure includes a type, optional scope, and a concise description, with optional body and footer.

```text
<type>(<scope>): <description>

[optional body]

[optional footer(s)]
```

--------------------------------

### Task Variable Naming Convention Example

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML snippet demonstrates the standardized naming convention for Task variables: SCREAMING_SNAKE_CASE, prefixed with TASK_, and suffixed with _ENABLED for feature flags. It also shows the use of 'default' for initial values.

```yaml
vars:
  TASK_COMPONENT_ENABLED: "{{ default "true" .TASK_COMPONENT_ENABLED }}"
```

--------------------------------

### Create DevSecOps Release

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Initiate the release process for the project by running this command, which handles versioning, tagging, and other release-related tasks defined within the DevSecOps pipeline.

```bash
task devsecops:release
```

--------------------------------

### Verify MailHog Services and Prepare Test Script

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This snippet demonstrates initial verification steps for MailHog's SMTP and Web UI ports using `netcat` and `curl`. It also includes commands to make the verification script executable and commit the initial test task structure to Git.

```bash
echo "Verifying SMTP port..."
nc -zv localhost 1025 || exit 1

echo "Verifying Web UI..."
curl -sf http://localhost:8025 || exit 1

echo "Sending test email..."
echo "Subject: Test" | curl --mail-from test@example.com --mail-rcpt recipient@example.com smtp://localhost:1025 || exit 1

echo "All verifications completed successfully"
EOF

chmod +x tests/verify/mailhog.sh
```

```git
git add project/Taskfile.yml tests/verify/mailhog.sh
git commit -m "test: add test tasks structure for MailHog deployment"
```

--------------------------------

### YAML Configuration for Project Taskfiles

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML snippet defines a typical structure for a Taskfile, showcasing how to declare version, global variables (like ENVIRONMENT, KUBECONFIG, HELM_CHART_DIR), and define tasks. It demonstrates the use of Go template syntax for variable defaults and dynamic path construction.

```YAML
version: '3'
vars:
  ENVIRONMENT: '{{.ENVIRONMENT | default "development"}}'
  KUBECONFIG: 'iac/environment/{{.ENVIRONMENT}}/kubeconfig.yaml'
  HELM_CHART_DIR: 'iac/helm/{{.CHART_NAME}}'

tasks:
  test:
    cmds: [...]
  test:tdd:
    cmds: [...]
```

--------------------------------

### Implement Minimal MailHog Helm Chart

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This snippet outlines the creation of a basic Helm chart for MailHog, including `values.yaml` for image and port configuration, and `deployment.yaml` to define the Kubernetes deployment and service. It also includes commands to run tests and commit the new chart.

```bash
# Create basic Helm chart
mkdir -p iac/helm/mailhog/templates
cat > iac/helm/mailhog/values.yaml << EOF
# Utilise formal British English for all comments
image: mailhog/mailhog:latest
smtp:
  port: 1025
webui:
  port: 8025
EOF

# Create deployment and service
cat > iac/helm/mailhog/templates/deployment.yaml << EOF
# Utilise formal British English for all comments
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mailhog
spec:
  selector:
    matchLabels:
      app: mailhog
  template:
    metadata:
      labels:
        app: mailhog
    spec:
      containers:
    - name: mailhog
        image: {{ .Values.image }}
        ports:
      - containerPort: {{ .Values.smtp.port }}
      - containerPort: {{ .Values.webui.port }}
EOF

# Run the test again - it should pass now
task test:tdd

# Verify the complete test cycle
task test
```

```git
git add iac/helm/mailhog/
git commit -m "feat: implement minimal MailHog Helm chart"
```

--------------------------------

### Mandatory DevOps Phases Order

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This section specifies the mandatory, strict order of the eight DevOps phases that structure the repository: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor. It emphasizes that no phase may be skipped or executed out of sequence without explicit justification and approval.

```txt
1. Plan
2. Code
3. Build
4. Test
5. Release
6. Deploy
7. Operate
8. Monitor
```

--------------------------------

### Generate New Project using DevSecOps Plugin Template

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Navigates to the target project directory, activates the virtual environment, and uses Copier to generate a new project based on the DevSecOps Plugin Gitlab template. The `.config/devsecops/.copier-answers.yml` file is used for automated answers during the project generation process.

```bash
cd ~/workspace/path/to/your/new/project

source ~/workspace/venv/bin/activate
copier copy -a .config/devsecops/.copier-answers.yml https://gitlab.com/digital-commons/devsecops/tools/the-devsecops-plugin.git .
```

--------------------------------

### YAML: Standard Environment Directory Structure

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Defines the required directory structure for infrastructure-as-code environments, separating configurations for development, staging, and production with dedicated kubeconfig and Helm values files.

```yaml
iac/
└── environment/
    ├── development/
    │   ├── kubeconfig.yaml    # Development cluster configuration
    │   └── values.yaml        # Environment-specific Helm values
    ├── staging/
    │   ├── kubeconfig.yaml    # Staging cluster configuration
    │   └── values.yaml        # Environment-specific Helm values
    └── production/
        ├── kubeconfig.yaml    # Production cluster configuration
        └── values.yaml        # Production-specific Helm values
```

--------------------------------

### Root Taskfile Configuration: Includes Section

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML snippet demonstrates how the main Taskfile.yml includes other specialized Taskfiles, such as those for specific DevOps phases (e.g., plan, code) and the project-specific Taskfile, enabling modularity and organization.

```yaml
includes:
    devsecops:plan:
      taskfile: .config/devsecops/Taskfile.plan.yml
    devsecops:code:
      taskfile: .config/devsecops/Taskfile.code.yml
    # ... other DevOps phases
    project:
      taskfile: project/Taskfile.yml
```

--------------------------------

### Bash: Kind Local Cluster with Specific Kubeconfig

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Provides commands for creating a `kind` local Kubernetes cluster and performing operations against it, explicitly using an environment-specific kubeconfig file for consistency with other environments.

```bash
# Create cluster with specific kubeconfig
kind create cluster --name dev --kubeconfig iac/environment/development/kubeconfig.yaml

# Use the environment-specific kubeconfig for all operations
kubectl --kubeconfig=iac/environment/development/kubeconfig.yaml apply -f manifest.yaml
```

--------------------------------

### View DevSecOps Plugin Project Structure

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Illustrates the directory layout of the DevSecOps Plugin project, showing where tool-specific configurations, development container settings, source code, and the main Task runner configuration file are located.

```bash
.
├── .config/           # Tool-specific configurations
│   ├── bun/          # Bun package manager configuration
│   ├── commitizen/   # Commit message standardisation
│   ├── devsecops/   # DevSecOps pipeline stages
│   ├── docker-ce/   # Docker configuration
│   └── ...          # Other tool configurations
├── .devcontainer/    # Development container configuration
├── src/             # Source code
└── Taskfile.yml     # Task runner configuration
```

--------------------------------

### Execute Complete DevSecOps Pipeline and Individual Stages

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Run the complete DevSecOps pipeline or execute specific stages like `plan`, `code`, `build`, `test`, `release`, `deploy`, `operate`, `monitor`, and `feedback` using the `task` command for granular control over the pipeline execution.

```bash
# Run the complete DevSecOps pipeline
task

# Run individual stages
task plan       # Initial planning
task code       # Development and checks
task build      # Build and security
task test       # Run tests
task release    # Handle releases
task deploy     # Deployment
task operate    # Operations
task monitor    # Monitoring
task feedback   # Feedback loop
```

--------------------------------

### YAML: Taskfile Variables for Environment-Specific Helm Deployments

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Illustrates a comprehensive `Taskfile.yml` configuration using environment-specific variables for `KUBECONFIG`, `HELM_VALUES`, and `HELM_CHART_DIR` to manage Helm deployments across different environments.

```yaml
version: '3'
vars:
  ENVIRONMENT: '{{.ENVIRONMENT | default "development"}}'
  KUBECONFIG: 'iac/environment/{{.ENVIRONMENT}}/kubeconfig.yaml'
  HELM_VALUES: 'iac/environment/{{.ENVIRONMENT}}/values.yaml'
  HELM_CHART_DIR: 'iac/helm/{{.CHART_NAME}}'

tasks:
  deploy:
    desc: Deploy to the specified environment
    cmds:
      - helm upgrade --install {{.RELEASE_NAME}} {{.HELM_CHART_DIR}}
        --values {{.HELM_VALUES}}
        --kubeconfig {{.KUBECONFIG}}
```

--------------------------------

### Taskfile Structure Overview Diagram

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

A visual representation of how the root Taskfile (Taskfile.yml) orchestrates operations by including project-specific tasks (project/Taskfile.yml) and various DevOps phase configurations (.config/devsecops/*.yml) and development tools (.config/tools/*.yml).

```mermaid
graph TD
    A[Taskfile.yml] --> B[project/Taskfile.yml]
    A --> C[.config/devsecops/*.yml]
    A --> D[.config/tools/*.yml]

    subgraph "Root Taskfile"
        A
    end

    subgraph "Project-Specific Tasks"
        B
    end

    subgraph "DevOps Phases"
        C1[Taskfile.plan.yml]
        C2[Taskfile.code.yml]
        C3[Taskfile.build.yml]
        C4[Taskfile.test.yml]
        C5[Taskfile.release.yml]
        C6[Taskfile.deploy.yml]
        C7[Taskfile.operate.yml]
        C8[Taskfile.monitor.yml]
        C9[Taskfile.feedback.yml]
        C --> C1 & C2 & C3 & C4 & C5 & C6 & C7 & C8 & C9
    end

    subgraph "Development Tools"
        D1[bun]
        D2[commitizen]
        D3[commitlint]
        D4[copier]
        D5[dev]
        D6[docker-ce]
        D7[kaniko]
        D8[lizard]
        D9[megalinter]
        D10[nodejs]
        D11[podman]
        D12[yamllint]
        D --> D1 & D2 & D3 & D4 & D5 & D6 & D7 & D8 & D9 & D10 & D11 & D12
    end
```

--------------------------------

### Refactor MailHog Helm Chart with Best Practices

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This snippet demonstrates refactoring the MailHog Helm chart by enhancing `values.yaml` to include resource limits (memory requests and limits) and enable ingress for the Web UI. It also includes commands to re-run tests and commit the refactored code.

```bash
# Enhance the Helm chart with best practices
cat > iac/helm/mailhog/values.yaml << EOF
image: mailhog/mailhog:latest
resources:
  limits:
    memory: 256Mi
  requests:
    memory: 128Mi
smtp:
  port: 1025
  metrics: true
webui:
  port: 8025
  ingress:
    enabled: true
EOF

# Verify refactoring didn't break anything
task test
```

```git
git add iac/helm/mailhog/values.yaml
git commit -m "refactor: enhance MailHog chart with resource management and metrics"
```

--------------------------------

### Run Complete DevSecOps Pipeline Locally

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Execute the entire DevSecOps pipeline locally using the `task devsecops` command to perform all defined stages and checks, simulating a full CI/CD run on your development machine.

```bash
task devsecops
```

--------------------------------

### Standard Universal DevOps Repository Directory Structure

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML snippet illustrates the mandatory, standardised directory structure for the universal DevOps code repository template. It ensures consistency, facilitates automation, and simplifies maintenance across all projects. Key directories include 'iac/' for Infrastructure-as-Code, '.config/' for technology-specific configurations, 'tests/' for all test types, and 'project/Taskfile.yml' for DevOps tasks.

```yaml
/
├── iac/
│   ├── helm/
│   ├── opentofu/
│   └── environment/
│       └── staging/
├── .config/
│   ├── nodejs/
│   └── megalinter/
├── tests/
│   ├── unit/
│   ├── integration/
│   └── e2e/
├── project/
│   └── Taskfile.yml
└── Taskfile.yml
```

--------------------------------

### Mandatory Test-Driven Development (TDD) Workflow

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This section details the mandatory Test-Driven Development (TDD) workflow, which requires every feature, fix, or change to begin with a failing test. It outlines the three core steps: writing a failing test, writing minimal code to pass, and refactoring while keeping tests green, along with the corresponding conventional commit types.

```txt
🔴 1. Write a Failing Test First
    commit type: test(scope): add failing test for new feature

🟢 2. Write Minimal Code to Pass
    commit type: feat(scope): implement minimal solution to pass test

🔵 3. Refactor While Keeping Tests Green
    commit type: refactor(scope): improve implementation while maintaining test
```

--------------------------------

### Clone DevSecOps Plugin Repository

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Clone the DevSecOps plugin repository from GitLab to your local machine using Git to begin contributing or setting up your development environment.

```bash
git clone https://gitlab.gitlab.com/digital-commons/devsecops/tools/the-devsecops-plugin.git
cd the-devsecops-plugin
```

--------------------------------

### Create and Verify MailHog Deployment Script

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This Bash script, `mailhog.sh`, is designed to verify the successful deployment and readiness of the MailHog application within a Kubernetes cluster. It takes the `kubeconfig` path as an argument and waits for the MailHog pod to reach a ready state, ensuring the service is operational for testing.

```bash
#!/bin/bash
# Verify MailHog deployment and functionality
# Arguments:
#   $1: Path to kubeconfig file

set -e

# Ensure kubeconfig is provided
if [ -z "$1" ]; then
    echo "Error: kubeconfig path is required"
    exit 1
fi

KUBECONFIG="$1"

# Wait for pod to be ready
kubectl --kubeconfig="$KUBECONFIG" wait --for=condition=ready pod -l app=mailhog --timeout=60s
```

--------------------------------

### Project-Specific Taskfile: DevOps Phase Definitions

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This YAML snippet from project/Taskfile.yml shows how project-specific tasks are defined for each DevOps phase (e.g., plan, code). These tasks contain simple, focused implementations relevant to the particular project.

```yaml
tasks:
    plan:
      desc: Run project-specific plan tasks
    code:
      desc: Run project-specific code tasks
    # ... other phase tasks
```

--------------------------------

### Standard DevOps Repository Structure

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This snippet illustrates the recommended directory structure for a DevOps-centric code repository. It defines logical separation for Infrastructure as Code (IaC), configurations, tests, and task definitions, promoting consistency and maintainability across projects.

```yaml
/
├── iac/
│   ├── helm/           (Helm charts)
│   ├── opentofu/       (Infrastructure as Code)
│   └── environment/    (Environment-specific configurations)
│       └── staging/
├── .config/
│   ├── nodejs/         (Node.js configurations)
│   └── megalinter/     (Linter configurations)
├── tests/
│   └── infrastructure/ (Infrastructure tests)
│       └── verify/         (Verification scripts)
├── project/
│   └── Taskfile.yml    (Task definitions)
└── Taskfile.yml       (Task definitions)
```

--------------------------------

### Run Specific DevSecOps Tools

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Directly invoke individual tools integrated with the plugin, such as MegaLinter for comprehensive code quality and security analysis, Commitizen for standardized commit management, or Lizard for code complexity analysis.

```bash
task megalinter         # Code quality & security
task commitizen         # Manage commits
task docker-ce:test     # Docker tests
task lizard             # Code complexity analysis
task commitlint         # Commit message validation
```

--------------------------------

### Mandatory Double Verification Principle

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

This section describes the mandatory Double Verification Principle, a critical safety measure for all significant actions, especially those involving system modifications or deletions. It outlines a two-step process: initial verification and secondary verification, emphasizing the importance of thorough checks to prevent errors and ensure data integrity.

```txt
✅ Double Verification Process:
1. Initial Verification
   - Validate the intended action
   - Check all parameters and conditions
   - Verify the context and impact

2. Secondary Verification
   - Re-validate with fresh perspective
   - Cross-check against documentation
   - Confirm all dependencies are considered
```

--------------------------------

### YAML: Define Kubeconfig Path in Taskfile

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Shows how to define dynamic `KUBECONFIG` and `ENVIRONMENT` variables within a `project/Taskfile.yml` to ensure Kubernetes operations use the correct environment-specific configuration.

```yaml
vars:
  ENVIRONMENT: '{{.ENVIRONMENT | default "development"}}'
  KUBECONFIG: 'iac/environment/{{.ENVIRONMENT}}/kubeconfig.yaml'
```

--------------------------------

### Run Code Quality and Security Checks

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Execute this command to perform code quality and security checks as part of the DevSecOps pipeline's code stage, ensuring code adheres to defined standards and is free of common vulnerabilities.

```bash
task devsecops:code
```

--------------------------------

### Configure Plugin Environment Variables

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

To customize the DevSecOps plugin's behavior, copy the `.env.dist` template file to `.env` and edit it with your preferred settings. This ensures that Task automatically loads your configurations for local development.

```bash
cp .env.dist .env
# Edit .env with your preferred settings
```

--------------------------------

### YAML: Use Kubeconfig Variable in Taskfile Commands

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Demonstrates how to integrate the defined `KUBECONFIG` variable into Kubernetes-related tasks within a `Taskfile.yml`, ensuring all deployments and operations are environment-aware.

```yaml
tasks:
  deploy:
    cmds:
      - kubectl --kubeconfig={{.KUBECONFIG}} apply -f {{.MANIFEST}}
```

--------------------------------

### Fixing MegaLinter CSpell Configuration

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

This command provides a quick fix for MegaLinter CSpell configuration issues by copying the generated configuration file to the project's local configuration directory. This helps synchronize CSpell settings and resolve spelling check errors.

```bash
cp megalinter-reports/.config/cspell/config.json .config/cspell/config.json
```

--------------------------------

### GitLab CI/CD Environment Variables Reference

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

These environment variables are crucial for the DevSecOps plugin's operation within a GitLab CI/CD pipeline and must be securely configured in your GitLab CI/CD settings for proper functionality, especially for release processes.

```APIDOC
CZ_DEPLOY_KEY: Base64 encoded SSH private key for git operations (required for releases)
GITLAB_USER_LOGIN: Your GitLab username (automatically provided)
GITLAB_USER_EMAIL: Your GitLab email (automatically provided)
```

--------------------------------

### Customize Project Tasks with Taskfile.yml

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/README.md

Projects can define their own tasks in `project/Taskfile.yml` to integrate custom commands into the DevSecOps lifecycle stages. This allows for project-specific planning, code checks, build processes, and other custom steps.

```yaml
tasks:
  plan:
    desc: Run project-specific plan tasks
    cmds:
      - custom-planning-command

  code:
    desc: Run project-specific code tasks
    cmds:
      - npm test
      - custom-linting

  build:
    desc: Run project-specific build tasks
    cmds:
      - docker build -t myproject .

  # ... other stages (test, release, deploy, operate, monitor, feedback)
```

--------------------------------

### Bash: Explicit Kubernetes Kubeconfig Usage

Source: https://github.com/thomassanson/the-devsecops-plugin/blob/main/docs/guidelines/DevSecOps.md

Illustrates two methods for explicitly specifying the kubeconfig file when executing `kubectl` commands: using the `--kubeconfig` flag or setting the `KUBECONFIG` environment variable. This ensures operations target the correct cluster.

```bash
# Option 1: --kubeconfig flag
kubectl --kubeconfig=iac/environment/staging/kubeconfig.yaml get pods

# Option 2: KUBECONFIG environment variable
export KUBECONFIG=iac/environment/staging/kubeconfig.yaml
kubectl get pods
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.