Skip to content
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

add support for limiting job concurrency based on one or more build parameters #9

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

joemiller
Copy link

Submitting this PR to see if this feature set is something the upstream would be in favor of accepting. And if so, what changes or cleanup would be necessary to get it upstream?

@cloudbees-pull-request-builder

plugins » throttle-concurrent-builds-plugin #6 FAILURE
Looks like there's a problem with this pull request

@jenkinsadmin
Copy link
Member

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

@@ -26,13 +26,13 @@ THE SOFTWARE.
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.399</version>
<version>1.518</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you reduce version dependency to 1.480.x at least? Old LTS releases still alive...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll try that.

On Mon, Nov 4, 2013 at 12:20 PM, Oleg Nenashev [email protected]:

In pom.xml:

@@ -26,13 +26,13 @@ THE SOFTWARE.

org.jenkins-ci.plugins
plugin

  • 1.399
  • 1.518

Could you reduce version dependency to 1.480.x at least? Old LTS releases
still alive...


Reply to this email directly or view it on GitHubhttps://github.com//pull/9/files#r7412031
.

@cloudbees-pull-request-builder

plugins » throttle-concurrent-builds-plugin #17 FAILURE
Looks like there's a problem with this pull request

@cloudbees-pull-request-builder

plugins » throttle-concurrent-builds-plugin #18 UNSTABLE
Looks like there's a problem with this pull request

@cloudbees-pull-request-builder

plugins » throttle-concurrent-builds-plugin #23 UNSTABLE
Looks like there's a problem with this pull request

@cloudbees-pull-request-builder

plugins » throttle-concurrent-builds-plugin #28 SUCCESS
This pull request looks good

@joemiller
Copy link
Author

this should be good to go now.

@joemiller
Copy link
Author

@oleg-nenashev do you have access to review and merge this PR? Thanks

@oleg-nenashev
Copy link
Member

@joemiller , @Hornswoggles
I'll review changes and provide my feedback.
BTW, I think that @abayer could make the final decision if he has some time to review the project.

From my point of view it makes sense to create a ThrottleCategoryProvider extension point. There are many possible sources of categories, so a generic approach would be very useful.

@@ -26,7 +26,7 @@ THE SOFTWARE.
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.424</version>
<version>1.509.4</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to change the version? I don't see real dependencies from Jenkins core.
I also recommend to avoid 1.509.4 at least. See https://groups.google.com/forum/#!topic/jenkinsci-dev/9fMrUsVh6zU

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure, possibly. It's been a while since we started this patch and
I don't recall if we bumped version for a reason.

Would the proper approach to testing this be to simply revert the version
in the pom.xml and run the test suite?

thanks

On Fri, Apr 4, 2014 at 10:46 AM, Oleg Nenashev [email protected]:

In pom.xml:

@@ -26,7 +26,7 @@ THE SOFTWARE.

org.jenkins-ci.plugins
plugin

  • 1.424
  • 1.509.4

Do we really need to change the version? I don't see real dependencies
from Jenkins core.
I also recommend to avoid 1.509.4 at least. See
https://groups.google.com/forum/#!topic/jenkinsci-dev/9fMrUsVh6zU

Reply to this email directly or view it on GitHubhttps://github.com//pull/9/files#r11305151
.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test suites don't provide enough test coverage. BTW, it is better than nothing

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Throttling by parameter doesnt work on 1.424 I will go through each LTS release between 1.424 and 1.509. Starting with 1.424.6

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LTS 1.447 builds and works. Although the helpful message does not show up in the queue
LTS 1.466 builds and works and has the helpful message in the queue

@varosi
Copy link

varosi commented Sep 16, 2015

Do you plan to merge those changes about controlling throttleling based on build parameters?

jmozmoz added a commit to jmozmoz/throttle-concurrent-builds-plugin that referenced this pull request Oct 24, 2015
@jmozmoz
Copy link

jmozmoz commented Oct 24, 2015

I merge the current master branch into this pull request and tried to follow the review comments in this pull request. These I do not know how to implement:

  • It also makes sense to use formatted outputs to prevent string constructions
  • It makes sense to add the parameter validation to UI form. Otherwise, errors in data formats may be left unnoticed
  • I suggest to calculate the array and save it to a transient field once (on save/load) to decrease the performance impact
  • Store a list instead of the string to avoid multiple parsings. I also think that the field name is quite confusing
  • isAnotherBuildWithSameParametersRunningOnAnyNode() has its internal logging of conflicts (there seems to be no loggin in isAnotherBuildWithSameParametersRunningOnAnyNode)
  • Please use Sun/Oracle Java code style to prevent complains from FindBugs and other utilities

If you give me more specific guidance how to fix these, I will try to implement them also.

Here is the repository: https://github.com/jmozmoz/throttle-concurrent-builds-plugin

@jmozmoz
Copy link

jmozmoz commented Nov 2, 2015

Ping
Is there a chance to get update of the original pull request into this plugin? Anybody willing to help?

@oleg-nenashev
Copy link
Member

@varosi @jmozmoz
This PR would be eligible for the merge when the performance issues get solved.
1.609.x LTS already provides some changes in this direction, but not enough IMHO.

@Ignas
Copy link

Ignas commented Jan 7, 2016

Which performance issues exactly have to be solved? I can't find any of them being discussed in comments on this pull request.

@jmozmoz
Copy link

jmozmoz commented Jan 8, 2016

As requested a I move the list paramsToCompare to a transient field which is filled by an overwritten load()/save()?
See the commit jmozmoz@599453b in pantheon-systems#6

Is this the way to go?

@oleg-nenashev
Copy link
Member

@oleg-nenashev
Copy link
Member

@jmozmoz

As requested a I move the list paramsToCompare to a transient field which is filled by an overwritten load()/save()?

Yes, it may work. I've lost the track of this PR a bit, need to review it again. Did you have a chance to process the previous comments?

@jmozmoz
Copy link

jmozmoz commented Jan 10, 2016

I created a new pull request #33 including upstream changes not merged into in this original pull request. Also I think I addressed the following issues (striked out):

  • I suggest to calculate the array and save it to a transient field once (on save/load) to decrease the performance impact
  • Store a list instead of the string to avoid multiple parsings. I also think that the field name is quite confusing (this was already fixed (the list), also the string has been renamed)
  • isAnotherBuildWithSameParametersRunningOnAnyNode() has its internal logging of conflicts
  • Please use Sun/Oracle Java code style to prevent complains from FindBugs and other utilities
  • It also makes sense to use formatted outputs to prevent string constructions
  • It makes sense to add the parameter validation to UI form. Otherwise, errors in data formats may be left unnoticed
    (the last two issues remain: Could somebody please point me to examples how to fix them)

@jmozmoz
Copy link

jmozmoz commented Jan 10, 2016

Now the pull request #33 builds but there are some test failures. I have no idea, how these test failures are related to the work here. Could somebody please help.

@zoidyzoidzoid
Copy link

Can this PR be closed since #38 has been merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.