Reduce recommended configurations

[MarkEWaite]

Reduce recommended configurations to best bug finders

Reduce recommended configurations to best bug finders

Assure that the recommended configuration will test most likely bug finding combinations:

• Windows, JDK 8, recent LTS
• Linux, JDK 11, recent LTS
• Linux, JDK 8, minimum Jenkins version

Don't need to cover every combination, just the most interesting combinations.

Will reduce the load on ci.jenkins.io and may decrease pull request build time.

@oleg-nenashev and @olblak this will reduce the load on ci.jenkins.io by running fewer configurations. Reduces tested configurations by 50%.

[oleg-nenashev]

Windows for the target Jenkins core version needs to be tested at least.
I think we could approach differently - starting from a single keystone build and doing other configuration if and only if it passes. I will draft a proposal

[MarkEWaite]

I disagree that Windows should be tested for the minimum Jenkins core version supported by the plugin. I've never encountered a case where that combination would detect something that Linux and plugin selected minimum Jenkins core version did not also detect.

I've not seen as many complex environments as you have through your work on remoting and other platform areas, so I'm open to learn of cases where Windows with minimum core version detected a problem that Linux with minimum Jenkins core version did not detect.

Windows runs tests more slowly (at least in my experience). Retaining a Windows test configuration that is not a strong benefit will keep our resource usage higher than necessary without significant benefit to plugin maintainers or users.

[MarkEWaite]

I'm open to consider a keystone build. It seems like an interesting concept.

I am concerned by the number of times that I've waited while a ci.jenkins.io job paused to acquire a new Windows machine for a build or paused to acquire a new maven agent for its deploy stage. With those pauses for agents, I'm hesitant to encourage adding more stages. It means that what is now described as a parallel process (validate configurations in parallel) will become a serial step (keystone build) followed by a parallel process (validate remaining configurations). Won't that double the average elapsed time of the job?

[oleg-nenashev]

depends on how we implement it, but indeed it would almost double the build speed if done incorrectly. We can reduce the impact by doing spotchecks as a keystone build on quickly provisioned ACI containers

…

On Fri, Nov 15, 2019 at 5:29 PM Mark Waite ***@***.***> wrote: I'm open to consider a keystone build. It seems like an interesting concept. I am concerned by the number of times that I've waited while a ci.jenkins.io job paused to acquire a new Windows machine for a build or paused to acquire a new maven agent for its deploy stage. With those pauses for agents, I'm hesitant to encourage adding more stages. It means that what is now described as a parallel process (validate configurations in parallel) will become a serial step followed by a parallel process. Won't that double the average elapsed time of the job? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#120?email_source=notifications&email_token=AAW4RIGVSSPD27YILVLHGF3QT3E6XA5CNFSM4JKHRFTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEF7CKA#issuecomment-554430760>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW4RIGQ6XVCIA27PELILKLQT3E6XANCNFSM4JKHRFTA> .

[jglick]

I suggested much the same thing in #94 (comment). In fact I think we could probably get away with just Windows / JDK 8 and Linux / JDK 11 / recent. See also discussion in #92.

[timja]

Would prefer unused platforms are removed, but I can't see a good reason to keep the extra platforms