CI/CD Pipeline

The rudder-php-sdk utilizes GitHub Actions to automate code quality enforcement, unit testing, security auditing, and release notifications. The pipeline ensures that every contribution meets the defined linting standards and passes all functional tests across the supported PHP environment.

1. Unit Tests, Coverage & Sonar (test.yml)

The primary CI pipeline is defined in .github/workflows/test.yml. It is triggered on workflow_dispatch, pushes to master and develop, and all pull request activities (opened, reopened, synchronize) targeting those branches .

Implementation Details

1. Runner Hardening: Every job starts by using step-security/harden-runner with an audit egress policy to monitor and restrict outbound network calls .
2. Environment Setup: The runner uses PHP 8.2 and configures pcov for high-performance code coverage collection .
3. Dependency Management: Composer dependencies are cached based on the composer.lock hash to accelerate build times .
4. Static Analysis (Linting): Executes make lint-ci, which triggers phplint and phpcs (PHP CodeSniffer) , .
5. Test Execution: Runs make tests, which executes vendor/bin/phpunit. This generates a Clover coverage report at build/logs/coverage-result.xml and a JUnit log at build/logs/execution-result.xml , .
6. SonarCloud Integration: The pipeline uploads the generated reports to SonarCloud for deep code analysis and quality gate enforcement .

Data Flow: Test and Analysis

The following diagram illustrates how the test.yml workflow interacts with the codebase and external tools.

Test and Coverage Data Flow

Sources: , ,

2. PR Title Validation (check_pr_title.yml)

To maintain a clean and readable commit history, the SDK enforces PR title standards using the rudderlabs/github-action-check-pr-title action .

This workflow triggers on pull requests targeting master or develop branches when they are opened, edited, or synchronized . It ensures that contributors follow the internal RudderStack naming conventions before a PR can be merged.

Sources:

3. Housekeeping (housekeeping.yaml)

The housekeeping workflow automates the maintenance of the repository by managing stale pull requests and cleaning up abandoned branches. It runs on a daily schedule (cron: '42 1 * * *') .

Stale PR Management

• Threshold: PRs with no activity for 20 days are marked with a Stale label .
• Closure: If no further activity occurs for 10 additional days, the PR is automatically closed .
• Notification: A custom message is posted to the PR to inform contributors how to avoid closure .

Branch Cleanup

• Logic: Deletes branches that are older than 2 months .
• Protection: Explicitly protects main, master, and develop branches from deletion via regex .
• Safety: Branches with open pull requests are excluded from deletion .

Sources:

4. Release Notifications (slack-notify.yml)

When a new release is created in GitHub, the slack-notify.yml workflow triggers to inform the engineering team via Slack .

Implementation

The workflow uses the slackapi/slack-github-action to send a structured JSON payload to a specific channel ID stored in secrets . The payload includes:

• A header indicating a "New release: PHP SDK" .
• A markdown section containing a direct link to the GitHub release HTML URL and the tag name .

Release Notification Logic

Sources:

5. SonarCloud Configuration

The SDK's quality gate is managed via sonar-project.properties. This file defines the scope of analysis and the location of test artifacts generated during the CI run.

Property	Value / Description
sonar.projectKey	rudderlabs_rudder-php-sdk
sonar.sources	lib (Core SDK logic)
sonar.tests	test (Unit tests)
sonar.php.coverage.reportPaths	build/logs/coverage-result.xml
sonar.php.tests.reportPath	build/logs/execution-result.xml
sonar.cpd.exclusions	Excludes test/ and examples/ from Copy-Paste Detection

Sources: