[
https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138580#comment-17138580
]
Matthieu Baechler commented on JAMES-3225:
------------------------------------------
> 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.
People at Linagora have a Jenkins running on every PR made on james-project.
Sadly, this Jenkins instance is private thus is of no use to the community.
However it's probably the reason why nobody took care of having a CI build
setup @ Apache.
> There are lots of things to take into consideration.
> My ( Ioan Eugen Stan ) opinions on how to handle this.
> builds should run automatically
You lack the "on what" part IMO. My opinion is: on all maintained branches for
every change made to the branch but also on every PR before it can be merged.
> builds should run fast < 10 min
And we should ban war too. More seriously, it depends on a lot of things (the
CI infrastructure being one of them) and setting a time budget for the tests to
run is a good way to drop valuable tests.
Let's first discuss what we want and don't want in term of test coverage first.
> 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
Not only. Functional tests and integration tests are also slow even for
non-distributed case.
> Given the limited resources available for us on the Apache infrastructure we
> will have to be selective of what we do.
Do you have information about that?
> 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
Profiles are just a technical solution to split things in subsets so let's not
debate that.
The real question for me is: should we merge a PR without having the results of
the full testsuite. I'm very opinionated about that and my answer is: no.
The consequence of allowing such merge is that people have to fix what is
merged on main branches but contributors could very well be gone at that time.
The main branches will begin to be untested and the confidence in tests will
lower to the point nobody will care to run them any longer.
Given how many bugs we detect with these tests, I don't want that to happen.
So let's consider other options if you want.
> 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 do that with each release. It doesn't help much.
> 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/ .
What do you think they do well?
Options, in my opinion are:
* make wall clock testsuite duration around 20 minutes (I know that it's doable
because I already did the maths). It requires heavy parallelism.
* check what is the computing budget we have @ ASF for running testsuites on
Jenkins
* check if ASF allows to use external servers for CI
* check if ASF accepts donation of computing power for a given project
What do you think?
> 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
