-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[typescript-migration] some tests and configs #4891
[typescript-migration] some tests and configs #4891
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4891 +/- ##
=======================================
Coverage 96.64% 96.65%
=======================================
Files 28 28
Lines 3251 3254 +3
Branches 1354 1342 -12
=======================================
+ Hits 3142 3145 +3
- Misses 105 109 +4
+ Partials 4 0 -4 ☔ View full report in Codecov by Sentry. |
7dd9e49
to
6058bbc
Compare
6b70152
to
7416c44
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ This pull request was sent to the PullRequest network for review. Expert reviewers are now being matched to your request based on the code's requirements. Stay tuned!
What to expect from this code review:
- Comments posted to any areas of potential concern or improvement.
- Detailed feedback or actions needed to resolve issues that are found.
- Turnaround times vary, but we aim to be swift.
@yuki0410-dev you can click here to see the review status or cancel the code review job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PullRequest Breakdown
Reviewable lines of change
+ 639
- 597
94% TSX (tests)
6% JavaScript
<1% GitHubActions (tests)
Type of change
Feature - These changes are adding a new feature or improvement to existing code.
e531b2d
to
0263278
Compare
@@ -30,8 +30,6 @@ jobs: | |||
with: | |||
path: ${{ steps.yarn-cache-dir-path.outputs.dir }} | |||
key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }} | |||
restore-keys: | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you expand on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martijnrusschen
"restore-keys" searches cache by forward matching and uses the latest cache hit.
I have finished the ts-jest migration. (CI was ok).
I removed babel-jest as it is no longer needed. (CI was NG as the version dependency of the module used internally seemed to be broken.)
Drop the commit of ↑ (CI was NG as well as ↑)
From the above, I think it is a good idea to reduce CI time by using close cache as a base for yarn install, though,
However, if a cache with incorrect dependencies remains somewhere, there is a risk that subsequent CI will be NG, including other branches, so I thought it would be better to remove it.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the intent of this cache is to reduce the CI time overall since it gets pretty slow if you don't have this. I haven't seen issues with cache hits before on dependency changes. I'd assume it would not match if there's a change in the yarn lock file since we use that in the key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martijnrusschen
Indeed, cache is created with hash and os in yarn.lock as keys.
However, according to the official documentation, if restore-keys is set, when using cache, it first searches for cache using hash and os in yarn.lock as keys; if cache is a hit, it is used, but if not, only os is used as key. If there is no hit, the repository is configured to use the most recent cache with only os as a key.
https://github.com/actions/cache?tab=readme-ov-file#inputs
I would expect that removing this setting will not slow down all PR CIs, but will make them take longer because cache is no longer allocated to PR CIs that include some yarn.lock changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latest CI shows that cache is being used correctly without restore-keys as long as yarn.lock has not been changed.
Run actions/cache@v4
Received 301[9](https://github.com/Hacker0x01/react-datepicker/actions/runs/9486148892/job/26139812754?pr=4891#step:5:10)89888 of 651797708 (46.3%), 287.1 MBs/sec
Cache Size: ~622 MB (651797708 B)
/usr/bin/tar -xf /home/runner/work/_temp/fbc7044b-c1cb-40eb-a8[10](https://github.com/Hacker0x01/react-datepicker/actions/runs/9486148892/job/26139812754?pr=4891#step:5:11)-6c1a5ad6255b/cache.tzst -P -C /home/runner/work/react-datepicker/react-datepicker --use-compress-program unzstd
Received 651797708 of 651797708 (100.0%), 310.2 MBs/sec
Cache restored successfully
Cache restored from key: Linux-yarn-d94afddf929d782fe04721c5606e6ca65a0a1ee89384f90043903a1cc9339958
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok thanks for clarifying, that sounds like a good approach to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a major milestone! I think this marks the complete conversion to TS. Nice work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only one comment about the non-null assertion when coupled with the assert truthy - otherwise no concerns.
Reviewed with ❤️ by PullRequest
Description
Linked issue: #4700
Changes
Contribution checklist