czw., 14 lip 2022 o 23:36 Olivier Lamy <ol...@apache.org> napisał(a):
> On Fri, 15 Jul 2022 at 07:30, Olivier Lamy <ol...@apache.org> wrote: > > > > > > > On Thu, 14 Jul 2022 at 19:25, Slawomir Jaranowski < > s.jaranow...@gmail.com> > > wrote: > > > >> I don't think that it is a code problem ... in the most times. > >> > >> eg: > >> > >> > https://ci-maven.apache.org/blue/organizations/jenkins/Maven%2Fmaven-box%2Fmaven-plugin-tools/detail/PR-112/2/pipeline/ > >> > >> Build was failed on three window nodes with error: > >> > >> [INFO] Building: ignore-plugin-class-realm\pom.xml > >> Sending interrupt signal to process > >> Terminate batch job (Y/N)? > >> script returned exit code 1 > >> > >> in the different places > >> > > > >> What can be the reason, how to investigate it? > >> > > > > > > interesting and not sure exactly. > > At least we can/could ask infra how windows nodes are provisioned, and > > eventually look at the code. > > As it's supported by our infra and open source code we still have the > > opportunity to do that and eventually fix something to help the > community. > > but frankly you guys want to get rid of Jenkins. So I do not feel the > > motivation to find some bandwidth for this now. > > Maybe in a few weeks, I will have some time as Jenkins will be still > there > > and I can find a bit of time to look at those sometimes sporadic errors. > > > > > I created this https://issues.apache.org/jira/browse/INFRA-23485. > As you are looking a lot and have figures on this happening a lot etc... > Maybe there is a pattern? > is it happening all the time with invoker plugin when forking anothe mvn? > > > Not always for invoker https://ci-maven.apache.org/blue/rest/organizations/jenkins/pipelines/Maven/pipelines/maven-box/pipelines/maven-plugin-tools/branches/PR-120/runs/2/nodes/331/steps/339/log/?start=0 INFO] --- maven-remote-resources-plugin:1.7.0:process (process-resource-bundles) @ maven-plugin-plugin --- [INFO] Preparing remote bundle org.apache:apache-jar-resource-bundle:1.4 [INFO] Copying 3 resources from 1 bundle. Terminate batch job (Y/N)? script returned exit code 1 > > > > > > >> > >> > >> śr., 13 lip 2022 o 22:56 Olivier Lamy <ol...@apache.org> napisał(a): > >> > >> > On Thu, 14 Jul 2022 at 04:04, Slawomir Jaranowski < > >> s.jaranow...@gmail.com> > >> > wrote: > >> > > >> > > Hi, > >> > > > >> > > To summarize the discussion we have many votes to go this way. > >> > > > >> > > My proposition is as first step remove windows nodes from jenkins > >> > builds, I > >> > > see many fals positive fails on such node ... > >> > > > >> > > >> > false positive or false negative? :) > >> > > >> > > >> > > Next step can be stop building PR by jenkins - it is only triggered > >> for > >> > > dependabot and for branch from repo - not triggered for build PR for > >> > forked > >> > > repo. > >> > > > >> > > >> > we can simply tell Jenkins to stop notify gh pr checks. As I presume > the > >> > goal is to not have Jenkins results within a fully oriented gh > workflow. > >> > Normally with this option build will still happen but not notify to GH > >> PR > >> > workflow so don't worry there will not be notifications. > >> > Not sure if someone tries to find the reason for windows issues (could > >> be > >> > some files locking during the build which is obviously a bug in our > >> code). > >> > Perso I prefer the Jenkins ui especially when trying to find the > reason > >> for > >> > a failed test result as results are collected and displayed in a more > >> easy > >> > to find stack. > >> > > >> > > >> > > >> > > > >> > > sob., 2 lip 2022 o 21:42 Tamás Cservenák <ta...@cservenak.net> > >> > napisał(a): > >> > > > >> > > > Howdy, > >> > > > > >> > > > I'd like to spin a discussion about the ASF Maven Jenkins > instance. > >> > > > > >> > > > As you know, ASF Infra operates one separate instance of Jenkins > >> only > >> > for > >> > > > Maven related projects. Still, aside this being a chore for INFRA, > >> it > >> > > does > >> > > > have quite some shortcomings: > >> > > > - lack of all needed OS-es (has linux and windows nodes only) > >> > > > - regular (lately more often) issues with windows nodea (like post > >> > build > >> > > > workspace cleanup and others). But really, like 1 out of 3 fails > >> due to > >> > > > some windows node issue. > >> > > > In short, it does not give us needed coverage, plus regularly > >> generates > >> > > > false negatives (red X) for PRs and master builds. > >> > > > > >> > > > OTOH, GH Actions proved very usable, quick, has macOS and in > general > >> > > fast. > >> > > > Still, GH Actions cannot deploy snapshots to repository.a.o, nor > is > >> > > > something we'd want (see last npmjs token leakage). > >> > > > > >> > > > Currently we have this "duality" of CI, and almost always one has > to > >> > > check > >> > > > why a job failed, and MANY times it fails due Jenkins non-build > >> related > >> > > > issues (usually on Windows nodes). > >> > > > > >> > > > Hence, I'd propose something along those lines: > >> > > > - "scale down" Jenkins, keep linux nodes only, and make it > "deploy" > >> > only > >> > > > (preferably of master branch commits only) > >> > > > - hence Jenkins would "loose" CI title, it would be just > "deployer" > >> to > >> > > > repository.a.o > >> > > > - use GH Actions for running tests on PRs and master branches and > >> rely > >> > on > >> > > > its results on GH UI > >> > > > > >> > > > This would give us (and ASF INFRA) benefit of: > >> > > > - the maintained instance becomes way simpler, linux only (ASF > >> INFRA) > >> > > > - PR and master CI results come in way faster > >> > > > - no more (well, GH Actions has outages as well, but less) false > >> > > negatives > >> > > > > >> > > > WDYT? > >> > > > > >> > > > T > >> > > > > >> > > > >> > > > >> > > -- > >> > > Sławomir Jaranowski > >> > > > >> > > >> > >> > >> -- > >> Sławomir Jaranowski > >> > > > -- Sławomir Jaranowski
