[
https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280858#comment-17280858
]
ASF GitHub Bot commented on JAMES-3225:
---------------------------------------
jeantil commented on a change in pull request #264:
URL: https://github.com/apache/james-project/pull/264#discussion_r571868651
##########
File path:
backends-common/cassandra/src/test/java/org/apache/james/backends/cassandra/DockerCassandra.java
##########
@@ -118,11 +126,36 @@ private void grantPermissionToTestingUser(Cluster
privilegedCluster, String keys
@SuppressWarnings("resource")
public DockerCassandra() {
- this("cassandra_3_11_3", AdditionalDockerFileStep.IDENTITY);
+ this("cassandra_3_11_3-"+ UUID.randomUUID().toString(),
AdditionalDockerFileStep.IDENTITY);
Review comment:
I have a few ideas of things to try but indeed I would really like to
stop maintaining this extremely long lived branch :(
There are 2 reasons to use unique names:
- it allows for concurrent runs on the same machine (which is a possible
cause for [docker cache
errors](https://github.com/apache/james-project/pull/264#issuecomment-762826374)
)
- it makes it easier to diagnose other docker cache related failures. Our
working hypothesis here is that there may be a garbage collection process on
apache CI which removes images that are not currently in use. it might be a bit
too aggressive and collect images that were just build right before we start
them. We added detailed logging of docker events in 28d0de15 to diagnose this
further
There are a few more ideas for optimization one of the things I intend to
try is running in
[dockerfile](https://www.jenkins.io/doc/book/pipeline/docker/#dockerfile) to be
closer to how linagora's build works
I also want to merge the [COW
fix](https://github.com/apache/james-project/pull/282) and revert "unstable" in
a specific branch to see how it impacts both build time and stability
last but not least I hope to find some time in the future to investigate the
root cause for the `OutOfMemoryError : Direct buffer memory` which forced me to
drop surefire fork reuse. I did some preliminary research and it is most likely
a memory leak of off-heap memory. The leak is "resolved" by dropping forks but
likely indicates a deeper issue probably with incorrectly sized buffers. Once
the leak is resolved we should be able to reactivate reuseFork whih would
massively speed up the build (it suceeded once with reuseFork and took around
3h)
----------------------------------------------------------------
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:
[email protected]
> 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
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
