Contributing to EKS Helm Client GitHub Action

First off, thank you for considering contributing to the EKS Helm Client GitHub Action! It’s people like you that make this tool better for everyone in the community.

Table of Contents

Code of Conduct

This project and everyone participating in it is governed by our Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to dinushchathurya21@gmail.com.

Getting Started

Before you begin:

How Can I Contribute?

Reporting Bugs

Before creating bug reports, please check the existing issues as you might find out that you don’t need to create one. When you are creating a bug report, please include as many details as possible using the bug report template.

Great Bug Reports tend to have:

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion, including completely new features and minor improvements to existing functionality.

Before creating enhancement suggestions, please check the existing issues and discussions. When you are creating an enhancement suggestion, please include as many details as possible using the feature request template.

Great Enhancement Suggestions tend to have:

Your First Code Contribution

Unsure where to begin contributing? You can start by looking through these beginner and help-wanted issues:

Pull Requests

The process described here has several goals:

Please follow these steps to have your contribution considered by the maintainers:

  1. Follow all instructions in the template
  2. Follow the style guides
  3. After you submit your pull request, verify that all status checks are passing

Development Setup

  1. Fork and Clone the Repository 
    git clone https://github.com/your-username/eks-helm-client-github-action.git
cd eks-helm-client-github-action
  2. Create a Feature Branch 
    git checkout -b feature/your-feature-name
  3. Set Up Development Environment 
    # Make scripts executable
chmod +x scripts/*.sh
chmod +x .github/scripts/**/*.sh
   
# Install development dependencies (if any)
# Currently, this action uses Docker, so ensure Docker is installed
  4. Build the Docker Image 
    docker build -t eks-helm-client:dev .
  5. Run Tests 
    # Unit tests
./tests/unit/test-entrypoint.sh
./tests/unit/test-health-check.sh
./tests/unit/test-templates.sh
   
# Integration tests
./.github/scripts/testing/run-integration-tests.sh

Style Guides

Git Commit Messages

Example:

feat: add support for private Helm registries

- Add authentication for Harbor, Nexus, and Artifactory
- Support both basic auth and token-based auth
- Add comprehensive error handling for registry failures

Fixes #123

Bash Style Guide

We follow the Google Shell Style Guide with some modifications:

Key Points:

  1. Shebang 
    #!/bin/bash
  2. Error Handling 
    set -e  # Exit on error
set -u  # Exit on undefined variable (when appropriate)
set -o pipefail  # Fail on pipe errors
  3. Functions 
    # Good
function_name() {
    local var_name="$1"
    local another_var="${2:-default}"
       
    # Function body
    echo "Processing: $var_name"
}
   
# Usage
function_name "argument" "optional"
  4. Variables 
    # Constants (readonly)
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly DEFAULT_TIMEOUT=300
   
# Local variables
local file_path="/tmp/test"
   
# Global variables (avoid when possible)
GLOBAL_STATE="active"
  5. Conditionals 
    # Good
if [[ -n "${variable:-}" ]]; then
    echo "Variable is set"
fi
   
# Check file existence
if [[ -f "$file_path" ]]; then
    echo "File exists"
fi
  6. Logging 
    log_info() {
    echo -e "${BLUE}[INFO]${NC} $1" >&2
}
   
log_error() {
    echo -e "${RED}[ERROR]${NC} $1" >&2
}
  7. Error Messages 
    if [[ -z "${CLUSTER_NAME:-}" ]]; then
    log_error "CLUSTER_NAME is required"
    log_error "Please provide either:"
    log_error "  - Input parameter: cluster-name"
    log_error "  - Environment variable: CLUSTER_NAME"
    exit 1
fi

Documentation Style Guide

  1. Markdown Files
    • Use ATX-style headers (# not underlines)
    • Include a table of contents for long documents
    • Use code blocks with language specification
    • Include examples whenever possible
  2. Code Comments 
    # Function to configure EKS cluster access
# This function retrieves cluster information from AWS EKS API
# and generates a kubeconfig file for authentication
configure_eks_access() {
    # Implementation
}
  3. README Sections
    • Keep examples concise and realistic
    • Include both basic and advanced usage
    • Provide troubleshooting guidance

Testing

Running Tests Locally

  1. Unit Tests 
    # Run all unit tests
for test in tests/unit/test-*.sh; do
    bash "$test"
done
  2. Integration Tests 
    # Build the Docker image
docker build -t eks-helm-client:test .
   
# Run integration tests
./.github/scripts/testing/run-integration-tests.sh
  3. Manual Testing 
    # Test with dry run
docker run --rm \
  -e INPUT_CLUSTER_NAME="test-cluster" \
  -e INPUT_REGION="us-west-2" \
  -e INPUT_DRY_RUN="true" \
  -e INPUT_ARGS="helm list" \
  eks-helm-client:test

Writing Tests

When adding new features, please include:

  1. Unit tests for individual functions
  2. Integration tests for end-to-end scenarios
  3. Documentation with examples
  4. Error cases to ensure proper error handling

Example test structure:

#!/bin/bash
# tests/unit/test-new-feature.sh

source "$(dirname "$0")/../../.github/scripts/testing/utils.sh"

test_new_feature() {
    # Test implementation
    local result
    result=$(new_feature "input")
    
    if [[ "$result" == "expected" ]]; then
        log_test_result "PASS" "New feature test"
        return 0
    else
        log_test_result "FAIL" "New feature test" "Expected 'expected', got '$result'"
        return 1
    fi
}

# Run test
test_new_feature

Security

Security Considerations

  1. Never commit secrets or sensitive data
  2. Validate all inputs to prevent injection attacks
  3. Use secure defaults for all configurations
  4. Follow the principle of least privilege for IAM permissions
  5. Clean up sensitive data after use

Reporting Security Issues

Please DO NOT create public GitHub issues for security vulnerabilities. Instead, please report them directly to dinushchathurya21@gmail.com.

Community

Getting Help

Project Structure

eks-helm-client-github-action/
├── .github/              # GitHub-specific files
│   ├── workflows/        # CI/CD workflows
│   └── scripts/          # CI/CD scripts
├── docs/                 # Documentation
│   └── examples/         # Usage examples
├── scripts/              # Main action scripts
├── templates/            # Configuration templates
├── tests/                # Test files
│   ├── unit/            # Unit tests
│   └── integration/      # Integration tests
├── action.yml            # Action definition
├── Dockerfile            # Container definition
└── README.md            # Main documentation

Release Process

  1. Version Numbering: We use Semantic Versioning
  2. Release Branches: Create from main branch
  3. Testing: All tests must pass
  4. Documentation: Update CHANGELOG.md
  5. Tag: Create version tag (e.g., v2.1.0)

Recognition

Contributors will be recognized in:

Thank You!

Your contributions to open source make great things possible. Thank you for taking the time to contribute to the EKS Helm Client GitHub Action!

Made with ❤️ by the Open Source Sri Lanka community