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

Benoit Tellier commented on JAMES-3225:
---------------------------------------

> With my Apache hat on:

+1

The current situation is not acceptable.

> ASF does accept donations.

After having read the page you linked it looks we could be working on the 
following solution: Linagora donates (most of) our current CI infrastructure so 
that we could build everything on Apache GitHub repository the way we currently 
do on Linagora one.

Of course we would have to :

 - Ensure we could run current build & test suite. (Can we launch docker 
containers on Apache Jenkins CI?)
 - Of course discuss this internally. There might be some legal aspects...

We won't get the 20 minute build but we could be working on progressive 
improvements for it. And we would be more open.

I agree to defend this option.

> Provide automated builds for Apache James - (restore builds.apache.org ?) 
> --------------------------------------------------------------------------
>
>                 Key: JAMES-3225
>                 URL: https://issues.apache.org/jira/browse/JAMES-3225
>             Project: James Server
>          Issue Type: Task
>            Reporter: Ioan Eugen Stan
>            Assignee: Ioan Eugen Stan
>            Priority: Major
>
> For a long time we had builds that ran on the Apache Infrastructure 
> https://builds.apache.org/view/All/job/james-mailet/ .
> The build infrastructure is not running for ~ 3 years now. 
> I believe it is important for us to have automated builds. 
> This ticket should gather the work needed to make this a reality.
> There are lots of things to take into consideration.
> My ( [~ieugen] ) opinions on how to handle this.
> * builds should run automatically
> * builds should run fast < 10 min
> * there are several things they should do (not exhaustive)
> ** verify the source code
> ** compile the source code
> ** run the unit tests
> ** run the integration tests 
> ** publish SNAPSHOTS (only from master or develop ?!)
> ** run code analytics
> ** publish reports relating to build
> ** provide build status for other services
> For smaller projects this is a no-brainer.
> For the current state of Apache James this is a challange, especially in the 
> context of 
> - multiple git branches and PR's 
> - the distributed integration tests which take a long time
> Given the limited resources available for us on the Apache infrastructure we 
> will have to be selective of what we do.
> Personally I don't see how we can run the current (40mni +) integration suite 
> on each push / build. I'm pretty sure we will get banned :) or throttled. 
> So a discussion should be in order on how to solve these issues but some 
> options regarding what we can do:
> - make integration tests OPT-IN
> - run (distributed) integration tests once a day or once every 6h / 12h
> - have build profiles that build a common subset all the time and run 
> The nuclear option: prune some of the components we have in James and we 
> don't want to support or move them out of the common project. 
> This is something we should consider especially for buggy components or for 
> components that don't have a maintainer. 
> We have limited time and resources.
> We can't maintain everything for everybody.
> We should be mindful of this.
>  We can take inspiration from the OFBiz project 
> https://builds.apache.org/view/All/job/Apache%20OFBiz/ .



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

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

Reply via email to