[JIRA] (JENKINS-38961) Escape not supported in Create Credentials popoup
Title: Message Title stephenconnolly updated JENKINS-38961 Jenkins / JENKINS-38961 Escape not supported in Create Credentials popoup Change By: stephenconnolly Status: Resolved In Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39031) Switch to github-branch-source's ViewBranchFilter implememtations
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-39031 Switch to github-branch-source's ViewBranchFilter implememtations Issue Type: Improvement Assignee: stephenconnolly Components: github-organization-folder-plugin Created: 2016/Oct/17 1:10 PM Priority: Minor Reporter: stephenconnolly Switch to the more generic ViewBranchFilter implementations in https://github.com/jenkinsci/github-branch-source-plugin/pull/84 Add Comment This message was sent by Atlassian JIRA
[JIRA] (JENKINS-39026) Add a ViewJobFilter specialized for filtering by Branch
Title: Message Title stephenconnolly started work on JENKINS-39026 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39026) Add a ViewJobFilter specialized for filtering by Branch
Title: Message Title stephenconnolly updated JENKINS-39026 Jenkins / JENKINS-39026 Add a ViewJobFilter specialized for filtering by Branch Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39026) Add a ViewJobFilter specialized for filtering by Branch
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-39026 Add a ViewJobFilter specialized for filtering by Branch Issue Type: Improvement Assignee: stephenconnolly Components: branch-api-plugin Created: 2016/Oct/17 10:22 AM Priority: Minor Reporter: stephenconnolly A common requirement for multibranch plugins is to create specialized sub-views that are filtered by the different types of branch. Given that some plugins have half-complete hacky implementations of this, we should provide a correct base implementation so that plugins can have a simpler path to doing the correct thing. (note; half complete because it assumes that it only ever will be applied to a WorkflowJob rather than correctly navigating to the BranchProjectFactory and then using that to access the Branch instance... thus the utility of that class is compromised relative to what it should be) Add Comment
[JIRA] (JENKINS-29346) Input approval should only be granted to users with job build permission
Title: Message Title stephenconnolly reopened an issue Jenkins / JENKINS-29346 Input approval should only be granted to users with job build permission Change By: stephenconnolly Resolution: Duplicate Status: Resolved Reopened Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38987) SCMHead/SCMSource/SCMNavigator need getPronoun() to assist contextual naming
Title: Message Title stephenconnolly updated JENKINS-38987 Jenkins / JENKINS-38987 SCMHead/SCMSource/SCMNavigator need getPronoun() to assist contextual naming Change By: stephenconnolly Status: In Review Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38987) SCMHead/SCMSource/SCMNavigator need getPronoun() to assist contextual naming
Title: Message Title stephenconnolly updated JENKINS-38987 Jenkins / JENKINS-38987 SCMHead/SCMSource/SCMNavigator need getPronoun() to assist contextual naming Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38987) SCMHead/SCMSource/SCMNavigator need getPronoun() to assist contextual naming
Title: Message Title stephenconnolly started work on JENKINS-38987 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38987) SCMHead/SCMSource/SCMNavigator need getPronoun() to assist contextual naming
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38987 SCMHead/SCMSource/SCMNavigator need getPronoun() to assist contextual naming Issue Type: Improvement Assignee: stephenconnolly Components: scm-api-plugin Created: 2016/Oct/14 11:27 AM Priority: Minor Reporter: stephenconnolly When an owner of a SCMHead, a SCMNavigator or a SCMSource only has one such instance (or where all instances agree on terminology) we need a way to allow the implementations to declare the terminology to be used. For example: The GitHub terminology for the thing represented by a SCMNavigator is an "Organization". The GitHub terminology for the thing represented by a SCMSource is a "Repository". The GitHub terminology for the thing represented by a SCMHead is variously a "Branch", "Tag" or "Pull Request" With Bitbucket we have SCMNavigator = "Team", SCMSource = "Repository" and SCMHead = "Branch", "Tag" or "Pull Request" Other SCM systems may have their own completely different terminology. Currently, the only way to expose this information is to use a hack with an AlternativeUiTextProvider, e.g. https://github.com/jenkinsci/github-organization-folder-plugin/blob/ebdc1c8e589cf0f24b542f33c08ad885ee66d553/src/main/java/org/jenkinsci/plugins/orgfolder/github/AlternativeUiTextProviderImpl.java The hack route is prone to errors, for example if the bitbucket-branch-source plugin wanted to apply its terminology and applied the hack, depending on which AlternativeUiTextProvider ran first, a WorkflowMultiBranchProject with two navigators, one for a BitBucket Team and the other for a GitHub Organization would randomly get the pronoun of "Team" or "Organization". (The question of what
[JIRA] (JENKINS-38960) Deprecate TopLevelItemDescriptor.getIconFilePathPattern() and TopLevelItemDescriptor.getIconFile(String)
Title: Message Title stephenconnolly updated JENKINS-38960 Jenkins / JENKINS-38960 Deprecate TopLevelItemDescriptor.getIconFilePathPattern() and TopLevelItemDescriptor.getIconFile(String) Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38960) Deprecate TopLevelItemDescriptor.getIconFilePathPattern() and TopLevelItemDescriptor.getIconFile(String)
Title: Message Title stephenconnolly started work on JENKINS-38960 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38960) Deprecate TopLevelItemDescriptor.getIconFilePathPattern() and TopLevelItemDescriptor.getIconFile(String)
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38960 Deprecate TopLevelItemDescriptor.getIconFilePathPattern() and TopLevelItemDescriptor.getIconFile(String) Issue Type: Improvement Assignee: stephenconnolly Components: core Created: 2016/Oct/13 11:37 AM Priority: Minor Reporter: stephenconnolly These two methods were introduced in Jenkins 2.0 Given that IconSet and IconSpec have been available since August 2014, the Icon classes should actually have been used instead of hardcoding a path. Add Comment
[JIRA] (JENKINS-38957) Add credentials does not save new credential
Title: Message Title stephenconnolly resolved as Not A Defect You cannot use SSH credentials as scan credentials. If you look in the credentials store you will find your SSH credentials have been stored, and they should be available from the "checkout credentials" drop down. The Add credentials dialog has no way of knowing the restrictions that apply to the select credentials drop-down, so it cannot restrict the available types of credentials for adding... the select box does know the restrictions and applies them correctly Jenkins / JENKINS-38957 Add credentials does not save new credential Change By: stephenconnolly Status: Open Resolved Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37792) Pipeline Config: Notifications per stage
Title: Message Title stephenconnolly commented on JENKINS-37792 Re: Pipeline Config: Notifications per stage > If we kill postBuild what happens to this functionality? So the notifications would still exist. And the other uses of postBuild are subsumbed by a lastly block at the end of all the stages (or we use a special syntax on stage to indicate that the stage is always run in order to remove the discontinuity Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37792) Pipeline Config: Notifications per stage
Title: Message Title stephenconnolly commented on JENKINS-37792 Re: Pipeline Config: Notifications per stage Patrick Wolf so what is the difference between a steps block and a success block? The steps block will only execute if the build result is currently successful... The success block will only execute if the build result is currently successful... One suggestion that Andrew Bayer suggested to me is that effectively each "step" in a success or failure block would be kind of "wrapped" in a try...catch so that all the steps would be executed in that block... To me, that makes it hard to construct inter-sequencing of steps that should happen on success and steps that should happen always followed by steps that should happen on success... we currently have not defined the execution sequence of the components of the conditional blocks in the notifications and I argue that actually we should just follow declaration order and allow conditions to be repeated... So that leads to perhaps the only place where I would expect a difference in behaviour for a "step" in a steps block vs a success block... Failure mode... A "step" in a steps block that has failed should fail the build... a "step" in a success block that has failed should "error" the build... the build has not failed but it is in an error state Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit
[JIRA] (JENKINS-37792) Pipeline Config: Notifications per stage
Title: Message Title stephenconnolly commented on JENKINS-37792 Re: Pipeline Config: Notifications per stage FTR I view postBuild as a terrible name... 1. it is the only camelCase name in the "keywords" of p-m-d 2. it is singular compared with notifications and stages which are the comparable containers Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37792) Pipeline Config: Notifications per stage
Title: Message Title
stephenconnolly commented on JENKINS-37792
Re: Pipeline Config: Notifications per stage
Patrick Wolf my proposal is that we kill off postBuild there is no postBuild any more. I would be against having conditionals in the raw stages... if you still see the need for that it would, to my mind, be a finally or lastly
stages {
stage('unix') {
steps {
...
}
success {
...
}
always {
...
}
}
stage('windows') {
agent label:'win'
steps {
...
}
success {
...
}
failure {
...
}
}
lastly {
success{
...
}
failure{
...
}
}
}
the notifications still stays as they are always executed without a node
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37792) Pipeline Config: Notifications per stage
Title: Message Title stephenconnolly commented on JENKINS-37792 Re: Pipeline Config: Notifications per stage Andrew Bayer each stage is then basically a processing of the list of conditions... (steps being a sort of special condition that is "run this if all the previous steps in this stage completed successfully" which is subtly different from success. all the conditions in a stage would always be evaluated and their contents executed until one of the content steps fails or all content steps are executed. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37792) Pipeline Config: Notifications per stage
Title: Message Title
stephenconnolly commented on JENKINS-37792
Re: Pipeline Config: Notifications per stage
When I think about this, I feel that the requirement can probably be satisfied by changing how we structure things. If the stage (or notifications) block contains node configuration and then an ordered sequence of conditions (where steps is just sort of an alias for success) Thus we can have
pipeline {
agent label:'nix'
stages {
stage('unix') {
steps {
...
}
success {
...
}
steps {
...
}
always {
...
}
}
stage('windows') {
agent label:'win'
steps {
...
}
success {
...
}
failure {
...
}
}
}
notifications {
// by default these get no node, but we can specify a config here to get a node for them
agent label:'irc-server'
always {
...
}
}
}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38870) Allow conditions to be repeated
Title: Message Title
stephenconnolly updated an issue
Jenkins / JENKINS-38870
Allow conditions to be repeated
Change By:
stephenconnolly
It can be confusing as to how to construct a sequence of commands to be executed during a condition, e.g.{code}pipeline { postBuild {success { sh 'echo Awesome > message' archive 'message' sh 'do something else'}failure { sh 'echo Disaster > message' archive 'message' sh 'rage something'} }}{code}What happens if the success {{archive}} step fails? Will we "do something else" or will we stop at that point?What happens if the failure {{archive}} step fails? Will we "rage something" or will we stop at the failure?The principle of least surprise suggests that we should behave the same way for both.We can argue that the steps in a condition block are actually wrapped steps around the actual steps and that they will be all executed providing the outer condition object holds... that is at least consistent *amongst conditions*... but it is not consistent with steps stages or the use of blocks elsewhere.An alternative would be to allow the conditions to be repeated and define the sequence in which conditions are evaluated as being their order of definition, thus{code}pipeline { postBuild {success { sh 'echo Awesome > message'}success { archive 'message'}success { sh 'do something else'}failure { sh 'echo Disaster > message'}failure { archive 'message' sh 'rage something'} }}{code} which clarifies the intent that the three success conditions will only be executed in the event of success being maintained and that the "rage something" will only occur during a failure if the archive step is successful.It also would enable other sequences to be expressed, e.g.:{code}pipeline { postBuild {success { sh 'echo Awesome > message'}failure { sh 'echo Disaster > message'}always { archive 'message'}success { sh 'do something else'}failure { sh 'rage something'} }}{code}
Add Comment
[JIRA] (JENKINS-38870) Allow conditions to be repeated
Title: Message Title
stephenconnolly created an issue
Jenkins / JENKINS-38870
Allow conditions to be repeated
Issue Type:
Improvement
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2016/Oct/10 4:26 PM
Priority:
Minor
Reporter:
stephenconnolly
It can be confusing as to how to construct a sequence of commands to be executed during a condition, e.g.
pipeline {
postBuild {
success {
sh 'echo Awesome > message'
archive 'message'
sh 'do something else'
}
failure {
sh 'echo Disaster > message'
archive 'message'
sh 'rage something'
}
}
}
What happens if the success archive step fails? Will we "do something else" or will we stop at that point? What happens if the failure archive step fails? Will we "rage something" or will we stop at the failure? The principle of least surprise suggests that we should behave the same way for both. We can argue that the steps in a condition block are actually wrapped steps around the actual steps and that they will be all executed providing the outer condition object holds... that is at least consistent amongst conditions... but it is not consistent with steps or the use of blocks elsewhere. An alternative would be to allow the conditions to be repeated and define the sequence in which conditions are evaluated as being their order of definition, thus
pipeline {
postBuild {
success {
sh 'echo Awesome > message'
}
success {
archive 'message'
}
[JIRA] (JENKINS-38861) This ID is already in use when updating credentials
Title: Message Title stephenconnolly commented on JENKINS-38861 Re: This ID is already in use when updating credentials Possibly a side-effect of JENKINS-36315 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38865) Move the ModelAST files into a separate plugin
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38865 Move the ModelAST files into a separate plugin Issue Type: Improvement Assignee: Andrew Bayer Components: pipeline-model-definition-plugin Created: 2016/Oct/10 1:34 PM Priority: Minor Reporter: stephenconnolly The ModelAST files are incredibly useful for programmatically generating pipeline model definitions. Moving them into a separate plugin that had minimal dependencies would enable other plugins to implement functionality for converting between different project types and pipeline models without unduly expanding their dependency trees. Add Comment
[JIRA] (JENKINS-38864) Add support for comments to the ModelAST
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38864 Add support for comments to the ModelAST Issue Type: Improvement Assignee: Andrew Bayer Components: pipeline-model-definition-plugin Created: 2016/Oct/10 1:32 PM Priority: Minor Reporter: stephenconnolly Would be nice to have support for comments in the ModelAST. TBD whether the comments are required to be fully round-trip aware, but for anyone using the ModelAST classes to generate a groovy pipeline definition the ability to inject comments into the generated groovy would be incredibly useful. Add Comment
[JIRA] (JENKINS-38863) Allow empty stage blocks
Title: Message Title
stephenconnolly created an issue
Jenkins / JENKINS-38863
Allow empty stage blocks
Issue Type:
Improvement
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2016/Oct/10 1:31 PM
Priority:
Minor
Reporter:
stephenconnolly
Usecase: As a user I want to prototype how the stage visualization will work, so I set up my pipeline like so:
pipeline {
stages {
parallel {
stage ('foo') {
// placeholder
}
stage ('bar') {
// placeholder
}
stage ('manchu') {
// placeholder
}
}
}
}
but now I cannot view that pipeline visualization as the model fails validation. Similarly I cannot test adding in the logic of each individual stage piecemeal. The current workaround requires that I add a echo 'placeholder' step which is non-intuitive to new users
Add Comment
[JIRA] (JENKINS-38818) String constants containing characters than need escaping are not round-tripped correctly
Title: Message Title
stephenconnolly commented on JENKINS-38818
Re: String constants containing characters than need escaping are not round-tripped correctly
May also want to handle round-tripping {{GString}}s but I'm too lazy to look up the escaping rules for those!
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38818) String constants containing characters than need escaping are not round-tripped correctly
Title: Message Title stephenconnolly started work on JENKINS-38818 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38818) String constants containing characters than need escaping are not round-tripped correctly
Title: Message Title stephenconnolly updated JENKINS-38818 Jenkins / JENKINS-38818 String constants containing characters than need escaping are not round-tripped correctly Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38818) String constants containing characters than need escaping are not round-tripped correctly
Title: Message Title
stephenconnolly created an issue
Jenkins / JENKINS-38818
String constants containing characters than need escaping are not round-tripped correctly
Issue Type:
Bug
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2016/Oct/07 1:34 PM
Priority:
Minor
Reporter:
stephenconnolly
The following script cannot be round-tripped
Unable to find source-code formatter for language: groovy. Available languages are: actionscript, html, java, _javascript_, none, sql, xhtml, xml
pipeline {
agent none
stages {
stage("foo") {
echo '''Hello!
'How are you?', said script A
"I am fine \'\'\'really\'\'\'" said script B
'''
sh 'echo "\'quoted\'"'
}
}
}
[JIRA] (JENKINS-38473) Changing the JNLP agent port via Groovy can cause long timeout
Title: Message Title stephenconnolly updated JENKINS-38473 Jenkins / JENKINS-38473 Changing the JNLP agent port via Groovy can cause long timeout Change By: stephenconnolly Status: In Review Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-33021) trilead ssh MAC and key exchange algorithms severely outdated
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-33021 trilead ssh MAC and key exchange algorithms severely outdated Change By: stephenconnolly Component/s: credentials-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38126) Credentials dropdown empty on git scm
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-38126 Credentials dropdown empty on git scm Change By: stephenconnolly Component/s: credentials-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38126) Credentials dropdown empty on git scm
Title: Message Title stephenconnolly assigned an issue to Mark Waite Jenkins / JENKINS-38126 Credentials dropdown empty on git scm Change By: stephenconnolly Assignee: stephenconnolly Mark Waite Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38613) Pass "Google Play account"-variable as build parameter
Title: Message Title stephenconnolly commented on JENKINS-38613 Re: Pass "Google Play account"-variable as build parameter This is just a question of the plugin switching to use the https://github.com/jenkinsci/credentials-plugin/blob/master/src/main/resources/lib/credentials/select.jelly tag with expressionAllowed="true" in https://github.com/jenkinsci/google-play-android-publisher-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/googleplayandroidpublisher/ApkPublisher/config.jelly#L5 and https://github.com/jenkinsci/google-play-android-publisher-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/googleplayandroidpublisher/ReleaseTrackAssignmentBuilder/config.groovy#L6 Removing the credentials-plugin component as that has provided all the generic framework to enable this functionality Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38613) Pass "Google Play account"-variable as build parameter
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-38613 Pass "Google Play account"-variable as build parameter Change By: stephenconnolly Component/s: credentials-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38465) ECR plugin isn't compatible with credentials managed by folder plugin
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-38465 ECR plugin isn't compatible with credentials managed by folder plugin Change By: stephenconnolly Component/s: credentials-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38539) Enable TCP keep alive on the agent side of the connection
Title: Message Title stephenconnolly updated JENKINS-38539 Merged to stable-2.x, will be in next release Jenkins / JENKINS-38539 Enable TCP keep alive on the agent side of the connection Change By: stephenconnolly Status: In Review Closed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37218) ClassFilter uses Regexs to match String.startsWith patterns
Title: Message Title stephenconnolly updated JENKINS-37218 remoting 2.62 Jenkins / JENKINS-37218 ClassFilter uses Regexs to match String.startsWith patterns Change By: stephenconnolly Status: In Review Closed Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38449) ZipExtractionInstaller not working behind proxy
Title: Message Title stephenconnolly commented on JENKINS-38449 Re: ZipExtractionInstaller not working behind proxy Oh.. before I forget... if you do use the JVM mechanism for defining proxy settings, it is vitally important that you configure them correctly, e.g. non-proxy hosts, and if you need different proxies to access different domains... yes you will have to dig through configuring that mess via the JVMs ugly configuration technologies... vitally important cannot be stressed enough, as otherwise you will get this issues like this reported here for some task or other. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38449) ZipExtractionInstaller not working behind proxy
Title: Message Title stephenconnolly commented on JENKINS-38449 Re: ZipExtractionInstaller not working behind proxy Daniel Beck not clear how this is relevant. 33414 just provides an API that lets you detect if you are running on the master JVM or on an agent JVM. The issue here is that we do not have a good story for things like Proxy management (and also TLS certificate management for agents). Most code just uses the PluginManager's proxy settings because that was the only place you could enter them. The reality is that proxy configuration is a layered thing. You need to define layers of proxies: use this one as the default for the cluster override the cluster default on the master override the cluster default on agents override the cagent default on this specific agent Plus you need to ensure that the proxy settings include details of which hosts they apply to. What happens instead is that we have one UI place for defining the proxies: Manage Jenkins » Manage Plugins » Advanced » Proxies - that page will override the JVM default proxies if you define proxies there... which means that it is effectively the global proxy settings... just managed on a non-intuitive screen. we have code that runs on the master and uses the JVM defaults for proxies we have code that runs on the master and uses Jenkins.getInstance().proxy we have code that runs on agents and uses the JVM defaults for proxies we have code that runs on agents and tries to use Jenkins.getInstance().proxy, fails and drops back to the JVM defaults for proxies we have code that runs on agents and knows it shouldn't try and invoke Jenkins.getInstance().proxy from the agent so makes the call from the master and sends the results over the remoting channel to use the proxies defined on the master from the agent. Users have no clue what path the code they are using will pick, and consequently are justifiably confused. At this point in time, without a good UI in core for managing proxy configuration across the master, agents and cloud provided agents (plus allowing injecting the proxy settings into things like launching agents) my recommendation is as follows: Use the JVM mechanism for defining proxies and keep Manage Jenkins » Manage Plugins » Advanced » Proxies empty. This means that you need to supply the proxy settings in the JAVA_OPTS / JENKINS_OPTS that you launch the master with... and yes that means if you get them wrong you will have to restart your master This means that you need to supply the proxy settings in the JAVA_OPTS / JENKINS_OPTS that you launch each agent with.
[JIRA] (JENKINS-38541) SocketTimeoutException should not be fatal in BIONetworkLayer
Title: Message Title stephenconnolly started work on JENKINS-38541 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38541) SocketTimeoutException should not be fatal in BIONetworkLayer
Title: Message Title stephenconnolly updated JENKINS-38541 Jenkins / JENKINS-38541 SocketTimeoutException should not be fatal in BIONetworkLayer Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38541) SocketTimeoutException should not be fatal in BIONetworkLayer
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38541 SocketTimeoutException should not be fatal in BIONetworkLayer Issue Type: Bug Assignee: stephenconnolly Components: remoting Created: 2016/Sep/27 2:17 PM Priority: Minor Reporter: stephenconnolly See https://github.com/jenkinsci/remoting/pull/106#discussion_r80674954 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-38539) Enable TCP keep alive on the agent side of the connection
Title: Message Title stephenconnolly updated JENKINS-38539 Jenkins / JENKINS-38539 Enable TCP keep alive on the agent side of the connection Change By: stephenconnolly Status: Resolved In Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38539) Enable TCP keep alive on the agent side of the connection
Title: Message Title stephenconnolly started work on JENKINS-38539 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38539) Enable TCP keep alive on the agent side of the connection
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38539 Enable TCP keep alive on the agent side of the connection Issue Type: Bug Assignee: stephenconnolly Components: remoting Created: 2016/Sep/27 1:57 PM Priority: Minor Reporter: stephenconnolly This is especially critical when JNLP agents are operating behind a NAT router with a short timeout on the routing table (i.e. running in a cloud who's name may or may not rhyme with awe-sure) Add Comment This message was sent
[JIRA] (JENKINS-38534) ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents
Title: Message Title
stephenconnolly edited a comment on JENKINS-38534
Re: ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents
From my analysis of OSS plugins, none of them instantiate a LocalProc from the agent JVM directly , rather all and subsequently invoke the {{kill}} method.Most of the uses I can find create the process via the Launcher api invoked starting rely on the master JVM {{join}} which probably explains why may explain how the regression introduced in 1.619 was missed until now .
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38534) ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents
Title: Message Title stephenconnolly commented on JENKINS-38534 Re: ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents From my analysis of OSS plugins, none of them instantiate a LocalProc from the agent JVM directly, rather all uses I can find create the process via the Launcher api invoked starting on the master JVM which probably explains why the regression introduced in 1.619 was missed until now. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38534) ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents
Title: Message Title stephenconnolly started work on JENKINS-38534 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38534) ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-38534 ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents Change By: stephenconnolly Labels: lts-candidate Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38534) ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38534 ProcessKillingVeto.all() forces Jenkins class to be instantiated on remote agents Issue Type: Improvement Assignee: stephenconnolly Components: core Created: 2016/Sep/27 11:48 AM Priority: Minor Reporter: stephenconnolly We have a plugin that is instantiating LocalProc from the agent JVM and is hitting a Caused by: java.lang.NoClassDefFoundError: Could not initialize class jenkins.model.Jenkins at hudson.util.ProcessKillingVeto.all(ProcessKillingVeto.java:77) at hudson.util.ProcessTree$OSProcess.getVeto(ProcessTree.java:237) at hudson.util.ProcessTree$UnixProcess.kill(ProcessTree.java:566) at hudson.util.ProcessTree$UnixProcess.killRecursively(ProcessTree.java:592) at hudson.util.ProcessTree.killAll(ProcessTree.java:141) at hudson.Proc$LocalProc.destroy(Proc.java:379) at hudson.Proc$LocalProc.kill(Proc.java:371) ... error. The root cause of this issue is that the ProcessKillingVeto.all method forces the Jenkins class to be loaded... this is a bad thing as agents are not supposed to try and instantiate the Jenkins class (that some plugins can sometimes managed to succeed in instantiating the Jenkins class on a remote agent is neither here nor there... we should not be trying to instantiate it at all)
[JIRA] (JENKINS-37031) tcpSlaveAgentListener should publish supported agent protocols to speed up connection setup
Title: Message Title stephenconnolly commented on JENKINS-37031 Re: tcpSlaveAgentListener should publish supported agent protocols to speed up connection setup All merged but pending remoting 3.0 release IIRC Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38473) Changing the JNLP agent port via Groovy can cause long timeout
Title: Message Title stephenconnolly updated JENKINS-38473 Jenkins / JENKINS-38473 Changing the JNLP agent port via Groovy can cause long timeout Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38473) Changing the JNLP agent port via Groovy can cause long timeout
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-38473 Changing the JNLP agent port via Groovy can cause long timeout Change By: stephenconnolly Labels: lts-candidate Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38473) Changing the JNLP agent port via Groovy can cause long timeout
Title: Message Title stephenconnolly started work on JENKINS-38473 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38473) Changing the JNLP agent port via Groovy can cause long timeout
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38473 Changing the JNLP agent port via Groovy can cause long timeout Issue Type: Improvement Assignee: stephenconnolly Components: core Created: 2016/Sep/23 4:29 PM Priority: Minor Reporter: stephenconnolly Jenkins 2.7.4 "Thread-12" id=102 (0x66) state=RUNNABLE cpu=0% (running in native) at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:170) at java.net.SocketInputStream.read(SocketInputStream.java:141) at java.net.SocketInputStream.read(SocketInputStream.java:127) at hudson.TcpSlaveAgentListener$PingAgentProtocol.connect(TcpSlaveAgentListener.java:263) at hudson.TcpSlaveAgentListener.shutdown(TcpSlaveAgentListener.java:139) at jenkins.model.Jenkins.launchTcpSlaveAgentListener(Jenkins.java:1054) at jenkins.model.Jenkins.setSlaveAgentPort(Jenkins.java:1047) at jenkins.model.Jenkins$setSlaveAgentPort$0.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) at tcp-slave-agent-port$_run_closure1.doCall(tcp-slave-agent-port.groovy:10) at tcp-slave-agent-port$_run_closure1.doCall(tcp-slave-agent-port.groovy) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498)
[JIRA] (JENKINS-37468) Support for ssh keys in Stash Pull Request Plugin
Title: Message Title stephenconnolly commented on JENKINS-37468 Re: Support for ssh keys in Stash Pull Request Plugin There is a bug in how the stash pull request builder plugin populates the drop-down list of credentials. https://github.com/jenkinsci/stash-pullrequest-builder-plugin/pull/18 will fix that bug so that only UsernamePassword credentials are available from the drop down. I agree that it would be really nice if SSH keys could be used to authenticate against the Stash REST API in order to fetch the required pull request information... however in the absence of Stash actually supporting the use of SSH keys to authenticate a HTTPS REST request I suspect that there is almost nothing that this plugin can do to further this desire. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37707) Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed
Title: Message Title stephenconnolly resolved as Fixed Jenkins / JENKINS-37707 Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed Change By: stephenconnolly Status: Open Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37707) Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed
Title: Message Title stephenconnolly assigned an issue to Thomas de Grenier de Latour Jenkins / JENKINS-37707 Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed Change By: stephenconnolly Assignee: Thomas de Grenier de Latour Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38370) Identify APIs that are only intended for use from the Master JVM
Title: Message Title stephenconnolly updated JENKINS-38370 Jenkins / JENKINS-38370 Identify APIs that are only intended for use from the Master JVM Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38373) Disable opt-out of enforcement of @MasterJVMOnly annotation classes blacklist on agents
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38373 Disable opt-out of enforcement of @MasterJVMOnly annotation classes blacklist on agents Issue Type: Improvement Assignee: Unassigned Components: core Created: 2016/Sep/20 10:44 AM Priority: Minor Reporter: stephenconnolly Downstream of JENKINS-38372. After a good chunk of time (i.e. at least 1 year) we should remove the ability to opt-out of the @MasterJVMOnly enforcement on agents Add Comment This message was sent
[JIRA] (JENKINS-38372) Enforce @MasterJVMOnly annotation classes blacklist on agent by default
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38372 Enforce @MasterJVMOnly annotation classes blacklist on agent by default Issue Type: Improvement Assignee: Unassigned Components: core Created: 2016/Sep/20 10:42 AM Priority: Minor Reporter: stephenconnolly Follow-up to JENKINS-38371 and JENKINS-38370 After "some time" of JENKINS-38371 being in play (probably 3-6 months at least) we should turn on by default the enforcement of the @MasterJVMOnly annotation on all agents. The enforcement should be opt-outable for some period of time Add Comment
[JIRA] (JENKINS-38371) Enforce @MasterJVMOnly annotation classes blacklist on agents when using hpi:run
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38371 Enforce @MasterJVMOnly annotation classes blacklist on agents when using hpi:run Issue Type: Improvement Assignee: Unassigned Components: core Created: 2016/Sep/20 10:40 AM Priority: Minor Reporter: stephenconnolly Follow-up to JENKINS-38370 Start enforcing the @MasterJVMOnly annotation when Jenkins is started using the hpi:run command so that plugin developers can catch bugs during manual testing Add Comment This
[JIRA] (JENKINS-38370) Identify APIs that are only intended for use from the Master JVM
Title: Message Title stephenconnolly started work on JENKINS-38370 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38370) Identify APIs that are only intended for use from the Master JVM
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38370 Identify APIs that are only intended for use from the Master JVM Issue Type: Improvement Assignee: stephenconnolly Components: core Created: 2016/Sep/20 10:32 AM Priority: Minor Reporter: stephenconnolly Initially we need to start identifying APIs that should only be invoked from the master JVM. Downstream of this change we need to start enforcing a blacklisting of such APIs from being invoked on the agents... but that is a separate concern that requires changes in the remoting API and careful introduction. The first step is to allow Core and Plugins to mark those classes which should not be referenced from an Agent JVM with a suitable documented and retained annotation Add Comment
[JIRA] (JENKINS-38344) Catch and log any uncaught exceptions
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-38344 Catch and log any uncaught exceptions Issue Type: Bug Assignee: stephenconnolly Components: remoting Created: 2016/Sep/19 11:08 AM Priority: Minor Reporter: stephenconnolly Found following stack traces when preparing for my Jenkins World talk: Sep 09, 2016 2:17:07 PM hudson.util.ExceptionCatchingThreadFactory uncaughtException WARNING: Thread Computer.threadPoolForRemoting [#3] terminated unexpectedly java.lang.RuntimeException: Delegated task threw Exception/Error at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1429) at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processRead(SSLEngineFilterLayer.java:336) at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecv(SSLEngineFilterLayer.java:116) at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecv(ProtocolStack.java:669) at org.jenkinsci.remoting.protocol.NetworkLayer.onRead(NetworkLayer.java:138) at org.jenkinsci.remoting.protocol.impl.NIONetworkLayer.ready(NIONetworkLayer.java:148) at org.jenkinsci.remoting.protocol.IOHub$OnReady.run(IOHub.java:697) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at
[JIRA] (JENKINS-35081) Separate authorization configuration page
Title: Message Title stephenconnolly assigned an issue to stephenconnolly Jenkins / JENKINS-35081 Separate authorization configuration page Change By: stephenconnolly Assignee: stephenconnolly Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37899) Git client does not call CredentialsProvider.snapshot() when adding credentials to a SmartCredentialsProvider that will be used on a remote instance
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-37899 Git client does not call CredentialsProvider.snapshot() when adding credentials to a SmartCredentialsProvider that will be used on a remote instance Issue Type: Bug Assignee: Mark Waite Components: git-client-plugin Created: 2016/Sep/01 2:57 PM Priority: Critical Reporter: stephenconnolly Some properties of a credential may need to be resolved at point of use rather than being stored in the credential itself. Observed the following as an example stacktraces: With JGit as the client: java.lang.NullPointerException at jenkins.security.ConfidentialStore.get(ConfidentialStore.java:65) at jenkins.security.ConfidentialKey.load(ConfidentialKey.java:46) at jenkins.security.CryptoConfidentialKey.getKey(CryptoConfidentialKey.java:32) at jenkins.security.CryptoConfidentialKey.decrypt(CryptoConfidentialKey.java:67) at hudson.util.Secret.decrypt(Secret.java:151) at hudson.util.Secret.fromString(Secret.java:200) at REDACTED.getPassword(REDACTED.java:136) at org.jenkinsci.plugins.gitclient.trilead.SmartCredentialsProvider.get(SmartCredentialsProvider.java:132) at org.eclipse.jgit.transport.HttpAuthMethod.authorize(HttpAuthMethod.java:219) at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:502) at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:309) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122) at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138) at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130) at org.jenkinsci.plugins.gitclient.JGitAPIImpl$5.execute(JGitAPIImpl.java:1448) at
[JIRA] (JENKINS-37816) Binary incompatible API change in Folders 5.0 broke unique-id plugin
Title: Message Title stephenconnolly updated JENKINS-37816 Version 2.1.3 Jenkins / JENKINS-37816 Binary incompatible API change in Folders 5.0 broke unique-id plugin Change By: stephenconnolly Status: In Review Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37816) Binary incompatible API change in Folders 5.0 broke unique-id plugin
Title: Message Title stephenconnolly updated JENKINS-37816 Jenkins / JENKINS-37816 Binary incompatible API change in Folders 5.0 broke unique-id plugin Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37816) Binary incompatible API change in Folders 5.0 broke unique-id plugin
Title: Message Title stephenconnolly started work on JENKINS-37816 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37816) Binary incompatible API change in Folders 5.0 broke unique-id plugin
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-37816 Binary incompatible API change in Folders 5.0 broke unique-id plugin Issue Type: Bug Assignee: stephenconnolly Components: unique-id Created: 2016/Aug/30 4:15 PM Priority: Minor Reporter: stephenconnolly SEVERE: Failed IdStoreMigratorV1ToV2.migrateIdStore java.lang.Error: java.lang.reflect.InvocationTargetException at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110) at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282) at jenkins.model.Jenkins$7.runTask(Jenkins.java:998) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104) ... 8 more Caused by: org.jenkinsci.plugins.uniqueid.impl.IdStoreMigratorV1ToV2$IDStoreMigrationException: Failure whilst migrating com.cloudbees.hudson.plugins.folder.Folder@3489f85a[folderWithID] at org.jenkinsci.plugins.uniqueid.impl.IdStoreMigratorV1ToV2.migrate(IdStoreMigratorV1ToV2.java:100) at org.jenkinsci.plugins.uniqueid.impl.IdStoreMigratorV1ToV2.performMigration(IdStoreMigratorV1ToV2.java:68) at
[JIRA] (JENKINS-37315) Make JNLP3 opt-in for all
Title: Message Title stephenconnolly commented on JENKINS-37315 Re: Make JNLP3 opt-in for all If it falls back to JNLP2 then the secret is exposed over the wire and thus the encryption can be broken. There are approx 28% of connection attempts that will fail due to the cookie and about 5-10% that will fail due to challenge-response encoding issues... the cookie one should have been fixed if you use the latest remoting.jar on your agents... If an admin has enabled JNLP3 on the master because they want to keep transport encrypted, this is a bad thing. For the 10% who are opted in to the A/B testing, they will get slower connection establishment. Given all the issues I have identified with JNLP3 I am now of the opinion that we drop it and go straight for JNLP4 (subject to an A/B test on JNLP4), so there is no value - to my mind - in continuing with the JNLP3 A/B testing and consequently no value in exposing users to it (obviously JNLP3 is more encrypted than JNLP2, so we cannot disable it until JNLP4 is merged into Jenkins core... and even then we should not disable it until after the A/B testing on JNLP4) Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37315) Make JNLP3 opt-in for all
Title: Message Title stephenconnolly resolved as Fixed Merged to Head Jenkins / JENKINS-37315 Make JNLP3 opt-in for all Change By: stephenconnolly Status: Open Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37315) Make JNLP3 opt-in for all
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-37315 Make JNLP3 opt-in for all Issue Type: Bug Assignee: stephenconnolly Components: core Created: 2016/Aug/10 4:37 PM Labels: lts-candidate Priority: Blocker Reporter: stephenconnolly Too many encoding issues with JNLP3 protocol. We should stop A/B testing it for HEAD and LTS Add Comment
[JIRA] (JENKINS-37302) JNLP3 challenge response generates invalid string encoding
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-37302 JNLP3 challenge response generates invalid string encoding Issue Type: Improvement Assignee: Unassigned Components: remoting Created: 2016/Aug/10 8:24 AM Priority: Major Reporter: stephenconnolly Oh looky here https://github.com/jenkinsci/remoting/blob/master/src/main/java/org/jenkinsci/remoting/engine/Jnlp3Util.java#L93 So the digest can generate any bytes you care... but not all byte sequences are valid UTF-8... thus you have a random chance of failure to validate... isn't that wonderful! Add Comment
[JIRA] (JENKINS-37189) a file:// update center will always be offline
Title: Message Title stephenconnolly updated JENKINS-37189 Merged Jenkins / JENKINS-37189 a file:// update center will always be offline Change By: stephenconnolly Status: In Review Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37189) a file:// update center will always be offline
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-37189 a file:// update center will always be offline Change By: stephenconnolly Labels: lts-candidate Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37189) a file:// update center will always be offline
Title: Message Title stephenconnolly updated JENKINS-37189 Jenkins / JENKINS-37189 a file:// update center will always be offline Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37189) a file:// update center will always be offline
Title: Message Title stephenconnolly assigned an issue to stephenconnolly Jenkins / JENKINS-37189 a file:// update center will always be offline Change By: stephenconnolly Assignee: stephenconnolly Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37189) a file:// update center will always be offline
Title: Message Title stephenconnolly started work on JENKINS-37189 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37218) ClassFilter uses Regexs to match String.startsWith patterns
Title: Message Title stephenconnolly updated JENKINS-37218 Jenkins / JENKINS-37218 ClassFilter uses Regexs to match String.startsWith patterns Change By: stephenconnolly Status: Reopened Open Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37218) ClassFilter uses Regexs to match String.startsWith patterns
Title: Message Title stephenconnolly updated JENKINS-37218 Jenkins / JENKINS-37218 ClassFilter uses Regexs to match String.startsWith patterns Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37218) ClassFilter uses Regexs to match String.startsWith patterns
Title: Message Title stephenconnolly reopened an issue Jenkins / JENKINS-37218 ClassFilter uses Regexs to match String.startsWith patterns Change By: stephenconnolly Resolution: Fixed Status: Resolved Reopened Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37218) ClassFilter uses Regexs to match String.startsWith patterns
Title: Message Title stephenconnolly started work on JENKINS-37218 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37218) ClassFilter uses Regexs to match String.startsWith patterns
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-37218 ClassFilter uses Regexs to match String.startsWith patterns Issue Type: Improvement Assignee: stephenconnolly Components: remoting Created: 2016/Aug/05 3:24 PM Priority: Minor Reporter: stephenconnolly From profiling connections using the load-testing client in the JENKINS-36871 PR I have notices that there is a lot of work done matching classes in the classfilter against simple regexes. There is a >50% reduction in this portion of CPU work if we replace the simple patterns with String.startsWith calls instead. This also reduces the GC pressure. Add Comment
[JIRA] (JENKINS-37140) JNLP3-connect protocol format does not handle encrypted cookies that happen to contain a newline
Title: Message Title stephenconnolly updated an issue Jenkins / JENKINS-37140 JNLP3-connect protocol format does not handle encrypted cookies that happen to contain a newline Change By: stephenconnolly Found this while comparing JNLP3-connect with JNLP4-connect under my stress test harness.The protocol finishes negotiation on the server side by sending a new cookie. The cookie is random bytes which have been encrypted using the cipher.The bytes are sent using as a `println(encryptedString)`The client then reads this using a `readLine` before switching over to the encrypted stream.Unfortunately if the encrypted string format of the new cookie contains a `\n` then basically the protocol is screwed up and the client will be stuck in an infinite loop trying to initialize the `ChannelBuilder` by detecting the preambles... which is akin to waiting on an infinite number of monkeys with typewriters to produce the complete works of Shakespeare. The symptom will be a JNLP client that never connects... with luck some of the remoting operations on the server side will time out (I'm looking at you Ping) and the connection will be closed, and a subsequent retry will hopefully "get lucky". Alternatively restarting the JNLP client will cause a new cookie to be created and we get to play roulette again.We can analyse the predicted probability of getting this type of failure.There are 32 random bytes of the cookie that get encoded as a hex string of length 64.A good cipher should result in something that appears close enough to a uniformly random distribution. Thus we have 64 bytes of random values in the range 0-255 and we want the probability that none of those 64 bytes are `\n`, or `(254/255)^64` which is about 78% of the time.Basically 12 22 % of connections will fall victim to this bug... which matches the observed frequency of failure in my tests Add Comment
[JIRA] (JENKINS-37140) JNLP3-connect protocol format does not handle encrypted cookies that happen to contain a newline
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-37140 JNLP3-connect protocol format does not handle encrypted cookies that happen to contain a newline Issue Type: Bug Assignee: stephenconnolly Components: remoting Created: 2016/Aug/03 10:10 AM Priority: Critical Reporter: stephenconnolly Found this while comparing JNLP3-connect with JNLP4-connect under my stress test harness. The protocol finishes negotiation on the server side by sending a new cookie. The cookie is random bytes which have been encrypted using the cipher. The bytes are sent using as a `println(encryptedString)` The client then reads this using a `readLine` before switching over to the encrypted stream. Unfortunately if the encrypted string format of the new cookie contains a `\n` then basically the protocol is screwed up and the client will be stuck in an infinite loop trying to initialize the `ChannelBuilder` by detecting the preambles... which is akin to waiting on an infinite number of monkeys with typewriters to produce the complete works of Shakespeare. The symptom will be a JNLP client that never connects... with luck some of the remoting operations on the server side will time out (I'm looking at you Ping) and the connection will be closed, and a subsequent retry will hopefully "get lucky". Alternatively restarting the JNLP client will cause a new cookie to be created and we get to play roulette again. We can analyse the predicted probability of getting this type of failure. There are 32 random bytes of the cookie that get encoded as a hex string of length 64. A good cipher should result in something that appears close enough to a uniformly random distribution. Thus we have 64 bytes of random values in the range 0-255 and we want the probability that none of those 64 bytes are `\n`, or `(254/255)^64` which is about 78% of the time. Basically 12% of connections will fall victim to this bug... which matches the observed frequency of failure in my tests
[JIRA] (JENKINS-37032) Provide a UI to manage the enabled TCP Agent Protocols
Title: Message Title stephenconnolly updated JENKINS-37032 Jenkins / JENKINS-37032 Provide a UI to manage the enabled TCP Agent Protocols Change By: stephenconnolly Status: In Review Resolved Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37032) Provide a UI to manage the enabled TCP Agent Protocols
Title: Message Title stephenconnolly commented on JENKINS-37032 Re: Provide a UI to manage the enabled TCP Agent Protocols released towards 2.16 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37041) If an older version of a detached plugin is already installed it does not get upgraded
Title: Message Title stephenconnolly updated JENKINS-37041 Jenkins / JENKINS-37041 If an older version of a detached plugin is already installed it does not get upgraded Change By: stephenconnolly Status: In Review Resolved Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37041) If an older version of a detached plugin is already installed it does not get upgraded
Title: Message Title stephenconnolly updated JENKINS-37041 Jenkins / JENKINS-37041 If an older version of a detached plugin is already installed it does not get upgraded Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37041) If an older version of a detached plugin is already installed it does not get upgraded
Title: Message Title stephenconnolly started work on JENKINS-37041 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37041) If an older version of a detached plugin is already installed it does not get upgraded
Title: Message Title stephenconnolly created an issue Jenkins / JENKINS-37041 If an older version of a detached plugin is already installed it does not get upgraded Issue Type: Bug Assignee: stephenconnolly Components: core Created: 2016/Jul/28 2:41 PM Environment: 2.16-SNAPSHOT with bouncycastle-api 1.648.0 installed Priority: Blocker Reporter: stephenconnolly INFO: Listed all plugins Jul 28, 2016 3:21:44 PM jenkins.model.Jenkins$7 runTask WARNING: Loading plugin bouncycastle-api failed perhaps due to plugin dependency issues java.io.IOException: Unable to load jenkins.bouncycastle.api.SecurityProviderInitializer from bouncycastle-api at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:508) at hudson.PluginManager$2$1$1.run(PluginManager.java:512) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282) at jenkins.model.Jenkins$7.runTask(Jenkins.java:1022) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/jce/provider/BouncyCastleProvider at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at
[JIRA] (JENKINS-37032) Provide a UI to manage the enabled TCP Agent Protocols
Title: Message Title stephenconnolly started work on JENKINS-37032 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37032) Provide a UI to manage the enabled TCP Agent Protocols
Title: Message Title stephenconnolly updated JENKINS-37032 Jenkins / JENKINS-37032 Provide a UI to manage the enabled TCP Agent Protocols Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37031) tcpSlaveAgentListener should publish supported agent protocols to speed up connection setup
Title: Message Title stephenconnolly updated JENKINS-37031 Jenkins / JENKINS-37031 tcpSlaveAgentListener should publish supported agent protocols to speed up connection setup Change By: stephenconnolly Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37031) tcpSlaveAgentListener should publish supported agent protocols to speed up connection setup
Title: Message Title stephenconnolly updated JENKINS-37031 Jenkins / JENKINS-37031 tcpSlaveAgentListener should publish supported agent protocols to speed up connection setup Change By: stephenconnolly Status: In Review Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36871) JNLPProtocol4
Title: Message Title stephenconnolly started work on JENKINS-36871 Change By: stephenconnolly Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
