Hi, Regarding CI of javadoc and site on PRs, I personally prefer to have failures as early as possible rather than during a last manual minute check before a release. Personal opinion again, I prefer to have this automated rather than manual. especially for javadoc which can have different results depending on jdk level and jdk distribution. If you don't want to have this as automatic you can probably change the goals used for some projects you're working on (if others agree) but I agree we probably do not need all possible combinations of os/maven versions/jdks. Long story short regarding Jenkins. A few weeks ago, there were some security issues reported by ASF Infra on the home made plugin [1] used by our jenkins jobs. (sorry but I don't like to report in public what could be potential security issues) And furthermore some scalability issues (too many requests to gitbox [2] which were overloading the gitbox servers and preventing other Apache projects to work correctly. Infra asked me to help fix that so I volunteer in my spare time to help fix those issues. As this home made plugin is not maintained anymore and nobody really wants to maintain it, it was a better option to use the out of the box github integration provided by the Jenkins community. It turns out using it automatically adds checks on github. (I'm sorry but this is something I didn't know or haven't figured out as a side effect). As the setup of this is really new, it might need some extra configurations (sorry as it's on my spare time I can miss some requests because of lack of spare time) and some configuration have been changed (such name which could have generated some wrong links) If I look at your PR here [3], I can see the 2 first checks from Jenkins are some wrong links (sorry for this but I need to investigate as I don't know the cause of this) other than that the other links are related to a test failure. Please explain if this is a false failure because of some wrong setup or some issues on the node used for this build. I will be happy to assist and report to ASF infra if needed. It was interesting to test some parallel tools and I was even happy to help participate in adding some tooling for gh especially because it's easier to have very large combinations of os/jdk/ for plugins such as compiler/javadoc which really needs to be tested on the biggest matrix possible. But I'm not sure we decided to remove Jenkins, personally I tend to prefer using Jenkins as it has a better UI for looking at reports (finding the stack trace related to a test failure is just so much easier) and more generally I prefer using open source as much as possible.
cheers Olivier [1] https://github.com/apache/infrastructure-jenkins/ [2] https://gitbox.apache.org/repos/asf [3] https://github.com/apache/maven-resolver/pull/156 On Fri, 25 Feb 2022 at 07:49, Tamás Cservenák <ta...@cservenak.net> wrote: > Olivier, > > please remove all the Jenkins checks from all of the Maven builds you added > without asking anyone about adding it. > The release manager should ensure beforehand it is all ok, if not, try to > fix it, if the issue is bigger, still can decide to rollback the change. > > Thanks > T > > > > On Thu, Feb 24, 2022 at 10:14 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > Building javadoc is slow and very fragile (fetches remote resources, > chews > > on stuff etc). > > Why not have a savvy release manager ensuring it is building, and calling > > out PR authors to fix it? > > The Worst can happen is rel mgr rollback the chnge if the PR author is > > unresponsive. > > > > On Thu, Feb 24, 2022 at 10:01 PM Olivier Lamy <ol...@apache.org> wrote: > > > >> Please read what I say. I'm just mentioning javadoc as contributors > >> and committers can fail the build with bad javadoc but we will not see > it. > >> > >> On Fri, 25 Feb 2022 at 06:47, Tamás Cservenák <ta...@cservenak.net> > >> wrote: > >> > >> > Building everything for each commit is insane. > >> > > >> > Also, I find a release mgr that does NOT check is site building > >> beforehand > >> > release as sloppy. > >> > > >> > Hence, building everything on each commit just to suit sloppy release > >> mgrs > >> > is insane IMHO. > >> > > >> > My 5 cents. > >> > > >> > T > >> > > >> > On Thu, Feb 24, 2022 at 9:30 PM Olivier Lamy <ol...@apache.org> > wrote: > >> > > >> > > Sounds good. > >> > > But who has never released something and having javadoc failing in > >> the > >> > > middle of the release or the site generation failing once tag done > and > >> > > artifacts staged… I find this a pain 😀 > >> > > > >> > > Maybe only testing javadoc works at least ? > >> > > > >> > > Btw I agree some reports could be removed > >> > > > >> > > On Fri, 25 Feb 2022 at 6:24 am, <herve.bout...@free.fr> wrote: > >> > > > >> > > > and reporting profile was done for this: > >> > > > - without reporting profile, just light site generation > >> > > > - with reporting profile, full documentation site > >> > > > > >> > > > disabling reporting profile for CI should do the job > >> > > > > >> > > > ----- Mail original ----- > >> > > > De: "herve boutemy" <herve.bout...@free.fr> > >> > > > À: "Maven Developers List" <dev@maven.apache.org> > >> > > > Envoyé: Jeudi 24 Février 2022 21:21:45 > >> > > > Objet: Re: Review of used reports for Maven project sites. > >> > > > > >> > > > done on GH and Jenkins, then on each commit? > >> > > > we're heating oceans for nothing > >> > > > > >> > > > IMHO, we need to differentiate CI vs release documentation: CI > >> should > >> > be > >> > > > much lighter than release > >> > > > > >> > > > ----- Mail original ----- > >> > > > De: "Slawomir Jaranowski" <s.jaranow...@gmail.com> > >> > > > À: "Maven Developers List" <dev@maven.apache.org> > >> > > > Envoyé: Jeudi 24 Février 2022 20:53:49 > >> > > > Objet: Re: Review of used reports for Maven project sites. > >> > > > > >> > > > Yes is done after release but also on jenkins for plugins and on > GH > >> > > builds > >> > > > > >> > > > czw., 24 lut 2022 o 20:43 <herve.bout...@free.fr> napisał(a): > >> > > > > >> > > > > full site building with reports enabled (through reporting > >> profile) > >> > is > >> > > > > just done after release, isn't it? > >> > > > > > >> > > > > ----- Mail original ----- > >> > > > > De: "Slawomir Jaranowski" <s.jaranow...@gmail.com> > >> > > > > À: "Maven Developers List" <dev@maven.apache.org> > >> > > > > Envoyé: Jeudi 24 Février 2022 20:24:56 > >> > > > > Objet: Review of used reports for Maven project sites. > >> > > > > > >> > > > > Hi, > >> > > > > > >> > > > > Building the Maven site takes a long time for our projects. > >> > > > > > >> > > > > Before releasing the next version of maven-parent, I have a > >> proposal > >> > to > >> > > > > review used Maven site reports. > >> > > > > > >> > > > > So > >> > > > > > >> > > > > - without reporting profile, standard > >> > > maven-project-info-reports-plugin > >> > > > - > >> > > > > build very quick - no problems > >> > > > > > >> > > > > - with reporting profile: > >> > > > > - surefire - require test phase - can have influence on > build > >> > time > >> > > > > - checkstyle > >> > > > > - pmd > >> > > > > - jxr - needed by other reports > >> > > > > - taglist > >> > > > > - javadoc - require generate-sources > >> > > > > > >> > > > > - for plugins and extensions additional invoker report is added. > >> > > > > > >> > > > > I starting to think what of benefit we have, who is looking at > >> > reports > >> > > > > like: surefire, checkstyle, pmd, taglist > >> > > > > Maybe they are redundant - tests, checkstyle verification simply > >> must > >> > > > pass > >> > > > > > >> > > > > -- > >> > > > > Sławomir Jaranowski > >> > > > > > >> > > > > > >> --------------------------------------------------------------------- > >> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > >> > > > > > >> > > > > >> > > > -- > >> > > > Sławomir Jaranowski > >> > > > > >> > > > > >> --------------------------------------------------------------------- > >> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > >> > > > > >> > > > >> > > >> > > >
