-
-
Notifications
You must be signed in to change notification settings - Fork 323
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
ci: always run setup_ci #3258
ci: always run setup_ci #3258
Conversation
For some reason if these jobs are both run on ci sequentially, the second one fails in the match phase. I think setup_ci lets the previous run's keychain get used for the subsequent run's, and then something fails. In any case, these are the only jobs that don't call this with force: true.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3258 +/- ##
=============================================
+ Coverage 89.143% 89.145% +0.001%
=============================================
Files 502 502
Lines 54133 54152 +19
Branches 19422 19431 +9
=============================================
+ Hits 48256 48274 +18
Misses 5018 5018
- Partials 859 860 +1 see 11 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
The issue this PR sets out to solve is fixed, as the test apps build now. There is a downstream issue with how the test is actually run. |
Performance metrics 🚀
|
Revision | Plain | With Sentry | Diff |
---|---|---|---|
cd39d58 | 1203.87 ms | 1239.88 ms | 36.01 ms |
01a28a9 | 1237.33 ms | 1256.52 ms | 19.20 ms |
2f8b3a8 | 1233.76 ms | 1260.24 ms | 26.48 ms |
60d6cec | 1257.14 ms | 1273.92 ms | 16.78 ms |
4654f66 | 1247.16 ms | 1263.96 ms | 16.80 ms |
c50d363 | 1215.10 ms | 1231.82 ms | 16.72 ms |
7fb7afb | 1235.00 ms | 1256.81 ms | 21.81 ms |
257c2a9 | 1231.45 ms | 1252.12 ms | 20.67 ms |
c00eafe | 1253.04 ms | 1256.41 ms | 3.37 ms |
c6773e5 | 1222.48 ms | 1240.02 ms | 17.54 ms |
App size
Revision | Plain | With Sentry | Diff |
---|---|---|---|
cd39d58 | 20.76 KiB | 435.26 KiB | 414.50 KiB |
01a28a9 | 22.85 KiB | 405.39 KiB | 382.55 KiB |
2f8b3a8 | 20.76 KiB | 434.72 KiB | 413.96 KiB |
60d6cec | 22.84 KiB | 403.51 KiB | 380.67 KiB |
4654f66 | 20.76 KiB | 432.17 KiB | 411.41 KiB |
c50d363 | 20.76 KiB | 432.68 KiB | 411.92 KiB |
7fb7afb | 20.76 KiB | 419.69 KiB | 398.94 KiB |
257c2a9 | 20.76 KiB | 401.36 KiB | 380.60 KiB |
c00eafe | 20.76 KiB | 432.88 KiB | 412.12 KiB |
c6773e5 | 20.76 KiB | 435.25 KiB | 414.49 KiB |
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.
LGTM
For some reason if these jobs are both run on ci sequentially, the second one fails in the match phase. I think setup_ci lets the previous run's keychain get used for the subsequent run's, and then something fails. In any case, these are the only jobs that don't call this with force: true.
This is also failing nondeterminstically; sometimes it works on PRs, sometimes not.
#skip-changelog