⚠ This page is served via a proxy. Original site: https://github.com
This service does not collect credentials or authentication data.
Skip to content

Conversation

@dc-larsen
Copy link
Contributor

@dc-larsen dc-larsen commented Jan 6, 2026

Problem

Customers currently need to manually specify Dockerfile paths in their config:

- uses: SocketDev/[email protected]
  with:
    dockerfile_scanning_enabled: 'true'
    dockerfiles: 'Dockerfile,docker/Dockerfile.prod,services/api/Dockerfile'

This is tedious and error-prone, especially across multiple repos where Dockerfiles may be in different locations.

Solution

Auto-discover Dockerfiles when scanning is enabled but no explicit paths are configured.

Before: Customer must know and list every Dockerfile path
After: Just enable scanning, Socket Basics finds them automatically

- uses: SocketDev/[email protected]
  with:
    dockerfile_scanning_enabled: 'true'
    # That's it - Dockerfiles are found automatically

Implementation

Added _discover_dockerfiles() method to the Trivy connector that:

  1. Walks the workspace directory tree using os.walk()
  2. Matches files against common Dockerfile naming patterns
  3. Excludes directories that typically contain third-party or test code
  4. Returns relative paths for discovered Dockerfiles

Discovery Patterns

Pattern Examples
Exact match Dockerfile
Prefix match Dockerfile.prod, Dockerfile.dev, Dockerfile.test
Extension match app.dockerfile, backend.dockerfile

Excluded Directories

Directories are excluded case-insensitively to avoid false positives:

Category Directories
Dependencies node_modules, vendor
Version control .git, .svn, .hg
Test directories test, tests, testing, __tests__, spec, specs
Test fixtures fixture, fixtures, testdata, test_data
Examples example, examples, sample, samples
Mocks mock, mocks
Build artifacts dist, build, out, target
Virtual envs venv, .venv, env, .env
Caches .cache, .tox, .nox, .pytest_cache
Socket Basics fixtures app_tests

Behavior

Scenario Result
dockerfiles explicitly set Uses explicit config (no change)
dockerfiles empty + scanning enabled Auto-discovers Dockerfiles
dockerfiles empty + scanning disabled Skips scanning (no change)
No Dockerfiles found Logs message, skips scanning

Test Coverage

15 unit tests covering all discovery and exclusion scenarios:

Running Dockerfile auto-discovery tests...

  ✓ discovers_dockerfile_at_root
  ✓ discovers_dockerfile_in_subdirectory
  ✓ discovers_dockerfile_with_suffix
  ✓ discovers_dockerfile_extension
  ✓ excludes_node_modules
  ✓ excludes_vendor_directory
  ✓ excludes_test_directories
  ✓ excludes_fixture_directories
  ✓ excludes_example_directories
  ✓ excludes_build_directories
  ✓ excludes_app_tests_directory
  ✓ discovers_multiple_dockerfiles
  ✓ empty_workspace_returns_empty_list
  ✓ no_dockerfiles_returns_empty_list
  ✓ case_insensitive_exclusions

Results: 15 passed, 0 failed

Test Details

Test What it validates
discovers_dockerfile_at_root Finds Dockerfile in workspace root
discovers_dockerfile_in_subdirectory Finds docker/Dockerfile nested paths
discovers_dockerfile_with_suffix Finds Dockerfile.prod, Dockerfile.dev
discovers_dockerfile_extension Finds app.dockerfile, backend.dockerfile
excludes_node_modules Skips node_modules/**/Dockerfile
excludes_vendor_directory Skips vendor/**/Dockerfile
excludes_test_directories Skips test/, tests/, testing/, __tests__/
excludes_fixture_directories Skips fixture/, fixtures/, testdata/
excludes_example_directories Skips example/, examples/, sample/, samples/
excludes_build_directories Skips dist/, build/, out/, target/
excludes_app_tests_directory Skips Socket Basics test fixtures
discovers_multiple_dockerfiles Finds 4 Dockerfiles across different locations
empty_workspace_returns_empty_list Handles empty workspace gracefully
no_dockerfiles_returns_empty_list Returns [] when no Dockerfiles exist
case_insensitive_exclusions Node_Modules, VENDOR, Tests all excluded

Files Changed

  • socket_basics/core/connector/trivy/trivy.py - Added _discover_dockerfiles() method and integration
  • tests/test_dockerfile_discovery.py - Pytest test suite (for future use with Python 3.10+)
  • tests/run_discovery_tests.py - Standalone test runner (works with any Python 3.x)

Example Log Output

INFO - Auto-discovered 3 Dockerfile(s): Dockerfile, docker/Dockerfile.prod, services/api/Dockerfile
INFO - Running Trivy Dockerfile scanning
INFO - Running: trivy config --format json --output /tmp/xxx.json /workspace/Dockerfile

🤖 Generated with Claude Code

When Dockerfile scanning is enabled but no explicit `dockerfiles` config
is provided, automatically search the workspace for Dockerfiles instead
of skipping the scan entirely.

Discovery patterns:
- Dockerfile (exact match)
- Dockerfile.* (e.g., Dockerfile.prod, Dockerfile.dev)
- *.dockerfile (e.g., app.dockerfile)

Excluded directories to avoid false positives:
- node_modules, vendor, .git
- test, tests, testing, __tests__, spec, specs
- fixture, fixtures, testdata, test_data
- example, examples, sample, samples
- dist, build, out, target
- venv, .venv, env, .env
- app_tests (Socket Basics test fixtures)

This improves the customer experience by eliminating the need to manually
specify Dockerfile paths in each repo, while still respecting explicit
configuration when provided.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@dc-larsen dc-larsen requested a review from a team as a code owner January 6, 2026 22:07
return []

# Directories to exclude from search
exclude_dirs = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should exclude dirs based on content of .gitignore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants