Jenkins Contributor Summit at cdCon: June 09, 2022

If you are in the Austin and or neaby areas and would like to join us in the planning of this contributor summit we'd love to have you.. As CDF has offered Jenkinsci a meeting room space at cdCon - we’ll be hosting an onsite

Re: Moving ATH tests closer to the code under test

On Tue, Apr 26, 2022 at 11:12 AM 'Jesse Glick' via Jenkins Developers wrote: > `acceptance-test-harness` has a bunch of dependencies some of which clash > with those in Jenkins core or some plugins, so you would need to either shade > them all, or otherwise somehow ensure the ATH dependency

Re: Moving ATH tests closer to the code under test

On Tue, Apr 26, 2022 at 12:28 PM Basil Crow wrote: > I wonder if we could design a system such that for the common case only a > single Maven project is needed Sounds tricky. `acceptance-test-harness` has a bunch of dependencies some of which clash with those in Jenkins core or some plugins,

Re: Automated plugin release

I, too, have had trouble passing the CI quality gate checks in plugins with existing SpotBugs violations. In my opinion, it is better to suppress SpotBugs violations at the Maven build level (or with @SuppressFBWarnings annotations) than at the CI level by comparing against a baseline, since that

Re: Moving ATH tests closer to the code under test

On Tue, Apr 26, 2022 at 7:45 AM Ullrich Hafner wrote: > Thanks Basil for bringing this topic to attention! You are welcome! > […] I already converted several plugins in the way you are suggesting […] I am pleased that this approach has been working well in your plugins. Assuming that the idea

Re: Moving ATH tests closer to the code under test

Thanks Basil for bringing this topic to attention! I am all in for this new approach! I think when we spend time to write UI tests (which are expensive to write and maintain, and slow to run, see test pyramid of Mike Cohen) then we should consider to run them as real system tests using a real

Re: Next LTS baseline

On Saturday, April 23, 2022 at 1:52:31 PM UTC-6 you wrote: > Heyo, > > 2.345 sounds promising, considering it contains current regressions and > quite a few from older releases too. > > What happened to the suggestion to delay the next LTS baseline selection > by two to four weeks to have