[JIRA] (JENKINS-38073) Default to organization hooks
Title: Message Title Antonio Beyah created an issue Jenkins / JENKINS-38073 Default to organization hooks Issue Type: Improvement Assignee: Honza Brázdil Components: ghprb-plugin Created: 2016/Sep/08 6:56 PM Priority: Minor Reporter: Antonio Beyah On our jenkins installation, we have about ~1500 jobs that require webhooks. The startup of jenkins is incredibly slow because the plugin attempts to create a hook for each individual repo and the 'starting trigger for' blocks jenkins startup. It would be ideal if we could default to an organization hook, and if setting an organization hook doesn't work fall back to individual repository hooks. I am willing to take on the work to make the change, but I would like maintainer support before doing the work. Add Comment
[JIRA] (JENKINS-36871) JNLPProtocol4
Title: Message Title Antonio Beyah commented on JENKINS-36871 Re: JNLPProtocol4 +1, also interested in this. Any update on when this is expected to be released? 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-39360) Allow ALLOWED_JNLPJARS_FILES to be configurable by plugins
Title: Message Title Antonio Beyah created an issue Jenkins / JENKINS-39360 Allow ALLOWED_JNLPJARS_FILES to be configurable by plugins Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: core, swarm-plugin Created: 2016/Oct/28 6:11 PM Priority: Minor Reporter: Antonio Beyah We currently use the [Swarm](https://wiki.jenkins-ci.org/display/JENKINS/Swarm+Plugin) plugin to configure our agents to connect to the master and one of the things we have to do is presetup the agent with the proper version of the swarm-client jar. One thing I wanted to do was update the swarm plugin to allow you to retrieve the swarm-client.jar in the same manner as we can the slave.jar. When I looked at the code though I don't think this is possible due to the code in the core. The current process looks like this: Download swarm-client.jar from internet Download slave.jar from master Run java process with -cp slave.jar:swarm-client.jar I would like it to look like: Download swarm-client.jar from master Download slave.jar from master Run java process with -cp slave.jar:swarm-client.jar End goal is to allow me to configure my agents by retrieving any necessary components from the master, including plugin client dependencies such as the swarm-client.jar. References: [Slave.java](https://github.com/jenkinsci/jenkins/blob/57fc2185da383e904a2a714f2d945426a92bfc3e/core/src/main/java/hudson/model/Slave.java
[JIRA] (JENKINS-29390) Parameterization for Docker Container configuration.
Title: Message Title Antonio Beyah commented on JENKINS-29390 Re: Parameterization for Docker Container configuration. Can we also make a similar consideration for volumes? I would like the volumes mounted for workspace and target paths to be configurable. The current (default) is great for most cases but there are areas where it falls apart, namely places where the same directories are used by the job running inside the container and are also mounted. For example, JENKINS_HOME is mounted inside the container, but I have an RPM that is building/installing a RPM that is creating those directories (the jenkins rpm), so in this case I would like the JENKINS_HOME to not match the paths in the rpm. In a sense, in some instances I want the file system to be completely isolated from the host machine. I'm thinking it would be nice if under 'volumes' the default was to have the ones that are currently hardcoded, but to allow the volumes to be completely configurable. I'm curious to your thoughts on that, if you are open to it I may be able to throw a PR together that adds that support. If you want I can open a separate issue to discuss configurable volumes, just let me know. 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-36865) Stage view showing wrong pipeline data
Title: Message Title Antonio Beyah created an issue Jenkins / JENKINS-36865 Stage view showing wrong pipeline data Issue Type: Bug Assignee: Sam Van Oort Attachments: pipeline_stage_view_bug_after_clearing_cache.png, pipeline_stage_view_bug_before.png Components: pipeline-stage-view-plugin Created: 2016/Jul/22 3:19 AM Environment: Jenkins 2.11, Pipeline Stage View v1.6, CentOS 7 Priority: Minor Reporter: Antonio Beyah After running a few pipeline executions, if you delete the job and recreate it will show the proper pipeline while building, but after the pipeline has completed running it will revert to showing the pipeline from the previous (deleted) run. After looking at the code to the plugin, I was able to determine that there was a cache and found some code in the tests to invalidate it. I was able to workaround the issue by running the following code in the script console: Unable to find source-code formatter for language: groovy. Available languages are: actionscript, html, java, _javascript_, none, sql, xhtml, xml import com.cloudbees.workflow.flownode.FlowNodeUtil FlowNodeUtil.CacheExtension ext = FlowNodeUtil.CacheExtension.all().get(0); ext.getExecutionCache().invalidateAll()
[JIRA] (JENKINS-36865) Stage view showing wrong pipeline data
Title: Message Title Antonio Beyah updated an issue Jenkins / JENKINS-36865 Stage view showing wrong pipeline data Change By: Antonio Beyah After running a few pipeline executions, if you delete the job and recreate it will show the proper pipeline while building, but after the pipeline has completed running it will revert to showing the pipeline from the previous (deleted) run. After looking at the code to the plugin, I was able to determine that there was a cache and found some code in the tests to invalidate it. I was able to workaround the issue by running the following code in the script console:{code: groovy java }import com.cloudbees.workflow.flownode.FlowNodeUtilFlowNodeUtil.CacheExtension ext = FlowNodeUtil.CacheExtension.all().get(0);ext.getExecutionCache().invalidateAll();ext.getRunCache().invalidateAll();{code} 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 unsubs