Files
actions/_tests
Ismo Vuorinen ab371bdebf feat: simplify actions (#353)
* feat: first pass simplification

* refactor: simplify actions repository structure

Major simplification reducing actions from 44 to 30:

Consolidations:
- Merge biome-check + biome-fix → biome-lint (mode: check/fix)
- Merge eslint-check + eslint-fix → eslint-lint (mode: check/fix)
- Merge prettier-check + prettier-fix → prettier-lint (mode: check/fix)
- Merge 5 version-detect actions → language-version-detect (language param)

Removals:
- common-file-check, common-retry (better served by external tools)
- docker-publish-gh, docker-publish-hub (consolidated into docker-publish)
- github-release (redundant with existing tooling)
- set-git-config (no longer needed)
- version-validator (functionality moved to language-version-detect)

Fixes:
- Rewrite docker-publish to use official Docker actions directly
- Update validate-inputs example (eslint-fix → eslint-lint)
- Update tests and documentation for new structure

Result: ~6,000 lines removed, cleaner action catalog, maintained functionality.

* refactor: complete action simplification and cleanup

Remove deprecated actions and update remaining actions:

Removed:
- common-file-check, common-retry: utility actions
- docker-publish-gh, docker-publish-hub: replaced by docker-publish wrapper
- github-release, version-validator, set-git-config: no longer needed
- Various version-detect actions: replaced by language-version-detect

Updated:
- docker-publish: rewrite as simple wrapper using official Docker actions
- validate-inputs: update example (eslint-fix → eslint-lint)
- Multiple actions: update configurations and remove deprecated dependencies
- Tests: update integration/unit tests for new structure
- Documentation: update README, remove test for deleted actions

Configuration updates:
- Linter configs, ignore files for new structure
- Makefile, pyproject.toml updates

* fix: enforce POSIX compliance in GitHub workflows

Convert all workflow shell scripts to POSIX-compliant sh:

Critical fixes:
- Replace bash with sh in all shell declarations
- Replace [[ with [ for test conditions
- Replace == with = for string comparisons
- Replace set -euo pipefail with set -eu
- Split compound AND conditions into separate [ ] tests

Files updated:
- .github/workflows/test-actions.yml (7 shell declarations, 10 test operators)
- .github/workflows/security-suite.yml (set -eu)
- .github/workflows/action-security.yml (2 shell declarations)
- .github/workflows/pr-lint.yml (3 shell declarations)
- .github/workflows/issue-stats.yml (1 shell declaration)

Ensures compatibility with minimal sh implementations and aligns with
CLAUDE.md standards requiring POSIX shell compliance across all scripts.

All tests pass: 764 pytest tests, 100% coverage.

* fix: add missing permissions for private repository support

Add critical permissions to pr-lint workflow for private repositories:

Workflow-level permissions:
+ packages: read - Access private npm/PyPI/Composer packages

Job-level permissions:
+ packages: read - Access private packages during dependency installation
+ checks: write - Create and update check runs

Fixes failures when:
- Installing private npm packages from GitHub Packages
- Installing private Composer dependencies
- Installing private Python packages
- Creating status checks with github-script

Valid permission scopes per actionlint:
actions, attestations, checks, contents, deployments, discussions,
id-token, issues, models, packages, pages, pull-requests,
repository-projects, security-events, statuses

Note: "workflows" and "metadata" are NOT valid permission scopes
(they are PAT-only scopes or auto-granted respectively).

* docs: update readmes

* fix: replace bash-specific 'source' with POSIX '.' command

Replace all occurrences of 'source' with '.' (dot) for POSIX compliance:

Changes in python-lint-fix/action.yml:
- Line 165: source .venv/bin/activate → . .venv/bin/activate
- Line 179: source .venv/bin/activate → . .venv/bin/activate
- Line 211: source .venv/bin/activate → . .venv/bin/activate

Also fixed bash-specific test operator:
- Line 192: [[ "$FAIL_ON_ERROR" == "true" ]] → [ "$FAIL_ON_ERROR" = "true" ]

The 'source' command is bash-specific. POSIX sh uses '.' (dot) to source files.
Both commands have identical functionality but '.' is portable across all
POSIX-compliant shells.

* security: fix code injection vulnerability in docker-publish

Fix CodeQL code injection warning (CWE-094, CWE-095, CWE-116):

Issue: inputs.context was used directly in GitHub Actions expression
without sanitization at line 194, allowing potential code injection
by external users.

Fix: Use environment variable indirection to prevent expression injection:
- Added env.BUILD_CONTEXT to capture inputs.context
- Changed context parameter to use ${{ env.BUILD_CONTEXT }}

Environment variables are evaluated after expression compilation,
preventing malicious code execution during workflow parsing.

Security Impact: Medium severity (CVSS 5.0)
Identified by: GitHub Advanced Security (CodeQL)
Reference: https://github.com/ivuorinen/actions/pull/353#pullrequestreview-3481935924

* security: prevent credential persistence in pr-lint checkout

Add persist-credentials: false to checkout step to mitigate untrusted
checkout vulnerability. This prevents GITHUB_TOKEN from being accessible
to potentially malicious PR code.

Fixes: CodeQL finding CWE-829 (untrusted checkout on privileged workflow)

* fix: prevent security bot from overwriting unrelated comments

Replace broad string matching with unique HTML comment marker for
identifying bot-generated comments. Previously, any comment containing
'Security Analysis' or '🔐 GitHub Actions Permissions' would be
overwritten, causing data loss.

Changes:
- Add unique marker: <!-- security-analysis-bot-comment -->
- Prepend marker to generated comment body
- Update comment identification to use marker only
- Add defensive null check for comment.body

This fixes critical data loss bug where user comments could be
permanently overwritten by the security analysis bot.

Follows same proven pattern as test-actions.yml coverage comments.

* improve: show concise permissions diff instead of full blocks

Replace verbose full-block permissions diff with line-by-line changes.
Now shows only added/removed permissions, making output much more
readable.

Changes:
- Parse permissions into individual lines
- Compare old vs new to identify actual changes
- Show only removed (-) and added (+) lines in diff
- Collapse unchanged permissions into details section (≤3 items)
- Show count summary for many unchanged permissions (>3 items)

Example output:
  Before: 30+ lines showing entire permissions block
  After: 3-5 lines showing only what changed

This addresses user feedback that permissions changes were too verbose.

* security: add input validation and trust model documentation

Add comprehensive security validation for docker-publish action to prevent
code injection attacks (CWE-094, CWE-116).

Changes:
- Add validation for context input (reject absolute paths, warn on URLs)
- Add validation for dockerfile input (reject absolute/URL paths)
- Document security trust model in README
- Add best practices for secure usage
- Explain validation rules and threat model

Prevents malicious actors from:
- Building from arbitrary file system locations
- Fetching Dockerfiles from untrusted remote sources
- Executing code injection through build context manipulation

Addresses: CodeRabbit review comments #2541434325, #2541549615
Fixes: GitHub Advanced Security code injection findings

* security: replace unmaintained nick-fields/retry with step-security/retry

Replace nick-fields/retry with step-security/retry across all 4 actions:
- csharp-build/action.yml
- php-composer/action.yml
- go-build/action.yml
- ansible-lint-fix/action.yml

The nick-fields/retry action has security vulnerabilities and low maintenance.
step-security/retry is a drop-in replacement with full API compatibility.

All inputs (timeout_minutes, max_attempts, command, retry_wait_seconds) are
compatible. Using SHA-pinned version for security.

Addresses CodeRabbit review comment #2541549598

* test: add is_input_required() helper function

Add helper function to check if an action input is required, reducing
duplication across test suites.

The function:
- Takes action_file and input_name as parameters
- Uses validation_core.py to query the 'required' property
- Returns 0 (success) if input is required
- Returns 1 (failure) if input is optional

This DRY improvement addresses CodeRabbit review comment #2541549572

* feat: add mode validation convention mapping

Add "mode" to the validation conventions mapping for lint actions
(eslint-lint, biome-lint, prettier-lint).

Note: The update-validators script doesn't currently recognize "string"
as a validator type, so mode validation coverage remains at 93%. The
actions already have inline validation for mode (check|fix), so this is
primarily for improving coverage metrics.

Addresses part of CodeRabbit review comment #2541549570
(validation coverage improvement)

* docs: fix CLAUDE.md action counts and add missing action

- Update action count from 31 to 29 (line 42)
- Add missing 'action-versioning' to Utilities category (line 74)

Addresses CodeRabbit review comments #2541553130 and #2541553110

* docs: add security considerations to docker-publish

Add security documentation to both action.yml header and README.md:
- Trust model explanation
- Input validation details for context and dockerfile
- Attack prevention information
- Best practices for secure usage

The documentation was previously removed when README was autogenerated.
Now documented in both places to ensure it persists.

* fix: correct step ID reference in docker-build

Fix incorrect step ID reference in platforms output:
- Changed steps.platforms.outputs.built to steps.detect-platforms.outputs.platforms
- The step is actually named 'detect-platforms' not 'platforms'
- Ensures output correctly references the detect-platforms step defined at line 188

* fix: ensure docker-build platforms output is always available

Make detect-platforms step unconditional to fix broken output contract.

The platforms output (line 123) references steps.detect-platforms.outputs.platforms,
but the step only ran when auto-detect-platforms was true (default: false).
This caused undefined output in most cases.

Changes:
- Remove 'if' condition from detect-platforms step
- Step now always runs and always produces platforms output
- When auto-detect is false: outputs configured architectures
- When auto-detect is true: outputs detected platforms or falls back to architectures
- Add '|| true' to grep to prevent errors when no platforms detected

Fixes CodeRabbit review comment #2541824904

* security: remove env var indirection in docker-publish BUILD_CONTEXT

Remove BUILD_CONTEXT env var indirection to address GitHub Advanced Security alert.

The inputs.context is validated at lines 137-147 (rejects absolute paths, warns on URLs)
before being used, so the env var indirection is unnecessary and triggers false positive
code injection warnings.

Changes:
- Remove BUILD_CONTEXT env var (line 254)
- Use inputs.context directly (line 256 → 254)
- Input validation remains in place (lines 137-147)

Fixes GitHub Advanced Security code injection alerts (comments #2541405269, #2541522320)

* feat: implement mode_enum validator for lint actions

Add mode_enum validator to validate mode inputs in linting actions.

Changes to conventions.py:
- Add 'mode_enum' to exact_matches mapping (line 215)
- Add 'mode_enum' to PHP-specific validators list (line 560)
- Implement _validate_mode_enum() method (lines 642-660)
  - Validates mode values against ['check', 'fix']
  - Returns clear error messages for invalid values

Updated rules.yml files:
- biome-lint: Add mode: mode_enum convention
- eslint-lint: Add mode: mode_enum convention
- prettier-lint: Add mode: mode_enum convention
- All rules.yml: Fix YAML formatting with yamlfmt

This addresses PR #353 comment #2541522326 which reported that mode validation
was being skipped due to unrecognized 'string' type, reducing coverage to 93%.

Tested with biome-lint action - correctly rejects invalid values and accepts
valid 'check' and 'fix' values.

* docs: update action count from 29 to 30 in CLAUDE.md

Update two references to action count in CLAUDE.md:
- Line 42: repository_overview memory description
- Line 74: Repository Structure section header

The repository has 30 actions total (29 listed + validate-inputs).

Addresses PR #353 comment #2541549588.

* docs: use pinned version ref in language-version-detect README

Change usage example from @main to @v2025 for security best practices.

Using pinned version refs (instead of @main) ensures:
- Predictable behavior across workflow runs
- Protection against breaking changes
- Better security through immutable references

Follows repository convention documented in main README and CLAUDE.md.

Addresses PR #353 comment #2541549588.

* refactor: remove deprecated add-snippets input from codeql-analysis

Remove add-snippets input which has been deprecated by GitHub's CodeQL action
and no longer has any effect.

Changes:
- Remove add-snippets input definition (lines 93-96)
- Remove reference in init step (line 129)
- Remove reference in analyze step (line 211)
- Regenerate README and rules.yml

This is a non-breaking change since:
- Default was 'false' (minimal usage expected)
- GitHub's action already ignores this parameter
- Aligns with recent repository simplification efforts

* feat: add mode_enum validator and update rules

Add mode_enum validator support for lint actions and regenerate all validation rules:

Validator Changes:
- Add mode_enum to action_overrides for biome-lint, eslint-lint, prettier-lint
- Remove deprecated add-snippets from codeql-analysis overrides

Rules Updates:
- All 29 action rules.yml files regenerated with consistent YAML formatting
- biome-lint, eslint-lint, prettier-lint now validate mode input (check/fix)
- Improved coverage for lint actions (79% → 83% for biome, 93% for eslint, 79% for prettier)

Documentation:
- Fix language-version-detect README to use @v2025 (not @main)
- Remove outdated docker-publish security docs (now handled by official actions)

This completes PR #353 review feedback implementation.

* fix: replace bash-specific $'\n' with POSIX-compliant printf

Replace non-POSIX $'\n' syntax in tag building loop with printf-based
approach that works in any POSIX shell.

Changed:
- Line 216: tags="${tags}"$'\n'"${image}:${tag}"
+ Line 216: tags="$(printf '%s\n%s' "$tags" "${image}:${tag}")"

This ensures docker-publish/action.yml runs correctly on systems using
/bin/sh instead of bash.
2025-11-19 15:42:06 +02:00
..
2025-11-19 15:42:06 +02:00
2025-11-19 15:42:06 +02:00
2025-11-19 15:42:06 +02:00

GitHub Actions Testing Framework

A comprehensive testing framework for validating GitHub Actions in this monorepo using ShellSpec and Python-based input validation.

🚀 Quick Start

# Run all tests
make test

# Run only unit tests
make test-unit

# Run tests for specific action
make test-action ACTION=node-setup

# Run with coverage reporting
make test-coverage

Prerequisites

# Install ShellSpec (testing framework)
curl -fsSL https://github.com/shellspec/shellspec/releases/latest/download/shellspec-dist.tar.gz | tar -xz
sudo make -C shellspec-* install

# Install nektos/act (optional, for integration tests)
brew install act  # macOS
# or: curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

📁 Framework Overview

Architecture

The testing framework uses a multi-level testing strategy:

  1. Unit Tests - Fast validation of action logic, inputs, and outputs using Python validation
  2. Integration Tests - Test actions in realistic workflow environments
  3. External Usage Tests - Validate actions work as ivuorinen/actions/action-name@main

Technology Stack

  • Primary Framework: ShellSpec - BDD testing for shell scripts
  • Validation: Python-based input validation via validate-inputs/validator.py
  • Local Execution: nektos/act - Run GitHub Actions locally
  • CI Integration: GitHub Actions workflows

Directory Structure

_tests/
├── README.md                    # This documentation
├── run-tests.sh                 # Main test runner script
├── unit/                       # Unit tests by action
│   ├── spec_helper.sh          # ShellSpec helper with validation functions
│   ├── version-file-parser/    # Example unit tests
│   ├── node-setup/            # Example unit tests
│   └── ...                    # One directory per action
├── framework/                   # Core testing utilities
│   ├── setup.sh                # Test environment setup
│   ├── utils.sh                # Common testing functions
│   ├── validation.py           # Python validation utilities
│   └── fixtures/               # Test fixtures
├── integration/               # Integration tests
│   ├── workflows/             # Test workflows for nektos/act
│   ├── external-usage/        # External reference tests
│   └── action-chains/         # Multi-action workflow tests
├── coverage/                  # Coverage reports
└── reports/                   # Test execution reports

✍️ Writing Tests

Basic Unit Test Structure

#!/usr/bin/env shellspec
# _tests/unit/my-action/validation.spec.sh

Describe "my-action validation"
ACTION_DIR="my-action"
ACTION_FILE="$ACTION_DIR/action.yml"

Context "when validating required inputs"
  It "accepts valid input"
    When call validate_input_python "my-action" "input-name" "valid-value"
    The status should be success
  End

  It "rejects invalid input"
    When call validate_input_python "my-action" "input-name" "invalid@value"
    The status should be failure
  End
End

Context "when validating boolean inputs"
  It "accepts true"
    When call validate_input_python "my-action" "dry-run" "true"
    The status should be success
  End

  It "accepts false"
    When call validate_input_python "my-action" "dry-run" "false"
    The status should be success
  End

  It "rejects invalid boolean"
    When call validate_input_python "my-action" "dry-run" "maybe"
    The status should be failure
  End
End
End

Integration Test Example

# _tests/integration/workflows/my-action-test.yml
name: Test my-action Integration
on: workflow_dispatch

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Test action locally
        id: test-local
        uses: ./my-action
        with:
          required-input: 'test-value'

      - name: Validate outputs
        run: |
          echo "Output: ${{ steps.test-local.outputs.result }}"
          [[ -n "${{ steps.test-local.outputs.result }}" ]] || exit 1

      - name: Test external reference
        uses: ivuorinen/actions/my-action@main
        with:
          required-input: 'test-value'

🛠️ Testing Functions

Primary Validation Function

The framework provides one main validation function that uses the Python validation system:

validate_input_python

Tests input validation using the centralized Python validator:

validate_input_python "action-name" "input-name" "test-value"

Examples:

# Boolean validation
validate_input_python "pre-commit" "dry-run" "true"       # success
validate_input_python "pre-commit" "dry-run" "false"      # success
validate_input_python "pre-commit" "dry-run" "maybe"      # failure

# Version validation
validate_input_python "node-setup" "node-version" "18.0.0"       # success
validate_input_python "node-setup" "node-version" "v1.2.3"       # success
validate_input_python "node-setup" "node-version" "invalid"      # failure

# Token validation
validate_input_python "npm-publish" "npm-token" "ghp_123..."    # success
validate_input_python "npm-publish" "npm-token" "invalid"       # failure

# Docker validation
validate_input_python "docker-build" "image-name" "myapp"       # success
validate_input_python "docker-build" "tag" "v1.0.0"            # success

# Path validation (security)
validate_input_python "pre-commit" "config-file" "config.yml"   # success
validate_input_python "pre-commit" "config-file" "../etc/pass"  # failure

# Injection detection
validate_input_python "common-retry" "command" "echo test"      # success
validate_input_python "common-retry" "command" "rm -rf /; "     # failure

Helper Functions from spec_helper.sh

# Setup/cleanup
setup_default_inputs "action-name" "input-name"     # Set required defaults
cleanup_default_inputs "action-name" "input-name"   # Clean up defaults
shellspec_setup_test_env "test-name"               # Setup test environment
shellspec_cleanup_test_env "test-name"             # Cleanup test environment

# Mock execution
shellspec_mock_action_run "action-dir" key1 value1 key2 value2
shellspec_validate_action_output "expected-key" "expected-value"

# Action metadata
validate_action_yml "action.yml"          # Validate YAML structure
get_action_inputs "action.yml"           # Get action inputs
get_action_outputs "action.yml"          # Get action outputs
get_action_name "action.yml"             # Get action name

Complete Action Validation Example

Describe "comprehensive-action validation"
  ACTION_DIR="comprehensive-action"
  ACTION_FILE="$ACTION_DIR/action.yml"

  Context "when validating all input types"
    It "validates boolean inputs"
      When call validate_input_python "$ACTION_DIR" "verbose" "true"
      The status should be success

      When call validate_input_python "$ACTION_DIR" "verbose" "false"
      The status should be success

      When call validate_input_python "$ACTION_DIR" "verbose" "invalid"
      The status should be failure
    End

    It "validates numeric inputs"
      When call validate_input_python "$ACTION_DIR" "max-retries" "3"
      The status should be success

      When call validate_input_python "$ACTION_DIR" "max-retries" "999"
      The status should be failure
    End

    It "validates version inputs"
      When call validate_input_python "$ACTION_DIR" "tool-version" "1.0.0"
      The status should be success

      When call validate_input_python "$ACTION_DIR" "tool-version" "v1.2.3-rc.1"
      The status should be success
    End

    It "validates security patterns"
      When call validate_input_python "$ACTION_DIR" "command" "echo test"
      The status should be success

      When call validate_input_python "$ACTION_DIR" "command" "rm -rf /; "
      The status should be failure
    End
  End

  Context "when validating action structure"
    It "has valid YAML structure"
      When call validate_action_yml "$ACTION_FILE"
      The status should be success
    End
  End
End

🎯 Testing Patterns by Action Type

Setup Actions (node-setup, php-version-detect, etc.)

Focus on version detection and environment setup:

Context "when detecting versions"
  It "detects version from config files"
    When call validate_input_python "node-setup" "node-version" "18.0.0"
    The status should be success
  End

  It "accepts default version"
    When call validate_input_python "python-version-detect" "default-version" "3.11"
    The status should be success
  End
End

Linting Actions (eslint-fix, prettier-fix, etc.)

Focus on file processing and security:

Context "when processing files"
  It "validates working directory"
    When call validate_input_python "eslint-fix" "working-directory" "."
    The status should be success
  End

  It "rejects path traversal"
    When call validate_input_python "eslint-fix" "working-directory" "../etc"
    The status should be failure
  End

  It "validates boolean flags"
    When call validate_input_python "eslint-fix" "fix-only" "true"
    The status should be success
  End
End

Build Actions (docker-build, go-build, etc.)

Focus on build configuration:

Context "when building"
  It "validates image name"
    When call validate_input_python "docker-build" "image-name" "myapp"
    The status should be success
  End

  It "validates tag format"
    When call validate_input_python "docker-build" "tag" "v1.0.0"
    The status should be success
  End

  It "validates platforms"
    When call validate_input_python "docker-build" "platforms" "linux/amd64,linux/arm64"
    The status should be success
  End
End

Publishing Actions (npm-publish, docker-publish, etc.)

Focus on credentials and registry validation:

Context "when publishing"
  It "validates token format"
    When call validate_input_python "npm-publish" "npm-token" "ghp_123456789012345678901234567890123456"
    The status should be success
  End

  It "rejects invalid token"
    When call validate_input_python "npm-publish" "npm-token" "invalid-token"
    The status should be failure
  End

  It "validates version"
    When call validate_input_python "npm-publish" "package-version" "1.0.0"
    The status should be success
  End
End

🔧 Running Tests

Command Line Interface

# Basic usage
./_tests/run-tests.sh [OPTIONS] [ACTION_NAME...]

# Examples
./_tests/run-tests.sh                           # All tests, all actions
./_tests/run-tests.sh -t unit                   # Unit tests only
./_tests/run-tests.sh -a node-setup             # Specific action
./_tests/run-tests.sh -t integration docker-build  # Integration tests for docker-build
./_tests/run-tests.sh --format json --coverage  # JSON output with coverage

Options

Option Description
-t, --type TYPE Test type: unit, integration, e2e, all
-a, --action ACTION Filter by action name pattern
-j, --jobs JOBS Number of parallel jobs (default: 4)
-c, --coverage Enable coverage reporting
-f, --format FORMAT Output format: console, json, junit
-v, --verbose Enable verbose output
-h, --help Show help message

Make Targets

make test                    # Run all tests
make test-unit              # Unit tests only
make test-integration       # Integration tests only
make test-coverage          # Tests with coverage
make test-action ACTION=name # Test specific action

🤝 Contributing Tests

Adding Tests for New Actions

  1. Create Unit Test Directory

    mkdir -p _tests/unit/new-action
    
  2. Write Unit Tests

    # _tests/unit/new-action/validation.spec.sh
    #!/usr/bin/env shellspec
    
    Describe "new-action validation"
    ACTION_DIR="new-action"
    ACTION_FILE="$ACTION_DIR/action.yml"
    
    Context "when validating inputs"
      It "validates required input"
        When call validate_input_python "new-action" "required-input" "value"
        The status should be success
      End
    End
    End
    
  3. Create Integration Test

    # _tests/integration/workflows/new-action-test.yml
    # (See integration test example above)
    
  4. Test Your Tests

    make test-action ACTION=new-action
    

Pull Request Checklist

  • Tests use validate_input_python for input validation
  • All test types pass locally (make test)
  • Integration test workflow created
  • Security testing included for user inputs
  • Tests are independent and isolated
  • Proper cleanup in test teardown
  • Documentation updated if needed

💡 Best Practices

1. Use validate_input_python for All Input Testing

Good:

When call validate_input_python "my-action" "verbose" "true"
The status should be success

Avoid:

# Don't manually test validation - use the Python validator
export INPUT_VERBOSE="true"
python3 validate-inputs/validator.py

Good:

Context "when validating configuration"
  It "accepts valid boolean"
    When call validate_input_python "my-action" "dry-run" "true"
    The status should be success
  End

  It "accepts valid version"
    When call validate_input_python "my-action" "tool-version" "1.0.0"
    The status should be success
  End
End

3. Always Include Security Testing

Always include:

It "rejects command injection"
  When call validate_input_python "common-retry" "command" "rm -rf /; "
  The status should be failure
End

It "rejects path traversal"
  When call validate_input_python "pre-commit" "config-file" "../etc/passwd"
  The status should be failure
End

4. Write Descriptive Test Names

Good:

It "accepts valid semantic version format"
It "rejects version with invalid characters"
It "falls back to default when no version file exists"

Avoid:

It "validates input"
It "works correctly"

5. Keep Tests Independent

  • Each test should work in isolation
  • Don't rely on test execution order
  • Clean up after each test
  • Use proper setup/teardown

🔍 Framework Features

Test Environment Setup

The framework automatically sets up test environments via spec_helper.sh:

# Automatic setup on load
- GitHub Actions environment variables
- Temporary directories
- Mock GITHUB_OUTPUT files
- Default required inputs for actions

# Available variables
$PROJECT_ROOT        # Repository root
$TEST_ROOT          # _tests/ directory
$FRAMEWORK_DIR      # _tests/framework/
$FIXTURES_DIR       # _tests/framework/fixtures/
$TEMP_DIR           # Temporary test directory
$GITHUB_OUTPUT      # Mock outputs file
$GITHUB_ENV         # Mock environment file

Python Validation Integration

All input validation uses the centralized Python validation system from validate-inputs/:

  • Convention-based automatic validation
  • 9 specialized validators (Boolean, Version, Token, Numeric, File, Network, Docker, Security, CodeQL)
  • Custom validator support per action
  • Injection and security pattern detection

🚨 Troubleshooting

Common Issues

"ShellSpec command not found"

# Install ShellSpec globally
curl -fsSL https://github.com/shellspec/shellspec/releases/latest/download/shellspec-dist.tar.gz | tar -xz
sudo make -C shellspec-* install

"act command not found"

# Install nektos/act (macOS)
brew install act

# Install nektos/act (Linux)
curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

Tests timeout

# Increase timeout for slow operations
export TEST_TIMEOUT=300

Permission denied on test scripts

# Make test scripts executable
find _tests/ -name "*.sh" -exec chmod +x {} \;

Debugging Tests

  1. Enable Verbose Mode

    ./_tests/run-tests.sh -v
    
  2. Run Single Test

    shellspec _tests/unit/my-action/validation.spec.sh
    
  3. Enable Debug Mode

    export SHELLSPEC_DEBUG=1
    shellspec _tests/unit/my-action/validation.spec.sh
    
  4. Check Test Output

    # Test results stored in _tests/reports/
    cat _tests/reports/unit/my-action.txt
    

📚 Resources

Framework Development

Framework File Structure

_tests/
├── unit/
│   └── spec_helper.sh          # ShellSpec configuration and helpers
├── framework/
│   ├── setup.sh                # Test environment initialization
│   ├── utils.sh                # Common utility functions
│   ├── validation.py           # Python validation helpers
│   └── fixtures/               # Test fixtures
└── integration/
    ├── workflows/              # Integration test workflows
    ├── external-usage/         # External reference tests
    └── action-chains/          # Multi-action tests

Available Functions

From spec_helper.sh (_tests/unit/spec_helper.sh):

  • validate_input_python(action, input_name, value) - Main validation function
  • setup_default_inputs(action, input_name) - Set default required inputs
  • cleanup_default_inputs(action, input_name) - Clean up default inputs
  • shellspec_setup_test_env(name) - Setup test environment
  • shellspec_cleanup_test_env(name) - Cleanup test environment
  • shellspec_mock_action_run(action_dir, ...) - Mock action execution
  • shellspec_validate_action_output(key, value) - Validate outputs

From utils.sh (_tests/framework/utils.sh):

  • validate_action_yml(file) - Validate action YAML
  • get_action_inputs(file) - Extract action inputs
  • get_action_outputs(file) - Extract action outputs
  • get_action_name(file) - Get action name
  • test_input_validation(dir, name, value, expected) - Test input
  • test_action_outputs(dir) - Test action outputs
  • test_external_usage(dir) - Test external usage

Last Updated: October 15, 2025