[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] [Commented] (JAMES-3500) Fasten the build
From:       "ASF GitHub Bot (Jira)" <server-dev () james ! apache ! org>
Date:       2021-02-18 9:53:00
Message-ID: JIRA.13358112.1613030043000.628148.1613641980482 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/JAMES-3500?page=com.atlassian.jira.plugin. \
system.issuetabpanels:comment-tabpanel&focusedCommentId=17286395#comment-17286395 ] 

ASF GitHub Bot commented on JAMES-3500:
---------------------------------------

jeantil commented on pull request #298:
URL: https://github.com/apache/james-project/pull/298#issuecomment-781222869


   >
   > But if we explicitly decide to only use surefire as a test runner (and
   > perform a scalatest -> junit5 rewrite) that could easily become a
   > non-issue.
   >
   >
   I don't think the rewrite is worth it in the short term. We can decide not
   to write new tests in Scala test and when a reason comes to work on these
   modules include the migration.
   
   What i was thinking of is: when 5 years from now, the project decides to
   include another test framework and we have all collectively forgotten that
   CI only runs for surefire(and maybe scalatest) executions... Then it could
   take a while before someone realizes that CI doesn't validate the build
   correctly[1]
   
   That's the one advantage I see to explicitly excluding plugins executions
   from the test phase [2] instead of running the surefire execution
   explicitly. While it is more work it offers better safety against future
   build modification.
   
   The tradeoff being : the build runs too many things (explicitly disable
   plugins) vs the build doesn't run enough (explicitly enable plugins)
   
   [1] or maybe I just spent too much time fixing builds and I'm biased :)
   
   [2] I don't mean using skip, I mean overriding the default execution to
   force an empty phase so that the plugin is not actually added to the
   effective build (which I think would yield 80% of the time saving - to be
   confirmed by an actual run)
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Fasten the build
> ----------------
> 
> Key: JAMES-3500
> URL: https://issues.apache.org/jira/browse/JAMES-3500
> Project: James Server
> Issue Type: Improvement
> Components: Build System
> Reporter: Benoit Tellier
> Priority: Major
> 
> On master, stable tests takes 5h16 and unstable tests takes 1h51
> Deploy (whatever it means took 1h05)
> Total, this took 8h+
> I can not be productive while waiting a full work-day for a build result, and I \
> believe I am not the only one in that case. I would like to help reduce the total \
> build time down to (say) 3 hours.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]