ci: introduce basic PR checks for typecheck, build and tests

[yb175]

What & why

Fixes #

How to test

• [ ]
• [ ]

AI assistance

• None
• Used AI for:

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would change existing behavior)
• Documentation
• Tests only
• Refactor / cleanup

Checklist

• pnpm typecheck passes
• pnpm lint passes
• pnpm format has been run on changed files
• Added or updated tests where it makes sense
• Branch is up to date with main
• PR title follows the area-prefix style for the area being changed (e.g. worker: …, fix(slack): …)
• Read CONTRIBUTING.md (skim counts)

[pullsharksite]

🦈 PullShark AI Analysis

Risk Level: 🔴 High

🧪 Recommended Tests

• Create a Pull Request with a valid, small code change (e.g., adding a comment) to confirm all workflow steps (Typecheck, Build, Tests) pass successfully.
• Create a Pull Request that introduces a deliberate type error to confirm the 'Typecheck & build' job fails as expected and provides clear error messages.
• Create a Pull Request that introduces a deliberate compilation error (e.g., invalid syntax) to confirm the 'Typecheck & build' job fails as expected.
• Create a Pull Request that causes an existing test to fail to confirm the 'Tests' job fails correctly.
• Create a Pull Request that only modifies dependencies (e.g., adding a new pnpm package) to ensure pnpm install and subsequent steps run correctly.
• Verify pnpm caching functionality: Run the workflow on a PR, then open a second PR with no dependency changes to confirm the cache is utilized, speeding up pnpm install.
• Monitor the execution time of each job and step to establish a baseline and identify potential performance bottlenecks for large PRs.
• Review the PR status checks on GitHub to ensure the workflow's status is clearly reported and provides direct links to the logs.

⚠️ Edge Cases & Security

• Verify workflow behavior for Pull Requests that only contain changes to documentation or non-code files (e.g., README.md).
• Test the workflow against a PR with a very large number of file changes or a very large single file to ensure performance and timeout limits are handled.
• Verify the workflow is triggered correctly when a PR is opened from different branch types (e.g., feature, bugfix, hotfix).
• Confirm the workflow can be explicitly skipped by including [skip ci] or [ci skip] in the commit message.
• Assess the behavior of the workflow when a PR is marked as 'Draft' and then later converted to 'Ready for review'.
• Verify how the workflow handles changes to the CI workflow file itself within a Pull Request. Does it run the new workflow definition or the old one?
• Explicitly test the branches: [""] configuration. This is an unusual configuration; confirm if it correctly triggers for all branches, or if it has an unintended effect (e.g., not triggering at all, or only for a branch literally named "").
• Review workflow logs to ensure no sensitive environment variables, secrets, or tokens are accidentally exposed during pnpm install or other steps.
• Evaluate the default permissions of the GITHUB_TOKEN used by the workflow to ensure it adheres to the principle of least privilege.
• Consider adding a security scanning step (e.g., for dependency vulnerabilities) to pnpm install or as a separate job, as basic dependency installation can introduce risks.
• Confirm that all GitHub Actions are pinned to specific major versions (e.g., @v4) to mitigate supply chain risks, which appears to be the case in the diff, but warrants confirmation.

---

Generated by PullShark AI

[pullsharksite]

🦈 PullShark AI Analysis

Risk Level: 🔴 High

🧪 Recommended Tests

• Positive Flow: Open a Pull Request with code that correctly passes typecheck, build, and all unit/integration tests. Verify the CI pipeline passes successfully.
• Negative Flow - Type Error: Open a Pull Request that introduces a type error. Verify the CI pipeline fails specifically at the typecheck step with an appropriate error message.
• Negative Flow - Build Error: Open a Pull Request that introduces a build-breaking change. Verify the CI pipeline fails at the build step with a relevant error message.
• Negative Flow - Test Failure: Open a Pull Request that causes an existing unit or integration test to fail. Verify the CI pipeline fails at the test step with the correct test results.
• Branch Targeting: Validate that the CI workflow triggers correctly only for pull_request events targeting the intended branches as configured (e.g., main, master, develop, ensuring branches: [""] behaves as expected).
• Dependency Management: Verify pnpm install executes correctly, utilizes caching effectively, and that all specified dependencies are installed without issues.
• Environment Validation: Confirm that the specified Node.js version (20) and pnpm setup are correctly provisioned and used by the CI runner.
• Performance Monitoring: Monitor the execution time of the CI job for typical PRs to ensure it completes within acceptable performance limits.
• Workflow Cancellation: Push a new commit to an existing open Pull Request while a CI run is in progress. Verify that the previous run is cancelled, and a new CI run is initiated.
• Code-less PR: Create a Pull Request with only a README change or an empty commit. Verify that the CI still triggers and passes without errors, indicating the checks are robust even without code changes.

⚠️ Edge Cases & Security

• PRs targeting branches not explicitly configured to trigger the workflow (e.g., if branches: [""] does not cover all intended target branches).
• PRs with no code changes (e.g., only documentation updates or an empty commit) to ensure the CI still triggers and passes without issues.
• Very large PRs with extensive code changes that might challenge CI runner resources or hit workflow timeouts during build/test.
• Intermittent network issues preventing dependency installation during the pnpm install step.
• Corrupted or stale pnpm cache leading to unexpected build failures or prolonged installation times.
• Changes to package.json or pnpm-lock.yaml that introduce incompatible dependencies not immediately caught by basic typecheck/build/test.
• Using unpinned GitHub Actions versions (e.g., uses: actions/checkout instead of actions/checkout@v4) could introduce vulnerabilities if the action maintainers release breaking or malicious changes.
• Potential for malicious code injection via pnpm scripts (e.g., preinstall, postinstall) if a malicious dependency or package.json is introduced through a PR, which could execute arbitrary commands on the CI runner.
• Over-privileged CI tokens or environment if future steps with elevated permissions are added without proper scope limitation (though not evident in this basic setup).
• Accidental exposure of sensitive data (if any secrets were to be added in future steps) through build logs or output.

---

Generated by PullShark AI

[pullsharksite]

🦈 PullShark AI Analysis

Risk Level: 🔴 High

🧪 Recommended Tests

• Verify the CI workflow is triggered automatically upon opening a new Pull Request.
• Verify the CI workflow is re-triggered automatically upon new commits pushed to an existing Pull Request.
• Validate that the 'Typecheck' job passes when there are no type errors in the code.
• Validate that the 'Typecheck' job fails gracefully and reports errors when type errors are introduced.
• Validate that the 'Build' job passes when the project builds successfully.
• Validate that the 'Build' job fails gracefully and reports errors when build failures are introduced.
• Validate that the 'Test' job passes when all unit/integration tests pass.
• Validate that the 'Test' job fails gracefully and reports errors when one or more tests fail.
• Confirm that all status checks (Typecheck, Build, Tests) are reported correctly on the GitHub Pull Request interface (green check for success, red X for failure).
• Verify the correct Node.js version is utilized as specified in the workflow configuration.
• Verify that pnpm is correctly installed and used for dependency management.
• Verify the workflow runs on the specified operating system ('ubuntu-latest').
• Test scenarios where a PR introduces changes only to non-code files (e.g., markdown) to ensure expected CI behavior.
• Introduce a deliberate syntax error in the workflow file itself to ensure it is caught and reported.

⚠️ Edge Cases & Security

• PRs with only documentation changes (verify if CI is necessary or can be optimized/skipped).
• PRs with large number of file changes or complex code modifications (monitor CI performance and potential timeouts).
• PRs that introduce new dependencies or significantly modify existing ones (ensure 'pnpm install' behaves correctly).
• PRs that are reverts of previous commits (verify expected CI behavior).
• PRs with an empty diff (e.g., after reverting a previous revert).
• CI workflow file itself containing syntax errors or misconfigurations (verify immediate failure on workflow parsing).
• Multiple commits pushed to an open PR branch simultaneously (ensure all commits are processed and status is updated correctly).
• PRs opened from branches with non-standard characters in their names (e.g., special symbols).
• Potential for malicious code execution if the build/test scripts allow arbitrary commands based on PR content (ensure scripts are limited to their intended scope).
• Risk of sensitive data exposure in CI logs if secrets were to be introduced or misconfigured (verify no secrets are logged).
• Supply chain vulnerability if any external actions used (e.g., actions/checkout, pnpm/action-setup, actions/setup-node) are compromised or outdated.
• Resource exhaustion attacks by a malicious PR trying to consume excessive build runner resources (CPU, memory, disk) leading to denial of service or increased costs.
• Overly permissive GITHUB_TOKEN permissions if additional steps or interactions with repository assets are added in the future.

---

Generated by PullShark AI

[pullsharksite]

🦈 PullShark AI Analysis

Risk Level: 🔴 High

🧪 Recommended Tests

• Positive Test Case (Happy Path): Create a simple PR with a valid, passing code change. Verify all 'typecheck', 'build', and 'tests' steps trigger and pass successfully, and the PR status is updated to 'Success'.
• Negative Test Case (Type Error): Create a PR that introduces a deliberate type error. Verify the 'typecheck' step fails as expected, and subsequent steps are skipped or fail appropriately. Check the PR status is updated to 'Failure'.
• Negative Test Case (Build Error): Create a PR that breaks the project's build process. Verify the 'build' step fails as expected, and the PR status is updated to 'Failure'.
• Negative Test Case (Failing Test): Create a PR that causes an existing test to fail or introduces a new failing test. Verify the 'tests' step fails as expected, and the PR status is updated to 'Failure'.
• Workflow Configuration Test: Verify the branches: [""] configuration's actual behavior. Test PRs opened against different branches (e.g., main, develop, feature branches) to confirm it triggers correctly on intended branches and doesn't trigger on unintended ones (if applicable).
• CI Workflow Syntax Error Test: Introduce a deliberate syntax error into the ci.yml file in a separate branch. Open a PR for this change and verify that the workflow fails to parse or execute, clearly indicating the configuration error.
• Dependency Management Test: Verify that pnpm install correctly installs dependencies and that the cache: pnpm mechanism is functioning as intended, showing cached dependencies being restored or new ones being cached.
• Node.js Version Test: Confirm that Node.js version 20 is correctly provisioned and used by the workflow runner.
• Re-trigger Test: Push additional commits to an already open PR. Verify that the CI workflow automatically re-triggers and runs all checks again.
• Logs and Reporting Test: Examine the GitHub Actions workflow logs for both successful and failed runs. Ensure they are clear, concise, and provide sufficient detail for debugging.
• Performance Observation: Monitor and record the execution times for 'typecheck', 'build', and 'tests' steps to establish a baseline and ensure they are within acceptable limits.

⚠️ Edge Cases & Security

• PRs targeting non-standard or unexpected branch names (especially given branches: [""] in the config).
• Workflow file syntax errors introduced within the ci.yml itself.
• Changes that solely involve modifications to the ci.yml workflow file, with no code changes.
• High volume of concurrent PRs being opened, testing GitHub Actions runner capacity and queueing.
• Scenarios involving dependency cache invalidation or corruption (e.g., frequent pnpm-lock.yaml changes).
• Very large PRs that might push against runner resource limits or job timeouts.
• Reliance on external GitHub Actions (e.g., actions/checkout@v4, pnpm/action-setup@v4, actions/setup-node@v4) and potential supply chain vulnerabilities if these actions are compromised or have unpatched security flaws.
• Potential for unauthorized code execution if the build/test commands were less constrained and could execute arbitrary code from the PR context without proper sandboxing (though standard pnpm commands reduce this risk).
• Accidental exposure of sensitive environment variables or secrets in build logs, particularly during unexpected failures (even if no secrets are explicitly used in the provided diff, it's a general CI concern).

---

Generated by PullShark AI

[pullsharksite]

🦈 PullShark AI Analysis

Risk Level: 🔴 High

🧪 Recommended Tests

• Create a new Pull Request with valid code (no type errors, builds successfully, all tests pass) and verify the CI workflow triggers, all steps pass, and the PR status reflects success.
• Create a Pull Request that deliberately introduces a type error and verify the typecheck step fails, and the overall CI workflow reports failure.
• Create a Pull Request that deliberately introduces a build error (e.g., malformed syntax in a compiled file, incorrect build script entry) and verify the build step fails, and the overall CI workflow reports failure.
• Create a Pull Request that deliberately introduces a failing test case and verify the test step (if implemented in the full workflow) fails, and the overall CI workflow reports failure.
• Create a Pull Request with no code changes to ensure the CI workflow still triggers and passes correctly, confirming it runs on all PRs regardless of diff content.
• Modify the pnpm-lock.yaml file (without changing package.json) to verify that pnpm install correctly re-evaluates dependencies and the cache mechanism works as expected.
• Verify that the caching for pnpm dependencies correctly speeds up subsequent runs on the same branch/PR and invalidates appropriately when pnpm-lock.yaml changes.
• Confirm that the specified Node.js version (20) is correctly used and that the pnpm installation is successful and functional within the CI environment.

⚠️ Edge Cases & Security

• Verify the actual behavior of on.pull_request.branches: [""] - does it correctly trigger on intended branches, all branches, or no branches at all? This is a critical configuration detail.
• Submit a Pull Request with a very large number of file changes or a particularly heavy build process to assess CI performance and resource limits.
• Introduce a dependency vulnerability (e.g., by downgrading a package to a known vulnerable version) to see if any hidden security scans exist or if the build fails due to security policies (though none are explicitly added in this PR).
• Test scenarios where pnpm-lock.yaml is out of sync with package.json to ensure dependency installation handles it gracefully (or fails appropriately).
• Trigger multiple Pull Requests simultaneously to verify the CI system handles parallel job executions without conflicts or unexpected delays.
• Vulnerabilities in the third-party GitHub Actions used (actions/checkout, pnpm/action-setup, actions/setup-node). Ensure they are pinned to specific versions (e.g., @v4) for stability and security.
• Accidental exposure of sensitive environment variables or tokens if verbose logging is enabled or commands output unexpected data.
• Potential for supply chain attacks if a compromised dependency is introduced through pnpm install during the build process. While not explicitly added here, a future enhancement could be dependency vulnerability scanning.
• Ensure the default permissions of the GITHUB_TOKEN are appropriate for the CI jobs and not overly permissive, especially for external contributions.

---

Generated by PullShark AI

[pullsharksite]

🦈 PullShark AI Analysis

Risk Level: 🔴 High

🧪 Recommended Tests

• Open a pull request with valid, passing code: Verify all CI jobs (typecheck, build, tests) complete successfully.
• Open a pull request with a deliberate type error: Verify the 'Typecheck' job fails as expected.
• Open a pull request with a deliberate build error (e.g., syntax error preventing compilation): Verify the 'Build' job fails as expected.
• Open a pull request with a failing unit test: Verify the 'Test' job fails as expected.
• Open a pull request that introduces errors in one stage but not others (e.g., typecheck passes, build fails): Verify only the intended job fails and others pass or are skipped correctly.
• Open a pull request that only modifies a non-source code file (e.g., README.md): Verify the CI runs and passes, confirming it triggers on all PRs.
• Verify the correct Node.js version (20) and pnpm setup are utilized as specified in the workflow steps.
• Monitor the execution time of the jobs to ensure they complete within an acceptable timeframe, especially for average-sized PRs.
• If the branches: [""] configuration is indeed a placeholder for a specific branch (e.g., 'main'), test opening a PR to that target branch.

⚠️ Edge Cases & Security

• Pull request opened to a branch not explicitly listed in branches configuration (given branches: [""] which is unusual and might imply all branches or a misconfiguration).
• Dependency installation failure (e.g., pnpm issues, network errors).
• Typecheck failure due to intentional code errors in the PR.
• Build failure due to intentional code errors in the PR.
• Test suite failure due to intentional code errors in the PR.
• Very large pull request (many files/lines changed) impacting CI performance and runtime.
• Concurrent pull requests being opened, ensuring parallel job execution does not cause conflicts or timeouts.
• Changes introduced to the workflow file (.github/workflows/ci.yml) itself - ensuring the workflow can validate its own changes.
• Changes made only to non-source code files (e.g., documentation, comments) to ensure the CI runs and passes as expected.
• Potential for supply chain attacks if actions/checkout, pnpm/action-setup, or actions/setup-node (or any future npm dependencies) are compromised.
• Risk of resource exhaustion or denial-of-service if malicious code were to be introduced that triggers excessively long or resource-intensive jobs on GitHub Actions runners.
• Exposure of sensitive information if future steps involve environment variables or secrets that are not properly masked or secured.

---

Generated by PullShark AI

[pullsharksite]

🦈 PullShark AI Analysis

Risk Level: 🔴 High

🧪 Recommended Tests

• Create a PR with valid code changes (including type changes, buildable code, passing tests) to verify all 'typecheck', 'build', and 'test' jobs pass as expected.
• Introduce a type error in a PR to confirm the 'typecheck' job fails appropriately and blocks the PR.
• Introduce a syntax or compilation error in a PR to confirm the 'build' job fails appropriately and blocks the PR.
• Introduce a failing unit/integration test in a PR to confirm the 'test' job fails appropriately and blocks the PR.
• Verify the CI workflow triggers only on 'pull_request' events and not on other events (e.g., 'push' to a non-PR branch).
• Push new commits to an existing open PR to ensure CI re-runs correctly and updates the PR status.
• Create a PR that updates 'package.json' and 'pnpm-lock.yaml' to ensure 'pnpm install' and subsequent steps handle dependency changes correctly.
• Confirm that the correct Node.js version and pnpm are installed and utilized by the workflow steps.
• Verify that the CI status (pass/fail) is correctly reported back to the GitHub PR status checks.
• Monitor the execution time of the CI jobs to establish a baseline and identify potential performance bottlenecks.

⚠️ Edge Cases & Security

• Verify CI triggers correctly for various target branches (e.g., 'main', 'develop', feature branches) as the 'branches: [""]' configuration is unusual and might limit triggering.
• PRs containing only documentation or non-code changes (e.g., '.md' files) to ensure CI either skips relevant steps or passes quickly without unnecessary resource consumption.
• PRs that modify only the CI workflow file itself, to prevent unintended recursive triggers or validation issues.
• Assess CI performance and stability with unusually large PRs or in a complex monorepo structure (if applicable).
• Simulate or consider scenarios where external dependencies (e.g., package registry issues) cause 'pnpm install' to fail gracefully.
• Verify CI runs independently and correctly for multiple PRs opened simultaneously.
• Ensure the 'permissions: contents: read' is sufficient and no additional, less secure permissions are implicitly granted or required by future steps.
• Confirm that all GitHub Actions (e.g., 'actions/checkout', 'pnpm/action-setup') are pinned to a specific commit SHA or major version to prevent unexpected behavior from upstream changes.
• Verify no sensitive information (e.g., tokens, private keys) is exposed directly within the workflow file or logs.

---

Generated by PullShark AI