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? ś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
