Hello. Le sam. 4 avr. 2020 à 17:13, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > > > On 4 Apr 2020, at 01:49, Bruno P. Kinoshita <ki...@apache.org> wrote: > > > > Build passed locally from tag, with `mvn clean test install site` after > > 21mins > > Hi Bruno, > > This is a known issue with the multi-module build when the ‘site-content’ > directory is missing and you run the ‘site’ target as it downloads the > existing site. It does this for each module. The more modules, the bigger the > problem.
IMO it is a misfeature, independent of whether the component is multi-module or not. What's the purpose of checking out the (live) site into "site-content" when the build is creating the new site in "target/site" (or "target/staging")? It is a fact that we never vote on the contents of the web site, not even for a release vote (since in that case, many links are broken). So, IMHO, the vote for a release should skip any site check, and when the release it is a convienience (as it is now) that the site is maintained up-to-date (by anyone, not necessarily the RM). Then, populating the directory "site-content" (by deleting the old content and copying from the build run within the release branch) is a separate and well defined task (done *after* the release, avoiding the "dangling links" issue). > The site-content folder is just a convenience when staging a new site during > a release. Inconvenience, you mean. ;-) > Perhaps this entire process should be rethought as the directory serves no > other purpose that I know of. +1 (as mentioned above). > > This has been fixed in commons RNG using a custom setup-checkout profile. > Either we: > > 1. copy the solution in commons RNG which does the checkout only for the > parent module and creates a dummy directory for child modules, or > 2. change the profile to not automatically trigger when ’site-content’ is > missing. The profile can be optional and used only in the release process > when staging the site. I think that "site-content" should be left alone by the build. Moreover I think that it's a bad idea to have a directory managed by "svn" under a directoy managed by "git". When someone wants to update a component's web site, he could just "svn co" into a separate area of the filesystem. > > Note that the site generates automatically without this folder. If you create > an empty folder 'site-content' and run 'mvn site' then it all works fine. That's *the* workaround, but it's easy to forget and then use a lot of bandwidth for nothing... :-} > > A clean checkout from the tag: > > mvn package site > > 12:58 min > > > Clean check from the tag: > > mkdir ./commons-numbers-arrays/site-content > mkdir ./commons-numbers-field/site-content > mkdir ./commons-numbers-gamma/site-content > mkdir ./commons-numbers-fraction/site-content > mkdir ./commons-numbers-core/site-content > mkdir ./commons-numbers-angle/site-content > mkdir ./commons-numbers-primes/site-content > mkdir ./commons-numbers-combinatorics/site-content > mkdir ./commons-numbers-rootfinder/site-content > mkdir ./site-content > mkdir ./commons-numbers-complex/site-content > mkdir ./commons-numbers-quaternion/site-content > mvn package site > > 3:46 min > > So disabling the profile to checkout the site would save 2/3 of the build > time from a clean checkout. Note: Currently a repeat build in the same git > clone is fast as the site-content directory already already exists. > > The multi-module build also takes a while generating the site as the Jira > report is built for each module and this is the slowest report. We have three > options here. > > 1. Build the full Jira report in each sub-module > 2. Disable the Jira report in each sub-module > 3. Build a partial Jira report in each sub-module > > In RNG we use option 3. The partial report is built using keyword tags on the > Jira tickets to identify to a module. The report then only contains items > that relate to the module. This is useful but the site generation takes the > same amount of time because generation of a full Jira report or partial > report takes the same time. It also requires diligent keyword tagging of > tickets. As long as the release notes contain a collated list of all the components' issues (so that users can quickly figure out if they would be impacted by upgrading, and whatever new features are available), I think that it's the cleanest option. Best regards, Gilles > > Alex > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
