GitHub Action Configuration
Relevant source files
The following files were used as context for generating this wiki page:
The GitHub Action Configuration provides a containerized environment to automatically detect code similarities and duplications within a repository's Pull Requests. It serves as a quality gate in CI/CD pipelines by analyzing source code, identifying high-similarity files, and reporting these findings directly as comments on the GitHub issue or pull request.
The system is architected as a Docker-based action that orchestrates environment setup, code analysis using the core detection engine, and interaction with the GitHub API to communicate results. It allows developers to define thresholds for warnings and failures, ensuring that code quality standards are maintained automatically.
Sources: action.yml:1-3, entrypoint.sh:1-22, run_action.py:126-146
Action Definition and Inputs
The action.yml file defines the interface for the GitHub Action, specifying how it should be run and what parameters it accepts. The action uses a Docker image to ensure a consistent runtime environment across different GitHub runner environments.
Input Parameters
| Input | Description | Default | Required |
|---|---|---|---|
github_token | The GitHub token for API authentication | N/A | Yes |
directories | Comma-separated list of source code directories | N/A | Yes |
ignore_directories | Comma-separated list of directories to skip | '' | No |
file_extensions | List of extensions to check (e.g., h, py, java) | h, hpp, c, cpp, cc, java, py, cs | No |
ignore_below | Minimum similarity percentage to report | 10 | No |
warn_above | Similarity percentage threshold for warnings | 100 | No |
fail_above | Similarity percentage threshold to fail the action | 100 | No |
only_code | Strip comments/docstrings before analysis | false | No |
one_comment | Update existing comment instead of new ones | false | No |
header_message_start | Unique identifier for report comments | ## 📌 Duplicate code detection tool report | No |
Sources: action.yml:4-43
Execution Workflow
The execution process begins with entrypoint.sh, which prepares the environment within the Docker container. It extracts the Pull Request ID from the GITHUB_EVENT_PATH, clones the repository using the provided token, and checks out the specific PR branch before invoking the Python runner.
The diagram shows the sequential flow from the initial shell entrypoint to the final GitHub API interaction.
Sources: entrypoint.sh:4-22, run_action.py:112-146
Integration with Core Engine
The run_action.py script acts as a bridge between the GitHub environment (Environment Variables and CLI arguments) and the duplicate_code_detection module. It maps action inputs to the run() function parameters to execute the similarity analysis.
Execution Logic
The action logic handles various return codes from the detection engine:
- SUCCESS: The analysis completed, and similarity is within allowed limits.
- BAD_INPUT: The action provided invalid directories or too few files.
- THRESHOLD_EXCEEDED: One or more file pairs exceeded the
fail_abovethreshold.
Sources: run_action.py:112-124, duplicate_code_detection.py:27-31
Reporting and Notification
Results are formatted into Markdown tables for readability. The tool can either post a new comment for every run or update a single, persistent comment to reduce clutter in the Pull Request thread.
Markdown Generation logic
The similarities_to_markdown function creates a collapsible <details> block for each file analyzed, containing a table of similar files and their percentages. If a similarity exceeds the warn_above threshold, a warning emoji (⚠️) is appended to the value.
This diagram illustrates the logic used to determine whether to create a new comment or update an existing one based on the one_comment input.
Sources: run_action.py:46-77, run_action.py:148-185
Conclusion
The GitHub Action Configuration automates the application of the Duplicate Code Detection Tool within the Flext ecosystem. By utilizing action.yml for configuration, entrypoint.sh for environment isolation, and run_action.py for API integration, it provides a robust mechanism for enforcing code quality standards during the review process.
Sources: action.yml:45-46, run_action.py:202-203