-
-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce recommended configurations #120
Reduce recommended configurations #120
Conversation
Assure that the recommended configuration will test most likely bug finding pairs of: * JDK 8, JDK 11 * Windows, Linux * minimum Jenkins version, recent LTS Jenkins version. Don't need to cover every combination, just assure that most interesting pairs are tested. Will reduce the load on ci.jenkins.io and may decrease pull request build time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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. |
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 |
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>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would prefer unused platforms are removed, but I can't see a good reason to keep the extra platforms
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:
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%.