1. Topics
  2. [release] [OpenDaylight Infrastructure] Autorelease carbon failed to build packetcable-policy-karaf from packetcable

[release] [OpenDaylight Infrastructure] Autorelease carbon failed to build packetcable-policy-karaf from packetcable

Anil Belur <abelur@...>
 


> According to
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-carbon/552/_sys-info.log.gz
>
> we are maxing out the 150 GB disk. Did something change recently that
> is causing significantly more logging to take place?

This might be related to https://git.opendaylight.org/gerrit/69529 — we
keep Pax Exam runtime trees so we can extract the Karaf logs...
 

I see we may only be copying the karaf logs and not runtime generated files, while these logs are preserved into `$WORKSPACE/archives` and published into log server.
It would be good to remove Pax runtime trees/files after the logs are copied. 

Thanks,
Anil
Robert Varga <nite@...>
 

On 05/04/18 11:26, Stephen Kitt wrote:
On Thu, 5 Apr 2018 19:16:08 +1000
Anil Belur <abelur@...> wrote:
According to
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/
autorelease-release-carbon/552/_sys-info.log.gz

we are maxing out the 150 GB disk. Did something change recently
that is causing significantly more logging to take place?
This might be related to https://git.opendaylight.org/gerrit/69529
— we keep Pax Exam runtime trees so we can extract the Karaf logs...
I see we may only be copying the karaf logs and not runtime generated
files, while these logs are preserved into `$WORKSPACE/archives` and
published into log server.
It would be good to remove Pax runtime trees/files after the logs are
copied.
I don’t think that would be sufficient. We’d really need to move the
Karaf logs out of the way and delete Pax runtime trees during the
build.
Or perhaps have SFT configure karaf to log outside of the pax tree and
not keep it?

Regards,
Robert

?
signature.asc

1 - 2 of 2