Fixing tests

.github/workflows/ci.yml

@@ -47,22 +47,22 @@ jobs:
         name: codecov-umbrella
 
   lint:
-    name: Lint
-    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        go: [stable]
+        os: [ubuntu-latest, macos-latest, windows-latest]
+    name: lint
+    runs-on: ${{ matrix.os }}
     steps:
-    - name: Checkout code
-      uses: actions/checkout@v4
+      - uses: actions/checkout@v5
+      - uses: actions/setup-go@v6
+        with:
+          go-version: ${{ matrix.go }}
+      - name: golangci-lint
+        uses: golangci/golangci-lint-action@v8
+        with:
+          version: v2.1
 
-    - name: Set up Go
-      uses: actions/setup-go@v4
-      with:
-        go-version: ${{ env.GO_VERSION }}
-
-    - name: Run golangci-lint
-      uses: golangci/golangci-lint-action@v3
-      with:
-        version: latest
-        args: --timeout=5m
 
   build:
     name: Build
@@ -159,7 +159,7 @@ jobs:
       uses: actions/checkout@v4
 
     - name: Run Gosec Security Scanner
-      uses: securecodewarrior/github-action-gosec@master
+      uses: securego/gosec@master
       with:
         args: './...'
 
@@ -172,7 +172,7 @@ jobs:
         output: 'trivy-results.sarif'
 
     - name: Upload Trivy scan results to GitHub Security tab
-      uses: github/codeql-action/upload-sarif@v2
+      uses: github/codeql-action/upload-sarif@v3
       if: always()
       with:
         sarif_file: 'trivy-results.sarif'

.kiro/specs/alternative-installation-providers/requirements.md

@@ -0,0 +1,97 @@
+# Requirements Document
+
+## Introduction
+
+This specification defines the implementation of alternative installation providers for SAI, extending beyond traditional package managers to support source builds, binary downloads, and script-based installations. This feature will enable SAI to handle the three most common manual installation patterns developers encounter: building from source code, downloading pre-compiled binaries, and executing installation scripts.
+
+## Requirements
+
+### Requirement 1: Complete Source Provider Implementation
+
+**User Story:** As a developer, I want to build software from source code using SAI, so that I can install the latest versions or customize build configurations that aren't available in package managers.
+
+#### Acceptance Criteria
+
+1. WHEN I use `sai install nginx --provider source` THEN SAI SHALL execute the complete source build workflow including download, extract, configure, build, and install steps
+2. WHEN the source provider encounters missing prerequisites THEN SAI SHALL install required build tools and dependencies, asking user confirmation
+3. WHEN I specify custom configure arguments in saidata THEN SAI SHALL use those arguments during the configure step
+4. WHEN a source build fails THEN SAI SHALL execute rollback procedures to clean up partial installations
+5. WHEN I use `sai uninstall nginx --provider source` THEN SAI SHALL remove all files installed from the source build
+6. WHEN I use `sai upgrade nginx --provider source` THEN SAI SHALL backup the current installation, build the new version, and restore on failure
+7. WHEN source builds use different build systems (autotools, cmake, make, meson, ninja) THEN SAI SHALL adapt the build commands appropriately
+8. WHEN OS-specific source configurations exist THEN SAI SHALL use platform-appropriate build settings and prerequisites
+
+### Requirement 2: Binary Download Provider
+
+**User Story:** As a system administrator, I want to download and install pre-compiled binaries using SAI, so that I can quickly deploy software without compilation overhead or when package managers don't have the latest versions.
+
+#### Acceptance Criteria
+
+1. WHEN I use `sai install terraform --provider binary` THEN SAI SHALL download the binary from the specified URL with version templating support
+2. WHEN downloading binaries THEN SAI SHALL verify checksums to ensure file integrity and security
+3. WHEN binaries are compressed archives THEN SAI SHALL automatically extract them to the appropriate location
+4. WHEN installing binaries THEN SAI SHALL set correct file permissions and place them in PATH-accessible locations
+5. WHEN binary URLs include OS and architecture placeholders THEN SAI SHALL substitute appropriate values for the current system
+6. WHEN I use `sai uninstall terraform --provider binary` THEN SAI SHALL remove the installed binary and any associated files
+7. WHEN binary installations fail THEN SAI SHALL clean up partially downloaded or extracted files
+8. WHEN multiple binary variants exist (different architectures, OS versions) THEN SAI SHALL select the appropriate variant automatically
+
+### Requirement 3: Script Installation Provider
+
+**User Story:** As a developer, I want to execute installation scripts using SAI, so that I can install software that provides custom installation scripts while maintaining SAI's unified interface and safety features.
+
+#### Acceptance Criteria
+
+1. WHEN I use `sai install docker --provider script` THEN SAI SHALL download and execute the installation script with appropriate safety measures
+2. WHEN downloading installation scripts THEN SAI SHALL verify checksums to prevent execution of tampered scripts
+3. WHEN executing scripts THEN SAI SHALL provide environment variables and configuration options as specified in saidata
+4. WHEN scripts require user interaction THEN SAI SHALL handle automatic confirmation when --yes flag is used
+5. WHEN script execution fails THEN SAI SHALL execute rollback scripts if provided in the configuration
+6. WHEN I use `sai uninstall docker --provider script` THEN SAI SHALL execute uninstall scripts or perform manual cleanup as configured
+7. WHEN scripts modify system configuration THEN SAI SHALL track changes for potential rollback
+8. WHEN script URLs are HTTPS THEN SAI SHALL enforce secure connections and certificate validation
+
+### Requirement 4: Template Function Implementation
+
+**User Story:** As a provider developer, I want comprehensive template functions for alternative installation methods, so that I can create flexible and reusable provider configurations.
+
+#### Acceptance Criteria
+
+1. WHEN providers use `{{sai_source(0, 'field')}}` THEN SAI SHALL resolve source configuration fields with provider override support
+2. WHEN providers use `{{sai_binary(0, 'field')}}` THEN SAI SHALL resolve binary download configuration with OS/architecture templating
+3. WHEN providers use `{{sai_script(0, 'field')}}` THEN SAI SHALL resolve script configuration with environment variable support
+4. WHEN template functions cannot resolve values THEN SAI SHALL disable the corresponding provider actions gracefully
+5. WHEN OS-specific overrides exist THEN template functions SHALL prioritize platform-specific configurations
+6. WHEN default values are needed THEN template functions SHALL generate sensible defaults based on software metadata
+7. WHEN multiple sources/binaries/scripts are defined THEN template functions SHALL support index-based access
+8. WHEN template resolution fails THEN SAI SHALL provide clear error messages indicating missing configuration
+
+### Requirement 5: Schema and Type System Updates
+
+**User Story:** As a saidata author, I want comprehensive schema support for alternative installation methods, so that I can define complete software configurations with validation and IDE support.
+
+#### Acceptance Criteria
+
+1. WHEN I define sources in saidata THEN the schema SHALL validate build system types, URLs, and configuration options
+2. WHEN I define binaries in saidata THEN the schema SHALL validate download URLs, checksums, and installation paths
+3. WHEN I define scripts in saidata THEN the schema SHALL validate script URLs, environment variables, and rollback configurations
+4. WHEN saidata files are loaded THEN SAI SHALL parse and validate all alternative installation configurations
+5. WHEN provider-specific overrides are used THEN the type system SHALL support nested configuration inheritance
+6. WHEN invalid configurations are detected THEN SAI SHALL provide specific validation errors with field-level details
+7. WHEN OS-specific files are merged THEN the type system SHALL properly combine base and override configurations
+8. WHEN new installation methods are added THEN the schema SHALL be extensible without breaking existing configurations
+
+### Requirement 6: Integration and Compatibility
+
+**User Story:** As a SAI user, I want alternative installation providers to integrate seamlessly with existing SAI features, so that I have a consistent experience regardless of installation method.
+
+#### Acceptance Criteria
+
+1. WHEN using alternative providers THEN SAI SHALL support all standard actions (install, uninstall, upgrade, version, info)
+2. WHEN multiple providers are available THEN SAI SHALL allow provider selection via --provider flag
+3. WHEN provider detection runs THEN SAI SHALL check availability of build tools, download utilities, and script interpreters
+4. WHEN compatibility matrices are defined THEN SAI SHALL respect platform and architecture constraints
+5. WHEN service management is needed THEN alternative providers SHALL integrate with existing service management functions
+6. WHEN file and directory management is required THEN alternative providers SHALL use existing resource management systems
+7. WHEN logging and debugging are enabled THEN alternative providers SHALL provide detailed execution information
+8. WHEN dry-run mode is used THEN alternative providers SHALL show planned actions without executing them

.kiro/specs/alternative-installation-providers/tasks.md

@@ -0,0 +1,196 @@
+# Implementation Plan
+
+## Task Overview
+
+Convert the alternative installation providers design into a series of coding tasks for implementing source, binary, and script providers with complete template function support and seamless SAI integration.
+
+## Implementation Tasks
+
+### Phase 1: Type System and Schema Foundation
+
+- [x] 1. Extend SoftwareData type with alternative installation support
+  - Add Sources, Binaries, and Scripts fields to SoftwareData struct
+  - Add corresponding fields to ProviderConfig struct
+  - Update JSON marshaling/unmarshaling methods
+  - Add helper methods for accessing sources, binaries, and scripts by name/index
+  - _Requirements: 5.4, 5.5, 5.7_
+
+- [x] 1.1 Define Source type and supporting structures
+  - Create Source struct with all required fields (name, url, build_system, etc.)
+  - Create SourceCustomCommands struct for build step overrides
+  - Add validation methods for build system types and required fields
+  - Implement default value generation for build directories and install prefixes
+  - _Requirements: 1.7, 5.1, 5.6_
+
+- [x] 1.2 Define Binary type and supporting structures
+  - Create Binary struct with download and installation configuration
+  - Create ArchiveConfig struct for handling compressed downloads
+  - Create BinaryCustomCommands struct for installation step overrides
+  - Add OS/architecture templating support for download URLs
+  - _Requirements: 2.5, 2.8, 5.2_
+
+- [x] 1.3 Define Script type and supporting structures
+  - Create Script struct with execution configuration
+  - Create ScriptCustomCommands struct for execution step overrides
+  - Add environment variable and argument handling
+  - Implement timeout and working directory configuration
+  - _Requirements: 3.3, 3.7, 5.3_
+
+### Phase 2: Template Function Implementation
+
+- [x] 2. Implement sai_source template function
+  - Add sai_source function to template engine function map
+  - Implement field resolution with provider override support
+  - Add default value generation for missing fields (build_dir, source_dir, etc.)
+  - Handle build system-specific command generation (autotools, cmake, make, etc.)
+  - Add comprehensive error handling and validation
+  - _Requirements: 4.1, 4.5, 4.6, 1.8_
+
+- [x] 2.1 Implement sai_binary template function
+  - Add sai_binary function to template engine function map
+  - Implement OS/architecture placeholder resolution in URLs
+  - Add checksum verification and archive extraction logic
+  - Handle installation path and permission configuration
+  - Add binary-specific validation and error handling
+  - _Requirements: 4.2, 2.2, 2.4, 2.6_
+
+- [x] 2.2 Implement sai_script template function
+  - Add sai_script function to template engine function map
+  - Implement environment variable and argument resolution
+  - Add script interpreter detection and configuration
+  - Handle working directory and timeout settings
+  - Add script-specific validation and security checks
+  - _Requirements: 4.3, 3.4, 3.8, 3.2_
+
+- [x] 2.3 Add template function error handling and validation
+  - Implement graceful degradation when template functions fail to resolve
+  - Add detailed error messages for missing configuration fields
+  - Update template validation to include new function signatures
+  - Add template function testing framework for all new functions
+  - _Requirements: 4.4, 4.8, 5.6_
+
+### Phase 3: Provider Implementation
+
+- [x] 3. Complete source provider implementation
+  - Update existing source.yaml provider with comprehensive action definitions
+  - Implement multi-step build workflow (prerequisites, download, extract, configure, build, install)
+  - Add build system detection and appropriate command generation
+  - Implement rollback procedures for failed builds
+  - Add source build validation and version detection
+  - _Requirements: 1.1, 1.2, 1.4, 1.5, 1.7_
+
+- [x] 3.1 Create binary provider implementation
+  - Create providers/binary.yaml with complete action definitions
+  - Implement download workflow with checksum verification
+  - Add archive extraction support for multiple formats (tar.gz, zip, etc.)
+  - Implement binary installation with correct permissions and PATH placement
+  - Add binary-specific uninstall and upgrade procedures
+  - _Requirements: 2.1, 2.2, 2.3, 2.4, 2.6, 2.7_
+
+- [x] 3.2 Create script provider implementation
+  - Create providers/script.yaml with complete action definitions
+  - Implement script download and checksum verification
+  - Add secure script execution with environment variable support
+  - Implement automatic confirmation handling for interactive scripts
+  - Add script-specific rollback and uninstall procedures
+  - _Requirements: 3.1, 3.2, 3.4, 3.5, 3.6, 3.8_
+
+### Phase 4: Integration and Compatibility
+
+- [x] 4. Update schema validation and documentation
+  - Update saidata-0.2-schema.json with new type definitions
+  - Add comprehensive field validation for all new types
+  - Update schema documentation with examples and field descriptions
+  - Validate schema compatibility with existing saidata files
+  - _Requirements: 5.1, 5.2, 5.3, 5.6, 5.8_
+
+- [x] 4.1 Integrate with existing SAI features
+  - Ensure alternative providers work with standard SAI actions (install, uninstall, upgrade, etc.)
+  - Add provider detection for build tools, download utilities, and script interpreters
+  - Integrate with existing service management and file/directory handling
+  - Add support for --provider flag and provider selection logic
+  - _Requirements: 6.1, 6.2, 6.3, 6.5, 6.6_
+
+- [x] 4.2 Add logging, debugging, and dry-run support
+  - Implement detailed logging for all alternative provider actions
+  - Add debug output for template resolution and command execution
+  - Implement dry-run mode for showing planned actions without execution
+  - Add progress indicators for long-running operations (builds, downloads)
+  - _Requirements: 6.7, 6.8_
+
+### Phase 5: Sample Configurations and Testing
+
+- [x] 5. Create comprehensive sample saidata configurations
+  - Update existing nginx sample with complete source build configuration
+  - Create terraform sample demonstrating binary download configuration
+  - Create docker sample demonstrating script installation configuration
+  - Add OS-specific override examples for all three installation methods
+  - _Requirements: 1.8, 2.8, 3.8, 5.7_
+
+- [x] 5.1 Implement comprehensive test suite
+  - Create unit tests for all new type definitions and methods
+  - Add template function tests with various input combinations and edge cases
+  - Create integration tests for end-to-end provider execution
+  - Add cross-platform compatibility tests for all three providers
+  - _Requirements: 4.4, 4.8, 6.4_
+
+- [x] 5.2 Add validation and error handling tests
+  - Test template resolution failure scenarios and graceful degradation
+  - Add tests for invalid saidata configurations and schema validation
+  - Test rollback procedures for failed installations
+  - Add security tests for script execution and binary verification
+  - _Requirements: 1.4, 2.7, 3.7, 4.4_
+
+### Phase 6: Documentation and Examples
+
+- [x] 6. Update documentation and examples
+  - Update sai_source_functions.md with complete field reference
+  - Create sai_binary_functions.md and sai_script_functions.md documentation
+  - Add provider development guide for alternative installation methods
+  - Update main SAI documentation with alternative provider examples
+  - _Requirements: 4.6, 4.8_
+
+- [x] 6.1 Create usage examples and tutorials
+  - Write tutorial for building software from source with SAI
+  - Create guide for downloading and installing binaries
+  - Add examples for using script-based installations safely
+  - Document best practices for saidata configuration with alternative providers
+  - _Requirements: 6.1, 6.2, 6.3_
+
+## Implementation Notes
+
+### Build System Support
+The source provider must support multiple build systems with appropriate defaults:
+- **autotools**: `./configure && make && make install`
+- **cmake**: `cmake . && cmake --build . && cmake --install .`
+- **make**: Direct make-based builds
+- **meson**: `meson setup build && meson compile -C build && meson install -C build`
+- **ninja**: `ninja && ninja install`
+- **custom**: User-defined build commands
+
+### Security Considerations
+- All downloads must support checksum verification (SHA256 recommended)
+- Script execution must be opt-in with clear security warnings
+- HTTPS enforcement for all download URLs
+- Sandbox considerations for script execution environments
+
+### Cross-Platform Compatibility
+- OS detection for platform-specific configurations
+- Architecture detection for binary downloads
+- Path handling differences between Unix and Windows
+- Permission setting compatibility across platforms
+
+### Performance Optimization
+- Parallel downloads where possible
+- Build caching for source builds
+- Incremental updates for binary installations
+- Progress reporting for long-running operations
+
+## Success Criteria
+
+1. **Functional**: All three providers (source, binary, script) work end-to-end
+2. **Compatible**: Seamless integration with existing SAI features and providers
+3. **Secure**: Proper validation, checksums, and safe execution practices
+4. **Documented**: Complete documentation and examples for all new features
+5. **Tested**: Comprehensive test coverage including edge cases and error scenarios
+6. **Cross-platform**: Works correctly on Linux, macOS, and Windows