Re: Revisiting bundled plugins

On Friday, September 4, 2015 at 3:31:54 PM UTC+1, James Nord wrote: > > For v1 all I am saying is we need to have *a* solution to the problem > (not *what* that solution needs to be). If the chosen solution is > pointing users to a document that explains some workarounds (possibly > provides

Re: Revisiting bundled plugins

On Friday, September 4, 2015 at 5:37:26 PM UTC+1, Daniel Beck wrote: > > >> For version 1 of this, can't we just document some possible solutions > to this problem and point the user to these solutions from inside the > wizard on detecting the fact that there's no internet connection? This >

Automatic tool installation - too many choices?

Hi all, my crawler for cmake.org gives 31 choices for end users to install. Would that be OK or should I try to reduce the number? Choices for cmake are "id": "3.3.1", "id": "3.3.0", "id": "3.2.3", "id": "3.2.2", "id": "3.2.1", "id": "3.2.0", "id": "3.1.3", "id":

Re: Commit access to jenkinsci/SCTMExecutor-plugin

In GitHub the right approach to the contribution is to create pull requests from forks to the master repo. In such case the plugin developers will be able to review and accept the pull request. Anyway I've granted the commit permissions to Sebastian. He dhould get an invitation to the

Re: Modularized JavaScript code in Jenkins Core .... how about it?

Hi Surya. We're not inventing anything new for the bundling/packaging part. It uses Browserify for that, which is similar to Webpack. So you are not against the idea of adding build steps to Jenkins core re supporting modularised JavaScript? Sent from my iPhone > On 6 Sep 2015, at 17:23,

Re: Automatic tool installation - too many choices?

Look at the other tools. Play Framework -- 24 versions Ant -- 28 versions Maven -- 33 versions Groovy -- 76 versions Gradle -- 89 versions NodeJS -- 155 versions So 31 for cmake looks low enough. Unless you've seem complaints about Gradle, Groovy, or Nodejs? > On 06.09.2015, at 07:35, Martin

Re: Modularized JavaScript code in Jenkins Core .... how about it?

Hi Tom, I've been packaging all kinds of js stuff with webpack. Avoids all kinds of problems with globals ect that you described. I am not quite sure if we need to invent a jenkins specific solution here. Here is an example using elm https://github.com/DotCi/DotCiPipelineViewer example

Cloud plugin, provisioning

Hi All, Quick question: writing cloud plugin, provisioning is called more than once for the same label, but I have only one node to provision, should I return the same instance once again, or should I return empty list and Jenkins will reuse the node that was returned on first request? -- You

Re: Commit access to jenkinsci/SCTMExecutor-plugin

Hi Oleg, thanks for helping, but why do I not have permissions to change settings. I'm the founder, owner an maintainer of this plugin? I also have a different plugin for jenkins (thinbackup) and here I'm able to change the settings. Regards, Thomas Am 06.09.2015 um 20:07 schrieb Oleg Nenashev:

Cloud plugin, disconnecting from slave properly

Hi All, Another question regarding custom cloud plugins: I'm creating a custom plugin that creates a node from prototype, uses the node, discards it (or reverts the state). I'm starting slave.jar with tcp and connecting to it. My ComputerLauncher also implements ExecutorListener, and

Re: Commit access to jenkinsci/SCTMExecutor-plugin

I have no permissions to check your permissions :( CC'ed Daniel Beck, he should be able to do it. 2015-09-06 21:55 GMT+03:00 Thomas Fürer : > Hi Oleg, > > thanks for helping, but why do I not have permissions to change > settings. I'm the founder, owner an maintainer