Skip to content

Commit 9bc1209

Browse files
Vincent056Vincent056
committed
Initial commit with project structure, including Go module setup, Makefile for build and test automation, and implementation of input fetchers for filesystem and Kubernetes resources. Added test cases for fetchers and scanner interfaces, along with necessary dependencies in go.mod and go.sum. Also included .gitignore to exclude build artifacts and IDE-specific files.
1 parent 2f19857 commit 9bc1209

3,555 files changed

Lines changed: 1288185 additions & 0 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.gitignore‎

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
2+
3+
# Environment variables
4+
.env
5+
.env.local
6+
7+
# IDE specific files
8+
.idea/
9+
.vscode/
10+
*.swp
11+
*.swo
12+
*~
13+
.project
14+
.settings/
15+
16+
# OS specific files
17+
.DS_Store
18+
Thumbs.db
19+
20+
# Build artifacts
21+
bin/
22+
dist/
23+
build/
24+
25+
# Temporary files
26+
*.tmp
27+
*.temp
28+
*.log
29+
30+
# Test coverage files
31+
coverage.out
32+
coverage.html
33+
*.cover
34+
35+
# Example binaries
36+
examples/*/main
37+
examples/*/*/main
38+
39+

‎CHANGELOG.md‎

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# Changelog
2+
3+
All notable changes to the Compliance SDK will be documented in this file.
4+
5+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
6+
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
7+
8+
## [0.1.0] - 2025-01-20
9+
10+
### Initial Release
11+
12+
#### Features
13+
- **CEL Rule Engine**: Full support for Common Expression Language (CEL) for complex logical expressions
14+
- **Extensible Architecture**: Generic `Rule` interface designed to support multiple rule engines in the future
15+
- **Multiple Input Sources**:
16+
- Kubernetes resources with discovery and caching
17+
- File system resources with format parsing (JSON, YAML, text)
18+
- System services and processes
19+
- HTTP API endpoints
20+
- **Resource Fetching**:
21+
- Composite fetcher for unified resource retrieval
22+
- Concurrent resource fetching for performance
23+
- Support for pre-fetched resources (offline scanning)
24+
- **Builder Pattern**: Fluent API for constructing rules programmatically
25+
- **Rich Metadata**: Support for rule metadata and extensions for compliance reporting
26+
- **Comprehensive Testing**: Unit tests with mock implementations
27+
- **Documentation**: Complete API documentation and usage examples
28+
29+
#### Architecture
30+
- Generic `Rule` interface as the foundation for all rule types
31+
- `CelRule` interface extending `Rule` for CEL-specific functionality
32+
- Pluggable `InputFetcher` system for different resource types
33+
- Clean separation between rule definition, resource fetching, and evaluation
34+
35+
#### Future Rule Types (Planned)
36+
The architecture supports these rule types, with implementations planned for future releases:
37+
- **Rego**: For OPA (Open Policy Agent) policy language
38+
- **JSONPath**: For simple path-based validations
39+
- **Custom**: For user-defined rule implementations

‎CONTRIBUTING.md‎

Lines changed: 288 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,288 @@
1+
# Contributing to Compliance SDK
2+
3+
We welcome contributions to the Compliance SDK! This document provides guidelines for contributing to the project.
4+
5+
## Table of Contents
6+
7+
- [Code of Conduct](#code-of-conduct)
8+
- [Getting Started](#getting-started)
9+
- [Development Setup](#development-setup)
10+
- [Making Changes](#making-changes)
11+
- [Testing](#testing)
12+
- [Submitting Changes](#submitting-changes)
13+
- [Coding Standards](#coding-standards)
14+
- [Documentation](#documentation)
15+
16+
## Code of Conduct
17+
18+
This project follows the [Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/). By participating, you are expected to uphold this code.
19+
20+
## Getting Started
21+
22+
1. Fork the repository on GitHub
23+
2. Clone your fork locally:
24+
```bash
25+
git clone https://github.com/your-username/compliance-sdk.git
26+
cd compliance-sdk
27+
```
28+
3. Add the upstream repository as a remote:
29+
```bash
30+
git remote add upstream https://github.com/ComplianceAsCode/compliance-sdk.git
31+
```
32+
33+
## Development Setup
34+
35+
### Prerequisites
36+
37+
- Go 1.24.0 or higher
38+
- Make
39+
- golangci-lint (for linting)
40+
- Access to a Kubernetes cluster (for integration tests)
41+
42+
### Building the Project
43+
44+
```bash
45+
# Install dependencies
46+
go mod download
47+
48+
# Run tests
49+
make test
50+
51+
# Run linter
52+
make lint
53+
54+
# Format code
55+
make fmt
56+
```
57+
58+
## Making Changes
59+
60+
### Branch Naming
61+
62+
Use descriptive branch names:
63+
- `feature/add-jsonpath-scanner` - for new features
64+
- `fix/kubernetes-fetcher-panic` - for bug fixes
65+
- `docs/update-api-examples` - for documentation updates
66+
- `refactor/scanner-interface` - for refactoring
67+
68+
### Commit Messages
69+
70+
Follow the [Conventional Commits](https://www.conventionalcommits.org/) specification:
71+
72+
```
73+
type(scope): subject
74+
75+
body
76+
77+
footer
78+
```
79+
80+
Examples:
81+
```
82+
feat(scanner): add JSONPath rule engine support
83+
fix(fetcher): handle nil pointer in Kubernetes fetcher
84+
docs(api): update RuleBuilder examples
85+
refactor(interfaces): simplify Input interface hierarchy
86+
```
87+
88+
## Testing
89+
90+
### Unit Tests
91+
92+
- Write unit tests for all new functionality
93+
- Maintain or improve code coverage
94+
- Use table-driven tests where appropriate
95+
- Mock external dependencies
96+
97+
Example test structure:
98+
```go
99+
func TestFeatureName(t *testing.T) {
100+
tests := []struct {
101+
name string
102+
input someType
103+
expected expectedType
104+
wantErr bool
105+
}{
106+
{
107+
name: "valid input",
108+
input: validInput,
109+
expected: expectedOutput,
110+
wantErr: false,
111+
},
112+
// more test cases...
113+
}
114+
115+
for _, tt := range tests {
116+
t.Run(tt.name, func(t *testing.T) {
117+
// test implementation
118+
})
119+
}
120+
}
121+
```
122+
123+
### Integration Tests
124+
125+
- Place integration tests in `*_integration_test.go` files
126+
- Use build tags to separate integration tests: `// +build integration`
127+
- Document any external dependencies required
128+
129+
### Running Tests
130+
131+
```bash
132+
# Run unit tests
133+
make test
134+
135+
# Run tests with coverage
136+
make test-coverage
137+
138+
# Run integration tests (requires Kubernetes cluster)
139+
go test -tags=integration ./...
140+
```
141+
142+
## Submitting Changes
143+
144+
### Pull Request Process
145+
146+
1. Update your fork with the latest upstream changes:
147+
```bash
148+
git fetch upstream
149+
git checkout main
150+
git merge upstream/main
151+
```
152+
153+
2. Create a new branch from main:
154+
```bash
155+
git checkout -b feature/your-feature-name
156+
```
157+
158+
3. Make your changes and commit them
159+
160+
4. Push to your fork:
161+
```bash
162+
git push origin feature/your-feature-name
163+
```
164+
165+
5. Create a Pull Request on GitHub
166+
167+
### Pull Request Guidelines
168+
169+
- Provide a clear description of the changes
170+
- Reference any related issues
171+
- Include tests for new functionality
172+
- Update documentation as needed
173+
- Ensure all tests pass
174+
- Ensure code follows the project's style guidelines
175+
176+
### Pull Request Template
177+
178+
```markdown
179+
## Description
180+
Brief description of changes
181+
182+
## Type of Change
183+
- [ ] Bug fix
184+
- [ ] New feature
185+
- [ ] Breaking change
186+
- [ ] Documentation update
187+
188+
## Testing
189+
- [ ] Unit tests pass
190+
- [ ] Integration tests pass (if applicable)
191+
- [ ] Manual testing completed
192+
193+
## Checklist
194+
- [ ] Code follows project style guidelines
195+
- [ ] Self-review completed
196+
- [ ] Documentation updated
197+
- [ ] Tests added/updated
198+
- [ ] CHANGELOG.md updated (for significant changes)
199+
```
200+
201+
## Coding Standards
202+
203+
### Go Style
204+
205+
- Follow the [Effective Go](https://golang.org/doc/effective_go.html) guidelines
206+
- Use `gofmt` for formatting
207+
- Use `golangci-lint` for linting
208+
- Keep functions focused and small
209+
- Use meaningful variable and function names
210+
211+
### Interface Design
212+
213+
- Keep interfaces small and focused
214+
- Document all exported types and functions
215+
- Use interface segregation principle
216+
217+
### Error Handling
218+
219+
- Always handle errors explicitly
220+
- Wrap errors with context using `fmt.Errorf`
221+
- Use custom error types for specific error conditions
222+
- Never ignore errors (use `_` only when absolutely necessary)
223+
224+
Example:
225+
```go
226+
if err != nil {
227+
return fmt.Errorf("failed to fetch resources: %w", err)
228+
}
229+
```
230+
231+
### Logging
232+
233+
- Use the provided Logger interface
234+
- Log at appropriate levels (Debug, Info, Warn, Error)
235+
- Include context in log messages
236+
- Avoid logging sensitive information
237+
238+
## Documentation
239+
240+
### Code Documentation
241+
242+
- Document all exported types, functions, and methods
243+
- Use complete sentences starting with the name being declared
244+
- Include examples in documentation where helpful
245+
246+
Example:
247+
```go
248+
// RuleBuilder provides a fluent API for building compliance rules.
249+
// It supports method chaining for easy rule construction.
250+
type RuleBuilder struct {
251+
// ...
252+
}
253+
254+
// WithInput adds an input source to the rule being built.
255+
// The input will be available in the rule expression by its name.
256+
func (b *RuleBuilder) WithInput(input Input) *RuleBuilder {
257+
// ...
258+
}
259+
```
260+
261+
### Documentation Updates
262+
263+
When adding new features or changing APIs:
264+
1. Update the README.md if needed
265+
2. Update API.md with new interfaces/types
266+
3. Add examples to EXAMPLES.md
267+
4. Update CHANGELOG.md
268+
269+
## Adding New Scanner Types
270+
271+
When implementing support for a new scanner type (e.g., Rego, JSONPath):
272+
273+
1. The `RuleType` constants are already defined for future use
274+
2. Create implementation structs extending `BaseRule` (e.g., `JsonPathRuleImpl`)
275+
3. Add builder methods (e.g., `SetJsonPathExpression()`)
276+
4. Implement the scanner logic (e.g., `processJsonPathRule()`)
277+
5. Update the switch statement in `Scanner.Scan()` and `RuleBuilder.Build()`
278+
6. Add comprehensive tests
279+
7. Update documentation
280+
281+
## Questions?
282+
283+
If you have questions about contributing, please:
284+
1. Check existing issues and pull requests
285+
2. Review the documentation
286+
3. Open a new issue for discussion
287+
288+
Thank you for contributing to the Compliance SDK!

0 commit comments

Comments
 (0)