search

xvik / generics-resolver

Java generics runtime resolver
https://xvik.github.io/generics-resolver
MIT License
45 stars 9 forks source link

Improve Travis CI build Performance #11

Closed chenzhang22 closed 1 year ago

chenzhang22 commented 3 years ago

According to Build times out because no output was received, we should carefully use travis_wait, as it may make the build unstable and extend the build time.

===================== If there are any inappropriate modifications in this PR, please give me a reply and I will change them.

codecov-commenter commented 3 years ago

Codecov Report

Merging #11 (e042ba2) into master (2c0c321) will increase coverage by 0.15%. The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff              @@
##             master      #11      +/-   ##
============================================
+ Coverage     94.28%   94.44%   +0.15%     
  Complexity      873      873              
============================================
  Files            43       43              
  Lines          1908     1908              
  Branches        407      407              
============================================
+ Hits           1799     1802       +3     
  Misses           24       24              
+ Partials         85       82       -3
Flag Coverage Δ
linux 94.44% <ø> (+0.15%) :arrow_up:
windows 94.28% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...generics/resolver/util/type/CommonTypeFactory.java 87.92% <0.00%> (+1.44%) :arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 2c0c321...e042ba2. Read the comment docs.

xvik commented 3 years ago

According to Build times out because no output was received, we should carefully use travis_wait, as it may make the build unstable and extend the build time.

Documentation actually states: "please think before using this, maybe the problem is in your build (test) and it could be optimized". There is no performance harm in using this (yes, another process tracks the build, but it's nothing comparing, for example, with gradle initialization time).

I really need this option only for one of my projects (with a lot of tests) but use it everywhere by default to avoid looking for this option when another project grows up.

Don't see any good reason to not using it (I know what I'm doing).