feat: sync chrome-for-testing json files #737
Conversation
WalkthroughThe changes in this pull request involve modifications to the Changes
Assessment against linked issues
Possibly related PRs
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #737 +/- ##
=======================================
Coverage 96.39% 96.39%
=======================================
Files 191 191
Lines 18995 19017 +22
Branches 2498 2498
=======================================
+ Hits 18310 18332 +22
Misses 685 685 ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
test/common/adapter/binary/ChromeForTestingBinary.test.ts (1)
20-28: LGTM! Consider extracting test constants.The test assertions comprehensively validate the new JSON files' properties. However, consider extracting the timestamp and file names into constants to improve test maintainability.
+ const TEST_TIMESTAMP = '2023-09-16T00:21:21.964Z'; + const JSON_FILES = { + KNOWN_GOOD_VERSIONS: 'known-good-versions-with-downloads.json', + LATEST_PATCH_VERSIONS: 'latest-patch-versions-per-build.json', + LAST_KNOWN_GOOD: 'last-known-good-versions.json', + }; assert.equal(result?.items[0].name, JSON_FILES.KNOWN_GOOD_VERSIONS); assert.equal(result?.items[0].date, TEST_TIMESTAMP);app/common/adapter/binary/ChromeForTestingBinary.ts (3)
49-69: Consider centralizing URLs and improving size handling.The implementation successfully adds the required JSON files, but there are a few potential improvements:
- The URLs could be centralized as constants to avoid duplication and make updates easier
- The size property is hardcoded to '-', consider fetching actual file sizes or removing if not needed
+ private static readonly BASE_URL = 'https://googlechromelabs.github.io/chrome-for-testing'; + private static readonly JSON_FILES = { + KNOWN_GOOD_VERSIONS: 'known-good-versions-with-downloads.json', + LATEST_PATCH_VERSIONS: 'latest-patch-versions-per-build.json', + LAST_KNOWN_GOOD: 'last-known-good-versions.json', + }; - const jsonApiEndpoint = 'https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json'; + const jsonApiEndpoint = `${ChromeForTestingBinary.BASE_URL}/${ChromeForTestingBinary.JSON_FILES.KNOWN_GOOD_VERSIONS}`;
Line range hint
29-41: Consider adding retry mechanism for HTTP requests.The HTTP request to fetch JSON data lacks a retry mechanism. Given that this is a critical synchronization operation, consider implementing retries with exponential backoff.
+ private async requestWithRetry(url: string, maxRetries = 3, initialDelay = 1000) { + let lastError; + for (let i = 0; i < maxRetries; i++) { + try { + const response = await this.httpclient.request(url, { + dataType: 'json', + timeout: 30000, + followRedirect: true, + gzip: true, + }); + return response; + } catch (error) { + lastError = error; + await new Promise(resolve => setTimeout(resolve, initialDelay * Math.pow(2, i))); + } + } + throw lastError; + }
Line range hint
42-48: Consider caching the fetched data.Since the data is timestamped and only needs to be updated when changed, consider implementing a caching mechanism to reduce unnecessary HTTP requests.
This could be implemented using:
- In-memory cache with TTL
- File-system cache with timestamp validation
- Distributed cache if running in a cluster
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
app/common/adapter/binary/ChromeForTestingBinary.ts(1 hunks)test/common/adapter/binary/ChromeForTestingBinary.test.ts(1 hunks)
🔇 Additional comments (1)
app/common/adapter/binary/ChromeForTestingBinary.ts (1)
Line range hint 29-41: Verify HTTPS certificate validation.
While the implementation uses HTTPS URLs, ensure that certificate validation is properly enforced in the HTTP client configuration.
✅ Verification successful
Based on the analysis of the configuration files and HTTP client usage, I can now provide a final response:
HTTPS certificate validation is properly enforced by default
The HTTP client configuration in config.default.ts shows that the application uses secure defaults:
- Uses HTTPS URLs for external services
- No certificate validation disabling settings found
- HTTP client is configured with secure defaults:
useHttpClientNext: true, allowH2: true - No
rejectUnauthorized: falseorstrictSSL: falsesettings found in the codebase
The implementation is secure as it maintains proper certificate validation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify HTTPS certificate validation settings in the codebase
# Check for certificate validation settings
rg -l "rejectUnauthorized.*false" .
rg -l "strictSSL.*false" .
Length of output: 66
Script:
#!/bin/bash
# Let's check the HTTP client implementation and configuration
# First, find the HTTP client implementation
ast-grep --pattern 'class $_ implements HttpClient'
# Also check for any HTTP-related configuration
rg -l "httpclient.*config" .
# Check the actual HTTP client usage and configuration
rg "new.*HttpClient" -A 5
Length of output: 197
Script:
#!/bin/bash
# Let's check the content of the files that have HTTP client config
cat ./app/core/service/BinarySyncerService.ts ./app/core/service/PackageSyncerService.ts
# Also check for any HTTP-related imports to find the client implementation
rg "import.*Http" -A 1
# Check for any security-related configuration in the application
rg -i "ssl|tls|certificate|secure" .
Length of output: 132435
Script:
#!/bin/bash
# Let's check the HTTP client configuration in the application
# First, check for any HTTP client configuration files
rg -l "httpclient.*config" config/
# Then check the HTTP client initialization and configuration
ast-grep --pattern 'new EggHttpClient($$$)'
# Also check for any HTTPS/SSL configuration in config files
rg -l "https|ssl|secure" config/
Length of output: 369
Script:
#!/bin/bash
# Let's check the default configuration for HTTP client and HTTPS settings
cat config/config.default.ts
# Also check the binaries configuration for any HTTPS settings
cat config/binaries.ts
# Check for any HTTP client options in the codebase
rg "httpclient.*options" -A 3
Length of output: 40333
[skip ci] ## [3.71.0](v3.70.0...v3.71.0) (2024-11-30) ### Features * sync chrome-for-testing json files ([#737](#737)) ([9bb12fd](9bb12fd))
closes #730
Summary by CodeRabbit
New Features
Bug Fixes
Tests