feat(common): Release v4.1.2 (#430)

Signed-off-by: Dan Manners <daniel.a.manners@gmail.com>
Co-authored-by: Daniel Manners <daniel.a.manners@gmail.com>

.github/instructions/chart-testing.instructions.md

@@ -0,0 +1,50 @@
+# Chart Testing Instructions
+
+Testing is a critical part of chart development to ensure reliability and compatibility.
+
+## Testing Structure
+
+- `charts/library/common/test-chart/`: Contains a test chart for validating the common library
+- `charts/library/common/test-chart/unittests/`: Contains unit tests for different resource types
+- `charts/library/common/test-chart/ci/`: Contains CI test values
+
+## Testing Tools
+
+This repository uses:
+
+1. **Helm lint**: For syntax validation
+2. **Schema validation**: For values validation
+3. **Unit tests**: For template functionality validation
+
+## Testing Guidelines
+
+### Running Tests Locally
+
+To run tests locally:
+
+1. `task charts:lint`: Run linting on all charts
+2. `task charts:test`: Run chart tests
+
+### Adding New Tests
+
+When adding new features, always add corresponding tests:
+
+1. For new resource types, add unit tests in the appropriate directory
+2. For new value options, add test cases that exercise those options
+3. For edge cases, add specific test values to validate behavior
+
+### Testing Best Practices
+
+1. Test both valid and invalid configurations
+2. Test resource generation with different combinations of values
+3. Test template functions with various inputs
+4. Test backward compatibility when making changes
+
+### Testing with Real Applications
+
+Beyond automated tests, it's valuable to test with real applications:
+
+1. Deploy sample applications using the app-template chart
+2. Verify that all resources are created correctly
+3. Test the application functionality
+4. Test upgrades from previous versions to ensure compatibility

.github/instructions/common-library.instructions.md

@@ -0,0 +1,56 @@
+# Common Library Development Instructions
+
+The `common` library chart is the foundation of this repository. It provides reusable templates and functions for Kubernetes resource generation.
+
+## Structure
+
+- `templates/classes/`: Contains template definitions for various Kubernetes resources
+- `templates/lib/`: Contains library functions used across templates
+- `templates/loader/`: Contains code for loading and initializing templates
+- `templates/render/`: Contains code for rendering resources
+- `templates/values/`: Contains code for value validation
+- `schemas/`: JSON schemas for validating values
+
+## Key Concepts
+
+1. **Template Classes**: These are blueprint templates for Kubernetes resources like Deployments, Services, etc.
+2. **Library Functions**: Helper functions that can be used across templates
+3. **Values Schema**: JSON schema definitions for validating chart values
+
+## Development Guidelines
+
+### Adding New Features
+
+When adding new features to the common library:
+
+1. Determine which resource type(s) the feature applies to
+2. Add appropriate parameters to the values schema
+3. Update the relevant template class(es)
+4. Update documentation as needed
+5. Increment the chart version in `Chart.yaml` following semver principles
+
+### Modifying Existing Features
+
+When modifying existing features:
+
+1. Ensure backward compatibility or document breaking changes
+2. Update the relevant template class(es)
+3. Update the values schema if needed
+4. Update documentation
+5. Increment the chart version appropriately
+
+### Testing Changes
+
+After making changes:
+
+1. Run `task charts:lint` to validate chart syntax
+2. Run `task charts:test` to run chart tests
+3. Deploy a test chart using the library to verify functionality
+
+### Common Library Best Practices
+
+1. Keep template functions focused and reusable
+2. Use clear naming conventions for functions and parameters
+3. Document function parameters and behavior
+4. Maintain backward compatibility where possible
+5. Update version numbers in accordance with semver principles

.github/instructions/documentation.instructions.md

@@ -0,0 +1,242 @@
+# Documentation Instructions
+
+Good documentation is essential for this project as it helps users understand how to use the charts effectively.
+
+## Documentation Structure
+
+- `docs/`: Main documentation directory
+  - `index.md`: Home page (includes README.md content)
+  - `app-template/`: Documentation for the app-template chart
+    - `index.md`: Overview of the app-template chart
+    - `upgrade-instructions.md`: Instructions for upgrading between major versions
+    - `examples/`: Example configurations for the app-template
+    - `howto/`: Guides for specific tasks with the app-template
+  - `common-library/`: Documentation for the common library chart
+    - `index.md`: Overview of the common library chart
+    - `howto/`: Guides for specific tasks with the common library
+    - `resources/`: Documentation for specific resource types
+    - `storage/`: Documentation for storage options
+  - `overrides/`: Custom MkDocs template overrides
+  - `requirements.txt`: Python dependencies for building the documentation
+
+## Documentation Tools
+
+This repository uses:
+
+1. **MkDocs**: For generating the documentation site
+2. **Material for MkDocs**: For styling and enhanced features
+3. **PyMdown Extensions**: For extended markdown capabilities
+4. **README.md.gotmpl**: Template files for generating README files
+5. **mkdocs-minify-plugin**: For minifying the generated HTML
+
+## Documentation Guidelines
+
+### Writing Documentation
+
+When documenting charts and features:
+
+1. Use clear, concise language
+2. Provide examples for common use cases
+3. Document all available options and their default values
+4. Include diagrams or screenshots where helpful
+5. Link to relevant external documentation
+
+### Markdown Formatting
+
+All documentation should use consistent Markdown formatting:
+
+1. **Headers**: Use proper hierarchy (H1 → H2 → H3)
+   ```markdown
+   # Page Title (H1)
+   ## Section (H2)
+   ### Subsection (H3)
+   ```
+
+2. **Code Blocks**: Use fenced code blocks with language specification
+   ```markdown
+   ```yaml
+   controllers:
+     main:
+       containers:
+         main:
+           image:
+             repository: ghcr.io/example/app
+             tag: latest
+   ```
+   ```
+
+3. **File Inclusions**: Use the `--8<--` syntax to include files
+   ```markdown
+   --8<--
+   examples/helm/vaultwarden/values.yaml
+   --8<--
+   ```
+
+4. **Admonitions**: Use admonition blocks for notes, warnings, etc.
+   ```markdown
+   !!! note
+       This is a note admonition.
+
+   !!! warning
+       This is a warning admonition.
+   ```
+
+5. **Line Numbers**: Use line numbers for longer code blocks
+   ```markdown
+   ```yaml linenums="1"
+   # Code with line numbers
+   ```
+   ```
+
+6. **Annotations**: Use annotations to highlight specific parts of code
+   ```markdown
+   ```yaml
+   image:
+     repository: nginx # (1)!
+     tag: latest
+   ```
+
+   1. This is an annotation explaining the repository value
+   ```
+
+### Chart Documentation
+
+Each chart should have at minimum:
+
+1. **Overview**: Brief description of the chart's purpose
+2. **Background**: Context or reasoning behind the chart
+3. **Usage**: Instructions for using the chart
+4. **Examples**: Practical examples with configurations
+5. **Source code**: Link to the chart's source code
+
+### Updating Documentation
+
+When making changes to charts:
+
+1. Update the corresponding documentation files
+2. Update examples if the change affects how users would use the chart
+3. Document breaking changes prominently
+4. Add upgrade instructions for major version changes
+5. Ensure cross-references between docs remain valid
+
+### Version-Specific Documentation
+
+For version-specific features or changes:
+
+1. Clearly indicate the version where the feature was introduced
+2. Use admonitions to highlight version requirements
+   ```markdown
+   !!! info "Version requirement"
+       This feature is available in version 4.0.0 and later.
+   ```
+3. For major version changes, update `upgrade-instructions.md` with migration steps
+4. Use version comparison conditionals when appropriate
+
+### Serving Documentation Locally
+
+To preview documentation locally:
+
+1. Run `task docs:serve`
+2. Open a browser to the URL displayed in the terminal (typically http://localhost:8000)
+3. Make changes to documentation files and see live updates
+
+### Building the Documentation
+
+To build the documentation for production:
+
+1. Run `task docs:build`
+2. The static site will be generated in the `site/` directory
+
+### Documentation Best Practices
+
+1. Keep documentation up to date with code changes
+2. Use consistent formatting and style
+3. Organize content in a logical hierarchy
+4. Include both basic and advanced usage examples
+5. Document common gotchas and troubleshooting tips
+6. Use code blocks with syntax highlighting for examples
+7. Add explanatory comments within code examples
+8. Link to related documentation sections
+
+## Folder-Specific Documentation
+
+### App Template Documentation
+
+For the app-template chart, ensure documentation covers:
+
+1. How to use the chart for basic applications
+2. Common customization patterns
+3. Examples for popular applications
+4. Integration with different environments (Flux, Kustomize, etc.)
+5. Upgrade paths between major versions
+
+### Common Library Documentation
+
+For the common library, documentation should focus on:
+
+1. Available templates and functions
+2. How to use each resource type
+3. Advanced configuration options
+4. Best practices for extending or customizing
+
+## Example Templates
+
+### Basic Chart Example
+
+```markdown
+# Chart Name
+
+## Background
+
+Brief explanation of what this chart does and why it exists.
+
+## Usage
+
+Instructions on how to use this chart, including:
+
+```yaml
+# Example values.yaml
+controllers:
+  main:
+    containers:
+      main:
+        image:
+          repository: nginx
+          tag: latest
+```
+
+## Source code
+
+The source code for this chart can be found [here](link/to/chart).
+```
+
+### How-To Guide Template
+
+```markdown
+# How to Accomplish X
+
+This guide explains how to accomplish X using the chart.
+
+## Prerequisites
+
+- List prerequisites
+- Required knowledge
+
+## Steps
+
+1. First step with explanation
+2. Second step with explanation
+   ```yaml
+   # Example configuration
+   ```
+3. Third step with explanation
+
+## Examples
+
+Provide complete examples
+
+## See Also
+
+- [Related guide](link/to/related)
+- [External resource](link/to/external)
+```

.github/instructions/examples.instructions.md

@@ -0,0 +1,46 @@
+# Example Development Instructions
+
+Examples are crucial for helping users understand how to use the charts in real-world scenarios.
+
+## Example Structure
+
+- `examples/`: Main examples directory
+  - `helm/`: Examples for using charts with plain Helm
+  - `flux/`: Examples for using charts with Flux CD
+  - `kustomize/`: Examples for using charts with Kustomize
+
+## Example Guidelines
+
+### Creating New Examples
+
+When creating new examples:
+
+1. Choose realistic applications that demonstrate chart capabilities
+2. Structure examples clearly with comments explaining key configuration options
+3. Include all necessary files for the deployment method
+4. Add a README.md explaining the purpose and usage of the example
+
+### Updating Examples
+
+When updating chart features:
+
+1. Update relevant examples to demonstrate the new features
+2. Ensure examples continue to work with the latest chart versions
+3. Document any breaking changes that would affect existing users
+
+### Example Best Practices
+
+1. Keep examples simple enough to understand but comprehensive enough to be useful
+2. Include comments that explain why certain configuration options are chosen
+3. Demonstrate both basic and advanced usage patterns
+4. Include examples for different types of applications (stateless, stateful, etc.)
+5. Show integration with common tools and platforms (Flux, Kustomize, etc.)
+
+### Testing Examples
+
+Before committing examples:
+
+1. Deploy the example in a test environment
+2. Verify that all resources are created correctly
+3. Test the functionality of the deployed application
+4. Ensure the example is compatible with the latest chart version

.github/instructions/project-purpose.instructions.md

@@ -0,0 +1,118 @@
+# Project Purpose and Goals
+
+This document outlines the core purpose, design philosophy, and goals of the helm-charts repository.
+
+## Core Purpose
+
+The helm-charts repository provides a standardized approach to Kubernetes application deployment through a reusable library chart pattern. It follows the DRY (Don't Repeat Yourself) principle for Helm charting, recognizing that many applications require similar Kubernetes resources with only slight variations.
+
+## Design Philosophy
+
+The repository is built around these key principles:
+
+### 1. Abstraction through Library Charts
+
+Helm's [library charts](https://helm.sh/docs/topics/library_charts/) allow for sharing chart primitives across multiple charts. This repository leverages this concept by:
+
+- Centralizing common templates and functions in a single library chart
+- Providing consistent interfaces for resource generation
+- Exposing a simplified API for application deployment
+
+### 2. Configuration over Code
+
+Rather than requiring users to write custom templates for each application, this repository:
+
+- Provides a declarative configuration approach
+- Uses values.yaml for defining application requirements
+- Generates appropriate Kubernetes resources based on configuration
+
+### 3. Convention over Configuration
+
+The charts implement sensible defaults while allowing for customization:
+
+- Standard resource naming conventions
+- Common label patterns
+- Predictable resource relationships
+- Escape hatches for advanced scenarios
+
+## Repository Goals
+
+The helm-charts repository aims to:
+
+### 1. Standardization
+
+Create a consistent approach to defining Kubernetes resources by:
+- Establishing uniform resource naming
+- Applying common labeling patterns
+- Maintaining consistent relationship patterns between resources
+- Providing standardized validation through JSON schemas
+
+### 2. Reusability
+
+Avoid duplicating code across multiple Helm charts by:
+- Centralizing template logic in a common library
+- Sharing helper functions across different resource types
+- Creating reusable patterns for common deployment scenarios
+- Building composable components
+
+### 3. Simplicity
+
+Make it easier to deploy applications to Kubernetes by:
+- Reducing boilerplate configuration
+- Providing intuitive defaults
+- Creating a streamlined interface for common scenarios
+- Minimizing the learning curve for users
+
+### 4. Flexibility
+
+Support a wide range of application types and deployment scenarios through:
+- Extensible templates that handle various application requirements
+- Support for different Kubernetes resource types
+- Configurability through values files
+- Escape hatches for complex use cases
+
+### 5. Maintainability
+
+Centralize common functionality to simplify updates and fixes by:
+- Consolidating resource generation logic
+- Standardizing validation
+- Using shared templates for common patterns
+- Implementing consistent testing approaches
+
+## Components and Their Purpose
+
+### Common Library Chart
+
+The `common` library chart (`charts/library/common/`) is the foundation of the repository, providing:
+
+- **Template Classes**: Blueprint templates for Kubernetes resources like Deployments, Services, etc.
+- **Library Functions**: Helper functions that simplify resource generation
+- **Value Validation**: JSON schemas that validate chart values
+- **Resource Rendering**: Logic for rendering various Kubernetes resources
+
+### App Template Chart
+
+The `app-template` chart (`charts/other/app-template/`) is a companion chart that:
+
+- Leverages the common library to provide a turnkey solution for application deployment
+- Offers a consistent interface for deploying various applications
+- Reduces the barrier to entry for deploying applications on Kubernetes
+- Provides a reference implementation of the common library
+
+## Use Cases
+
+The helm-charts repository is designed for:
+
+1. **Application Deployment**: Simplifying the process of deploying applications on Kubernetes
+2. **GitOps Workflows**: Supporting declarative configuration for GitOps tools like Flux
+3. **Standardized Operations**: Enabling consistent operational patterns across applications
+4. **Learning and Reference**: Providing examples of Helm best practices and patterns
+
+## Related Documentation
+
+The helm-charts repository contains several types of documentation to help users and contributors understand and use the charts effectively. The documentation covers aspects such as:
+
+- **Common Library Development**: Details on modifying or extending the common library chart
+- **App Template Development**: Guidance for working with the app-template chart
+- **Documentation Guidelines**: Instructions for maintaining repository documentation
+- **Examples**: Information about example configurations and use cases

.github/instructions/versioning.instructions.md

@@ -0,0 +1,55 @@
+# Version Management Instructions
+
+Proper versioning is critical for maintaining compatibility and communicating changes to users.
+
+## Versioning Principles
+
+This repository follows [Semantic Versioning (SemVer)](https://semver.org/):
+
+1. **MAJOR**: Incompatible API changes
+2. **MINOR**: Functionality added in a backward compatible manner
+3. **PATCH**: Backward compatible bug fixes
+
+## Version Management Guidelines
+
+### When to Increment Versions
+
+- **MAJOR**: When making breaking changes like:
+  - Removing or renaming values
+  - Changing default behavior significantly
+  - Requiring a newer Kubernetes version
+
+- **MINOR**: When adding new features like:
+  - New resource types
+  - New configuration options
+  - Extended functionality
+
+- **PATCH**: When making non-breaking fixes like:
+  - Bug fixes
+  - Documentation updates
+  - Optimization improvements
+
+### Chart Dependencies
+
+When updating chart dependencies:
+
+1. Update the dependency version in `Chart.yaml`
+2. Update the chart's own version appropriately
+3. Document the change and any implications
+
+### Release Notes
+
+For each version change:
+
+1. Document what changed
+2. Highlight any breaking changes
+3. Provide upgrade instructions if needed
+4. Tag the repository with the new version
+
+### Version Management Best Practices
+
+1. Always increment versions for any chart changes
+2. Be conservative in MAJOR version increments
+3. Document breaking changes thoroughly
+4. Provide upgrade paths for users on older versions
+5. Test upgrades from previous versions to ensure compatibility