This group is locked. No changes can be made to the group while it is locked.
Date
1 - 5 of 5
[release] Autorelease oxygen failed to build odl-alto-resourcepool from alto
|
Jenkins <jenkins-dontreply@...>
Attention alto-devs,
Autorelease oxygen failed to build odl-alto-resourcepool from alto in build 257. Attached is a snippet of the error message related to the failure that we were able to automatically parse as well as console logs. Console Logs: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-oxygen/257 Jenkins Build: https://jenkins.opendaylight.org/releng/job/autorelease-release-oxygen/257/ Please review and provide an ETA on when a fix will be available. Thanks, ODL releng/autorelease team
|
|
|
|
Gao Kai
Hi releng/autorelease team, As the report suggests, the failure is typically transient and should clear in the next run and no fix is required. Regards, Kai
On Mon, Apr 9, 2018 at 9:32 AM, Jenkins <jenkins-dontreply@...> wrote: Attention alto-devs, --
Kai Gao PhD Candidate at Institute of Network Science and Cyberspace Department of Computer Science and Technology Tsinghua University, Beijing, China
|
|
|
|
Daniel Farrell <dfarrell@...>
Hello Kai, Thanks for the diagnosis. Is there anything that can be done to properly mitigate the failure? We have so many transient potential failures that we're almost certain to hit one on a given autorelease (<=Oxygen, Fluorine should be better because fewer projects in Managed Release). Thanks, Daniel
On Mon, Apr 9, 2018 at 7:17 AM Kai GAO <godrickk@...> wrote:
|
|
|
|
Gao Kai
Hi Daniel and the autorelease team, I don't really know for sure. The module only contains a few source files and takes ~10 seconds to compile/test on my laptop. I remember there were quite a few such failures while compiling ALTO modules (and sometimes other projects), but the compilation managed to go through at a certain point. I don't think the transient failures can be mitigated very well by improving a certain project. One hypothesis is that this could be a JVM issue that it runs short of resources during the compilation. But according to the log, there should still be plenty of memory. Emm... Since most failures happen during single feature tests, it would be one direction to look into. As for solutions, first I would think of something such as incremental compilation or checkpoints. Maven has this "-rf" option to resume a compilation. It may not be a good practice in production systems but I feel it might make some sense in handling transient failures. Another option might be executing the single feature tests after the compilation. As the projects have their own jenkins jobs, they should be less likely to raise compilation errors. Since a success build requires all SFT to pass anyway, I think the order may be less critical. [Don't know whether this is feasible, though :(] Just my two cents. Best, Kai
On Mon, Apr 9, 2018 at 9:50 PM, Daniel Farrell <dfarrell@...> wrote:
--
Kai Gao PhD Candidate at Institute of Network Science and Cyberspace Department of Computer Science and Technology Tsinghua University, Beijing, China
|
|
|
|
Robert Varga <nite@...>
On 09/04/18 15:50, Daniel Farrell wrote:
Hello Kai,Hello, https://jira.opendaylight.org/browse/ODLPARENT-143 is tracking this for some time. Noone is working on it AFAICT. Regards, Robert
|
|
|