[RELENG-86] Reduce autorelease build size by converting karaf builds to profiles Created: 05/Apr/18 Updated: 04/May/18 Resolved: 04/May/18 |
|
| Status: | Resolved |
| Project: | releng |
| Component/s: | Autorelease |
| Affects Version/s: | None |
| Fix Version/s: | Carbon-SR4 |
| Type: | Bug | Priority: | Highest |
| Reporter: | Thanh Ha (zxiiro) | Assignee: | Thanh Ha (zxiiro) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Per discussions on mailing list thread: https://lists.opendaylight.org/pipermail/dev/2018-April/004857.html We discovered that Autorelease Carbon build size appears to be significantly larger since the last release. One point that came out of the discussions was that the project local karaf distributions should not be built by autorelease and released as part of simrel. 2 things need to be done here: 1. Patch autorelease builds to ignore the "karaf" profile with "-P!karaf" This method will allow by default the same behaviour that developers are expecting when they run local builds but allows us to disable the karaf distribution in autorelease builds. We need to deploy this to Carbon ASAP however we should do it for all supported releases. For patches suggest using "autorelease-skip-karaf": git review -t autorelease-skip-karaf
For those helping out with patches to test if your patch works run these 2 commands and check the Maven reactor (takes about 30 seconds): 1. mvn clean install The first should include the karaf in the build. The 2nd should not. |
| Comments |
| Comment by Thanh Ha (zxiiro) [ 06/Apr/18 ] |
|
There is an issue with activeByDefault where if the same pom.xml has other profiles that is activated via other methods it disables all of the activeByDefault profiles. We should ensure all the pom.xmls are updated to only have profiles that have activeByDefault. |
| Comment by Thanh Ha (zxiiro) [ 06/Apr/18 ] |
|
First simple patch example with the USC project: |
| Comment by Thanh Ha (zxiiro) [ 06/Apr/18 ] |
|
We need to be careful if a project uses activeByDefault in the same pom.xml then using properties will disable their local profile. In that case we should use activeByDefault to not disturb their local configuration. Which means autorelease needs to disable the profile with "-P!karaf" regardless of activation method. A common case we need to resolve is if a project still has the obsolete maven-site configuration we need to remove it first. Refer to this USC patch as an example: |
| Comment by Thanh Ha (zxiiro) [ 06/Apr/18 ] |
|
To test if your patch works run these 2 commands and check the Maven reactor (takes about 30 seconds): 1. mvn clean install The first should include the karaf in the build. The 2nd should not. |
| Comment by Thanh Ha (zxiiro) [ 06/Apr/18 ] |
|
This patch should disable karaf in the autorelease builds: |
| Comment by Michael Vorburger [ 06/Apr/18 ] |
|
> Autorelease Carbon build size appears to be significantly larger since the last release. It would be interesting to understand why... perhaps we could solve the root cause of this by excluding something somewhere? Perhaps using a tool such as dutree (recommended by rovarga) could shed more light on why we are suddenly consuming that much more space in autorelease than before... |
| Comment by Stephen Kitt [ 06/Apr/18 ] |
|
vorburger, we know why the builds are larger: we’re keeping the Pax Exam builds so we can archive the Karaf logs. |
| Comment by Thanh Ha (zxiiro) [ 07/Apr/18 ] |
|
Patches submitted to all of the Carbon projects: |
| Comment by Thanh Ha (zxiiro) [ 07/Apr/18 ] |
|
Using these filters to track the remaining branches:
|
| Comment by Thanh Ha (zxiiro) [ 07/Apr/18 ] |
|
Big thanks to dfarrell07 for helping out, we completed cherry-picking the patches to all branches for all the autorelease projects. |
| Comment by Thanh Ha (zxiiro) [ 04/May/18 ] |
|
Going to consider this issue resolved since it is no longer preventing autorelease from passing. Patches have been proposed to all of the projects and it's now up to them whether or not to accept them. I will keep pushing for it for active projects participating in the managed release. |