v0.2.7

What's New

Skip tarball transfer when remote already has matching hash

Optimizes deployments by comparing SHA256 hashes before transferring large tarballs:

• Hash computation: After saving a tarball, computes and stores SHA256 hash in dist/*.tar.gz.sha256
• Remote check: Before transfer, checks if remote /tmp/ already has a tarball with matching hash via SSH
• Smart skip: Skips tarball transfer if hashes match (template and env files still transferred)
• Validation: Validates hash format (64 hex chars) and handles SSH failures gracefully
• Cleanup: Hash files are cleaned up alongside old tarballs

Test suite

Added pytest test suite with 12 tests covering the hash comparison feature.

Files Changed

• src/deploy_kit/docker.py - Hash computation and storage
• src/deploy_kit/backends/compose.py - Remote hash check logic
• src/deploy_kit/scripts/ssh_check_hash.sh - New script for remote hash retrieval
• src/deploy_kit/scripts/ssh_transfer.sh - Conditional tarball transfer
• src/deploy_kit/scripts/__init__.py - Added run_script_capture() helper
• tests/test_hash_transfer.py - New test suite

v0.2.6

Fixes

• Fix gzip tarball output from docker.image.save
  • python-on-whales writes plain tar regardless of filename extension
  • Remote deploy script expects gzipped data (gunzip -c)
  • Now saves to .tar first, compresses with gzip module, removes intermediate file

v0.2.5

What's Changed

Breaking fix: Migrate from docker-py to python-on-whales for BuildKit support.

The docker-py SDK doesn't support BuildKit (docker/docker-py#2230), which breaks Dockerfiles using RUN --mount syntax (e.g., uv cache mounts).

python-on-whales wraps the Docker CLI directly, so BuildKit features work out of the box.

⚠️ v0.2.4 is defunct

Do not use v0.2.4 - it will fail on any Dockerfile with BuildKit syntax (RUN --mount).

Changes

• Replace docker dependency with python-on-whales
• Simplified build_image() and save_image() functions
• Added test fixtures for BuildKit validation

v0.2.4

What's Changed

Refactoring

• Replace Docker shell scripts with Python SDK - Uses docker-py directly instead of shelling out to docker_build.sh and docker_save.sh
• Better error handling with typed exceptions (BuildError, APIError, ImageNotFound)
• Streaming build output for visibility using logger.stream()
• Proper client cleanup with try/finally pattern

Features

• Make pyproject.toml optional - deploy-kit now works with any language by setting name in deploy-kit.toml
• Configuration precedence: deploy-kit.toml > pyproject.toml > defaults

Fixes

• Disable SSL verification for Portainer API client (supports self-signed certs)
• Code formatting improvements in CLI

Dependencies

• Added docker>=7.0.0

Full Changelog: v0.2.3...v0.2.4

v0.2.3 - Logger Bug Fix

Bug Fixes

• Critical: Fixed AttributeError: 'Logger' object has no attribute 'warning' that prevented deployment when no .env file was present
  • Changed logger.warning() to logger.warn() to match the actual Logger class method name in utils.py
  • This bug was discovered during comprehensive testing of the new-project-guide.md documentation

What Changed

• src/deploy_kit/sops.py: Corrected logger method call
• Version bumped to 0.2.3

Installation

# Global install
uv tool install --from git+https://github.com/mi-skam/deploy-kit deploy-kit

# Or upgrade existing install
uv tool uninstall deploy-kit
uv tool install --from git+https://github.com/mi-skam/deploy-kit deploy-kit

Full Changelog

Full Changelog: v0.2.0...v0.2.3

v0.2.2: Configuration File Support for Deployment Targets

🎉 What's New in v0.2.2

This release adds deploy-kit.toml configuration support for deployment targets, achieving full feature parity between environment variables and config files.

✨ New Features

• Configure SSH targets in deploy-kit.toml via ssh_target field
• Configure Portainer URLs in deploy-kit.toml via portainer_url field
• Full 4-layer precedence: CLI argument > Environment variable > Config file > Default

💡 Benefits

• Eliminate repetitive environment variables on every deployment
• Store deployment targets persistently in project configuration
• Override targets easily via env vars or CLI args when needed
• Streamlined workflow - just run deploy-kit up --compose and targets are read from config

📝 Example Configuration

# deploy-kit.toml
[deploy]
# Deployment targets
ssh_target = "user@production.example.com"
portainer_url = "https://portainer.example.com"

# Build configuration
architecture = "linux/amd64"  # Cross-compile for x86_64 from ARM Mac
port = 8001
healthcheck_path = "/health"
keep_tarballs = 5

🚀 Usage Examples

Before (v0.2.1):

DEPLOY_ARCH=linux/amd64 DEPLOY_PORT=8001 deploy-kit up --compose user@production.example.com

After (v0.2.2):

# Simple deployment - reads everything from config
deploy-kit up --compose

# Override specific values when needed
DEPLOY_PORT=8002 deploy-kit up --compose staging-server

🔒 Security Best Practices

• PORTAINER_API_KEY remains environment-variable-only (as it should!)
• Recommended: Store secrets in .env.sops (encrypted with SOPS)
• Deploy-kit automatically decrypts .env.sops during deployment
• Clear warnings in all documentation about never committing secrets to config files

📚 Documentation Updates

• README.md: Added config file examples to all usage sections
• Configuration precedence: Detailed explanation with real-world examples
• Getting Started Guides: Enhanced with deploy-kit.toml setup instructions
• Template file: Comprehensive documentation for new configuration options

🔧 Technical Changes

Files Modified (9 files, +112/-44 lines):

• src/deploy_kit/config.py - Add ssh_target and portainer_url fields to DeployConfig
• src/deploy_kit/cli.py - Update validation logic to check config file (4 locations)
• templates/config/deploy-kit.toml.example - Document new configuration options
• README.md - Usage examples and precedence documentation
• docs/existing-project-guide.md - Integration guide updates
• docs/new-project-guide.md - New project setup updates

Configuration Precedence Chain:

CLI argument (highest)
    ↓
Environment variable
    ↓
deploy-kit.toml  ← NEW!
    ↓
Built-in default (lowest)

✅ Backward Compatibility

No breaking changes! All existing workflows continue to work:

• ✅ CLI arguments still work
• ✅ Environment variables still work
• ✅ Projects without deploy-kit.toml still work
• ✅ Existing deploy-kit.toml files without new fields still work

📦 Installation

# Global install
uv tool install deploy-kit

# Or update existing installation
uv tool upgrade deploy-kit

# Or use as git submodule
git submodule add https://github.com/your-org/deploy-kit.git

🙏 Credits

🤖 Implemented with assistance from Claude Code

---

Full Changelog: https://github.com/your-org/deploy-kit/compare/v0.2.1...v0.2.2

v0.2.1: Type Safety Improvements

Type Safety Improvements

This release fixes type checking issues in the CLI using Python's TypeGuard feature.

What's Changed

Type System Enhancements:

• Fixed type inference for CLI parameters (ssh_target, portainer_url, portainer_key)
• Added is_non_empty_str() TypeGuard function to utils.py
• Improved compatibility with type checkers (mypy, pyright)
• Variables now properly narrowed from str | None to str after validation

Implementation Details:

• TypeGuard-based validation for explicit type narrowing
• Variables initialized at function scope with proper types
• Assertions in deployment blocks to satisfy type checkers
• Removed duplicate variable assignments

Code Quality:

• Code formatting improvements across multiple files
• Better type safety without runtime behavior changes
• Maintains fail-fast validation pattern

Technical Notes

The TypeGuard approach provides explicit type narrowing that works with advanced type checkers while maintaining the existing validation and error handling patterns. This is a non-breaking change that improves developer experience when using type checkers.

Release: 0.2.0 with up and down subcommands

Full Changelog: https://github.com/mi-skam/deploy-kit/commits/0.2.0