[Jenkins Docker] Preinstalling plugins not working

[domi]

Hi,

I just tried to update our Jenkins Docker Image with the latest version 
(Jenkins 2.204.1).
To preinstall plugins, we use the provided 'install-plugins.sh’ script. But it 
does not work as before anymore…
Many plugins fail to be downloaded e.g. the script tries to get the 
'git-client-plugin’ from 
https://updates.jenkins.io/download/plugins/git-client-plugin/2.8.1/git-client-plugin.hpi
 - but the plugin is not available at this location anymore, it is now 
available at: 
http://mirrors.jenkins-ci.org/plugins/git-client/2.8.1/git-client.hpi 
As you can see, the two URLs reference the plugin with a different name, one 
uses the postfix ‘-plugin’, but the new one does not.

Did I miss anything? Is this script discarded? What should be used instead?

Many Thanks
Domi

btw.
I have the same problem for all these plugins:

Some plugins failed to download! Not downloaded: greenballs
Not downloaded: favorite
Not downloaded: managed-scripts
Not downloaded: github-api
Not downloaded: workflow-api
Not downloaded: pipeline-model-definition
Not downloaded: blueocean-config
Not downloaded: blueocean
Not downloaded: pubsub-light
Not downloaded: docker-java-api
Not downloaded: mailer
Not downloaded: pipeline-stage-step
Not downloaded: matrix-project
Not downloaded: pipeline-utility-steps
Not downloaded: h2-api
Not downloaded: blueocean-web
Not downloaded: blueocean-pipeline-editor
Not downloaded: junit
Not downloaded: credentials-binding
Not downloaded: blueocean-display-url
Not downloaded: pipeline-maven
Not downloaded: sse-gateway
Not downloaded: github
Not downloaded: basic-branch-build-strategies
Not downloaded: github-branch-source
Not downloaded: pipeline-model-declarative-agent
Not downloaded: git-client


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/42D80737-53D5-4DB9-997B-8E7CBE38785A%40fortysix.ch.

Re: Adding Atlassian Bitbucket server integration to recommended plugins

[domi]

Thats great suggestion by Mark!
Please also make sure to clearly differentiate the “Bitbucket Server” Plugin 
landscape form the “Bitbucket Cloud” landscape - its quite a mess and hard to 
understand what is really needed for what and why.
e.g. there are plugins like 
- https://plugins.jenkins.io/bitbucket <https://plugins.jenkins.io/bitbucket>
- https://plugins.jenkins.io/bitbucket-approve 
<https://plugins.jenkins.io/bitbucket-approve>
- https://plugins.jenkins.io/cloudbees-bitbucket-branch-source 
<https://plugins.jenkins.io/cloudbees-bitbucket-branch-source>
- https://plugins.jenkins.io/bitbucket-oauth 
<https://plugins.jenkins.io/bitbucket-oauth>
- “Bitbucket for Blue Ocean”
- https://plugins.jenkins.io/bitbucket-build-status-notifier 
<https://plugins.jenkins.io/bitbucket-build-status-notifier>
- https://plugins.jenkins.io/stashNotifier 
<https://plugins.jenkins.io/stashNotifier>
- https://plugins.jenkins.io/violation-comments-to-stash 
<https://plugins.jenkins.io/violation-comments-to-stash>
- https://plugins.jenkins.io/bitbucket-pullrequest-builder 
<https://plugins.jenkins.io/bitbucket-pullrequest-builder>
- https://plugins.jenkins.io/bitbucket-approval-filter 
<https://plugins.jenkins.io/bitbucket-approval-filter>
- https://plugins.jenkins.io/bitbucket-filter-project-trait 
<https://plugins.jenkins.io/bitbucket-filter-project-trait>
- https://plugins.jenkins.io/bitbucket-push-and-pull-request 
<https://plugins.jenkins.io/bitbucket-push-and-pull-request>
- https://plugins.jenkins.io/bitbucket-scm-filter-aged-refs 
<https://plugins.jenkins.io/bitbucket-scm-filter-aged-refs>
- https://plugins.jenkins.io/bitbucket-scm-filter-jira-validator 
<https://plugins.jenkins.io/bitbucket-scm-filter-jira-validator>
- https://plugins.jenkins.io/bitbucket-scm-trait-commit-skip 
<https://plugins.jenkins.io/bitbucket-scm-trait-commit-skip>
- https://plugins.jenkins.io/publish-to-bitbucket 
<https://plugins.jenkins.io/publish-to-bitbucket>
...

Some do support “Server” AND “Cloud” others don’t. Some even do the 
exact/nearly same thing. And most of the plugins probably do not use a common 
configuration but have to be configured individually to have access to the 
service.

As I’m a user of "bitbucket cloud” my self, I think this clearly shows a 
problem: there is no coordination of what kind of plugins are build and how 
they should work together. I understand this is also the power of Jenkins: 
something is missing and your free to build a plugin to solve the issue. But 
with each plugin published, the confusion for users/admins gets bigger. I’m 
sure this issue is not only about bitbucket, the same thing (probably even 
bigger) might be with GitHub and other areas.

It would be really great to have some kind of documentation for a topics/area 
which highlights (and maybe coordinates) the most common use cases one has 
around different topics. e.g. GitHub Integration, Bitbucket Cloud Integration, 
Bitbucket Server Integration, Kubernetes Integration, Docker Integration, … 
some of these might overlap or must work with each other - but sure there are a 
lot of hidden gems and simplifications which should get better attention. 
Providing a bigger picture on a specific topic (not just a single plugin) in 
the context of the whole community, might even help to coordinate plugin 
creation and feature placing in existing plugins AND deprecation of 
existing/duplicated plugins. Sure, such an initiative would need someone being 
responsible, in terms of Bitbucket, I think the best would be if Atlassian 
could step in.

Sorry for misusing this thread, but the topic just happened to raise this issue 
for me again and I’m sure I’m not the only one feeling this way...

/Domi


> On 6 Nov 2019, at 05:24, Mark Waite  wrote:
> 
> We don't have a recommended install count, though I think that is a good idea 
> for discussion.
> 
> Would you be willing to join me in a Jenkins Online Meetup 
> <https://www.meetup.com/Jenkins-online-meetup/> that can highlight the new 
> capabilities and the improvements provided by the Bitbucket Server 
> integration plugin?  
> 
> We hosted the next generation Warnings plugin in a Jenkins Online Meetup 
> <https://www.youtube.com/watch?v=0GcEqML8nys> and it helped users understand 
> the capabilities of the plugin and how it was improving the experience 
> compared to the previous plugin.  If your'e available in mid December (17, 
> 18, or 19), I could host that session in the same fashion.  If that week in 
> December does not work for you, we could host it in early January.
> 
> If you're attending DevOps World | Jenkins World 2019 in Lisbon Dec 2-5, we 
> could have you present a lightning talk in the community booth describing the 
> plugin and what it provides.
> 
> It would also be very nice to add a "Bitbucket&

Re: Feedback request: Mentioning contributors in Jenkins core changelogs

[domi]

Nice!!! +1 

> On 5 Nov 2019, at 00:29, Daniel Beck  wrote:
> 
> Thanks everyone for the suggestions addressing my concerns around minor 
> changes. I think with a list of "additional contributors" we'd properly take 
> care of them without bloating the changelog.
> 
>> On 4. Nov 2019, at 23:35, Baptiste Mathus  wrote:
>> 
>> A simple list of contributors for more trivial changes that weren't worth a
>> dedicated changelog entry seems very important to me.
> 
> A potential approach for implementing this is 
> https://github.com/jenkins-infra/jenkins.io/pull/2621, including how we'd 
> need to adapt the YAML data to make it work (also getting rid of the 
> longstanding, terrible hack with commented out entries).
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/18A77A1C-B4A6-43A9-961F-F956F5485E39%40beckweb.net.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/79C45E89-177F-4C1C-980B-4BFDD69223AD%40fortysix.ch.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[domi]

My first thought was that I would like to keep the default assignee - but after 
reading all the comments, I have to agree, that my only reason for this is so 
that I get notified by new issues. Although Oleg shoed it is possible to create 
a filter and get notified about this things, It seems quite complicated and 
many maintainers will not do it and therefore not get any info about new 
issues. So I think there should be some kind of easy way to at least inform the 
official maintainer - maybe we can even create these filters automatically…
/Domi


> On 6 Sep 2019, at 01:37, Ullrich Hafner  wrote:
> 
> Making it an optional field in the HOSTING report seems to be a good 
> compromise, so +1 from me for such a change.
> 
> (I understand that developers do not want to be assignee for issues they are 
> never going to fix. On the other hands, for a user that reports an issue it 
> is somewhat disappointing that no one actually cares about his new issue. 
> This will indicate that it is not worth to report an issue at all.)
>  
> 
>> Am 05.09.2019 um 20:40 schrieb Slide > <mailto:slide.o@gmail.com>>:
>> 
>> We should add a field in the HOSTING Jira that allows people to specify if 
>> they want to be set as the default assignee, then the bot can check that 
>> field before setting up the default assignee for the component. We would 
>> need someone with admin access on Jira to add the field. I can create a PR 
>> for the bot once the field is setup.
>> 
>> On Thu, Sep 5, 2019, 11:35 Matt Sicker > <mailto:msic...@cloudbees.com>> wrote:
>> That makes tons of sense to me. You should only assign tickets to
>> yourself that you're currently working on or at least intend to work
>> on in the near future.
>> 
>> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus > <mailto:m...@batmat.net>> wrote:
>> >
>> > I fully agree with Jesse's take. IMO for most plugins where the maintainer 
>> > is not going to have time to jump on new reports right away, this sends a 
>> > wrong message that issues will be analyzed and fixed by the assignee.
>> > This sends a second bad message: that an issue being already assigned, 
>> > this is not necessary that someone steps up to work on a fix proposal.
>> >
>> > AIUI, the default assignee is often used by maintainers as a nice way to 
>> > be notified when a new issue arises, but on average not meaning that that 
>> > given maintainer will commit to address in a timely manner anything new 
>> > that comes in.
>> >
>> > IOW, my main point is that I think we should allow maintainers to be made 
>> > default assignee, but we should default to having no default assignee.
>> >
>> > Le mar. 27 août 2019 à 15:14, Jesse Glick > > <mailto:jgl...@cloudbees.com>> a écrit :
>> >>
>> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev > >> <mailto:o.v.nenas...@gmail.com>> wrote:
>> >> > a default assignee for the component
>> >>
>> >> As always, I prefer there to be no default assignee for a JIRA
>> >> component. It is not a helpful concept IMO. If and when I decide to
>> >> tackle an issue, I will assign it to myself.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups 
>> >> "Jenkins Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an 
>> >> email to jenkinsci-dev+unsubscr...@googlegroups.com 
>> >> <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
>> >> To view this discussion on the web visit 
>> >> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
>> >>  
>> >> <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com>.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Jenkins Developers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to jenkinsci-dev+unsubscr...@googlegroups.com 
>> > <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
>> >  
>> > <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK

Re: m2Release attn Dominik Bartholdi

[domi]

Hey James,

No, I I’m not using - its years since the last time I did...
So yes, please feel free to put it up for adoption.

/Domi

> On 16 Jul 2019, at 15:19, James Nord  wrote:
> 
> Hi Dominik,
> 
> I have not used the m2release plugin for over 4 years now and have not been 
> actively maintaining it.   I don't know if you are still using the plugin 
> interested or otherwise interested in keeping things moving.
> 
> If you're not interested I'll put the plugin up for adoption.
> 
> Regards
> 
> /James
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/6fdd5cb8-2c30-4767-a7ba-ed5d1b7183da%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/6fdd5cb8-2c30-4767-a7ba-ed5d1b7183da%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/0EE19A67-5856-4359-A794-5C08A50F94C7%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Conditional CasC

[domi]

I’m not sure I missed something, is there any way to tell the CasC plugin 
load/ignore some configuration files?
My use case is the following: I have a Dockerimage which contains all required 
configuration files, but in some cases I want to load a different security 
configuration (OAuth vs. Local).
Is there any way I can do this? (Beside using groovy initscripts instead of the 
CasC configuration files)
Thanks Domi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/D7DA3592-8D8D-4EE5-AA96-D2B1221D7FAA%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Disposable Jenkins & GitOps do not make a good match

[domi]

Thanks for the explanation Jesse! I created an issue for the 
workflow-cps-plugin at https://issues.jenkins-ci.org/browse/JENKINS-54996 
/Domi

> On 3 Dec 2018, at 15:25, Jesse Glick  wrote:
> 
> On Mon, Dec 3, 2018 at 7:49 AM Tony Noble  wrote:
>> Would it not make sense to for Jenkins to at least attempt to parse the 
>> pipeline script when the job is created / amended?  Even if it ignores 
>> 'stages' and just looks at 'parameters' and 'triggers', that would at least 
>> get round not only this issue but also the need to write pipelines in such a 
>> way that they don't cause mayhem when running for the first time with no 
>> parameter definitions (or with parameter definitions that are no longer 
>> correct).
> 
> There is discussion of this general issue in JENKINS-41929. Briefly,
> for Declarative Pipelines (but not Scripted), we could in principle
> parse the definition as soon as the job is created and set the
> `List` accordingly, including parameter definitions, and
> probably also preconfigure SCM polling without relying on
> `WorkflowRun.checkouts` from an initial build.
> 
> Note that for the special case of parameter definitions, the `params`
> global variable is defined so that `defaultValue`s of parameters
> defined in the job will be honored for the parameterless initial
> build, which is a partial workaround.
> 
> As to Domi’s suggestion of having polling (on the “main repo”) be set
> up automatically for the case of a job using `CpsScmFlowDefinition`,
> yes this could work reliably for any Pipeline syntax I think, since
> the SCM information is statically available. Feel free to file an RFE
> in `workflow-cps-plugin` for it.
> 
> Anyway, the broad issue remains that Jenkins maintains a variety of
> pieces of state—distinct from configuration—in `$JENKINS_HOME`, and so
> if you blow that away, some functionality will be impaired. For the
> particular case of SCM state as described here, you can work around
> this by defining non-multibranch projects with a different build
> trigger structure using the Job DSL plugin or similar job definition
> tools, which amounts to much the same thing as Jenkins-X is doing in
> `--prow` mode at least in this respect.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr33oP9JzwbVdvyuEPfs_EKwkUTGoF8kTvTL__9TQJCezA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/98E93108-6065-439E-B061-1424AAB13D7F%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Disposable Jenkins & GitOps do not make a good match

[domi]

Yes, I do the exact same thing, there is not trigger config in the pipeline 
script - but for me this does not work the way you describe it - the job at 
least has to run once. But you seem to use the cps block instead of the cpsScm 
block for you job-dsl configuration, not sure abut this...

pipelineJob("${folderName}/install") {
  triggers {
bitbucketPush()
  }
  definition {
cpsScm { 
  scm { 
git { 
  remote {
url('https://bitbucket.org/x')
credentials('BITBUCKET_CRED')
  } 
  branches('develop') 
  scriptPath(’install.groovy') 
  lightweight(true)
  extensions { 
localBranch()
cleanCheckout()
  }  
} 
  } 
}   
  }
}

/Domi


> On 3 Dec 2018, at 13:38, Tomas Bjerre  wrote:
> 
> But I don't configure the trigger part with a pipeline script.
> 
> I use Job DSL to create a pipeline job. In that pipeline job I configure the 
> triggering-part with Job DSL and only keep the build process in the pipeline 
> script.
> 
> Then I don't have to run the pipeline script once before it all works.
> 
> Like this:
> 
> pipelineJob("my pipeline job") {
>  triggers {
>    // Job DSL with triggering configuration
>  }
>  
>  definition {
>   cps {
>script(...) //Pipeline with build process
>sandbox()
>   }
>  }
> }
> 
> 
> 
> Den mån 3 dec. 2018 kl 13:20 skrev domi  <mailto:d...@fortysix.ch>>:
> Hi Tomas,
> I do this too, but this does not mean I don’t have to start the build at 
> least once to make the webhooks work.
> /Domi
> 
>> On 3 Dec 2018, at 09:25, Tomas Bjerre > <mailto:tomas.bjerr...@gmail.com>> wrote:
>> 
>> Regarding configuration of webhooks with pipelines. This is why I always 
>> configure that with Job DSL. I configure the Jenkins job and the Git service 
>> (usually some rest-call) in the same Groovy (Job DSL) script.
>> 
>> Den måndag 3 december 2018 kl. 09:15:05 UTC+1 skrev domi:
>> Thanks Jesse, it probably is, but even though - do you see a chance to fix 
>> the issues I mentioned? 
>> e.g. why do I need to run a pipeline once before it accepts webhooks from 
>> GitHub or Bitbucket? I do understand that I can configure additional SCM 
>> sources from within a pipeline, but why does it not listen on the one I have 
>> defined on the I have defined to load the "Pipeline from SCM”? 
>> /Domi 
>> 
>> > On 30 Nov 2018, at 17:59, Jesse Glick > wrote: 
>> > 
>> > The simplest approach, starting from what you are doing now, would be 
>> > to keep the build records and other state files from your Jenkins 
>> > installation, recreating only the configuration files from Git. 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google Groups 
>> > "Jenkins Developers" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to jenkinsci-de...@googlegroups.com <>. 
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1W_8-%3DU8GJSuw_oazA0PSiXGyYDhv8mSKzLV0bScStFg%40mail.gmail.com
>> >  
>> > <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1W_8-%3DU8GJSuw_oazA0PSiXGyYDhv8mSKzLV0bScStFg%40mail.gmail.com>.
>> >  
>> > For more options, visit https://groups.google.com/d/optout 
>> > <https://groups.google.com/d/optout>. 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com 
>> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/d21bf102-f345-4c6b-a234-4ab8ad3c6995%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/d21bf102-f345-4c6b-a234-4ab8ad3c6995%40googlegroups.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/jenkinsci-dev/1gc8t6MAl4g/unsubscribe 
> <https://groups.google.com/d/topic/jenkinsci-dev/1gc8t6MAl4g/unsubscribe>.
> To unsubs

Re: Disposable Jenkins & GitOps do not make a good match

[domi]

Hi Tomas,
I do this too, but this does not mean I don’t have to start the build at least 
once to make the webhooks work.
/Domi

> On 3 Dec 2018, at 09:25, Tomas Bjerre  wrote:
> 
> Regarding configuration of webhooks with pipelines. This is why I always 
> configure that with Job DSL. I configure the Jenkins job and the Git service 
> (usually some rest-call) in the same Groovy (Job DSL) script.
> 
> Den måndag 3 december 2018 kl. 09:15:05 UTC+1 skrev domi:
> Thanks Jesse, it probably is, but even though - do you see a chance to fix 
> the issues I mentioned? 
> e.g. why do I need to run a pipeline once before it accepts webhooks from 
> GitHub or Bitbucket? I do understand that I can configure additional SCM 
> sources from within a pipeline, but why does it not listen on the one I have 
> defined on the I have defined to load the "Pipeline from SCM”? 
> /Domi 
> 
> > On 30 Nov 2018, at 17:59, Jesse Glick > wrote: 
> > 
> > The simplest approach, starting from what you are doing now, would be 
> > to keep the build records and other state files from your Jenkins 
> > installation, recreating only the configuration files from Git. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Jenkins Developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to jenkinsci-de...@googlegroups.com <>. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1W_8-%3DU8GJSuw_oazA0PSiXGyYDhv8mSKzLV0bScStFg%40mail.gmail.com
> >  
> > <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1W_8-%3DU8GJSuw_oazA0PSiXGyYDhv8mSKzLV0bScStFg%40mail.gmail.com>.
> >  
> > For more options, visit https://groups.google.com/d/optout 
> > <https://groups.google.com/d/optout>. 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/d21bf102-f345-4c6b-a234-4ab8ad3c6995%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/d21bf102-f345-4c6b-a234-4ab8ad3c6995%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/A03F3239-D428-4EC3-8167-E7C3AD02CE7C%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Disposable Jenkins & GitOps do not make a good match

[domi]

Thanks Jesse, it probably is, but even though - do you see a chance to fix the 
issues I mentioned? 
e.g. why do I need to run a pipeline once before it accepts webhooks from 
GitHub or Bitbucket? I do understand that I can configure additional SCM 
sources from within a pipeline, but why does it not listen on the one I have 
defined on the I have defined to load the "Pipeline from SCM”?
/Domi

> On 30 Nov 2018, at 17:59, Jesse Glick  wrote:
> 
> The simplest approach, starting from what you are doing now, would be
> to keep the build records and other state files from your Jenkins
> installation, recreating only the configuration files from Git.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1W_8-%3DU8GJSuw_oazA0PSiXGyYDhv8mSKzLV0bScStFg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/D3849AFD-8449-48A8-88F5-172B2111C421%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Disposable Jenkins & GitOps do not make a good match

[domi]

Thanks James, thats an interesting path, but it does look like we would have to 
build quite a lot around this to make it a good replacement of our current 
infrastructure. We also did have a look at jenkins-x, but to be honest, it is 
just way to much for us: first of all we don’t use k8s (we use cloud foundry) 
and I would say that running jenkins-x cost us more then our production 
environment, because of the number of pods (yes, we don’t have a micro service 
architecture) 
/Domi

> On 30 Nov 2018, at 15:02, James Strachan  wrote:
> 
> we solved this in Jenkins X through the use of Prow for handling webhooks & 
> orchestrating the serverless jenkins pod and then using kubernetes custom 
> resources to maintain state (pipeline activities, environments, teams, 
> releases etc)
> https://jenkins-x.io/news/serverless-jenkins/ 
> <https://jenkins-x.io/news/serverless-jenkins/>
> 
> we then use an immutable docker image of jenkins that starts up (thanks to 
> the custom war packager) and processes each pipeline execution in a separate 
> container.
> 
> 
> On Fri, Nov 30, 2018 at 1:51 PM domi  <mailto:d...@fortysix.ch>> wrote:
> Hi,
> 
> Since we now have JCasC and the job-dsl plugin it is easier then ever to 
> treat jenkins as a disposable resource and just recreate it from scratch 
> whenever you feel the need for it.
> We do have build everything around this idea and reinstall our whole build 
> infrastructure every time we need to update jenkins or even just a plugin (we 
> create a docker image with all required plugins preinstalled).
> 
> But there are two issues which hurt us quite a bit:
> 
> 1. Pipeline jobs do not listen on any commit webhooks before the job was not 
> executed at least once (in our case Bitbucket, but the same is true for 
> Github)
> 2. A multi branch pipeline (organizationFolder, *-branch-source-plugin) job 
> will trigger a build for every single branch just discovered. This is quite a 
> problem in case you have build your processes around git (some call it 
> GitOps). e.g. if every time your master branch gets build something special 
> happens: build a new release version of a library or even install something 
> to some environment.
> 
> These two issues together cause us quite some problem, because every time we 
> setup a new environment the following happens:
> 
> The branch source plugin (in our case Bitbucket) scans the whole organisation 
> for branches, will trigger builds and therefore: new releases of libraries 
> and artefacts get build and some stuff gets installed because the builds for 
> many of our ‘master’ branches are triggered too.
> Then I somehow have to trigger a build for all other pipelines (not managed 
> by the branch-source-plugin) which should listen on any git webhooks, because 
> otherwise they will never be triggered
> 
> 
> Does anyone have the same experience? How do you work around them?
> 
> I have some ideas on how to solve/ workaround it:
> - problem 1: write a plugin which is able to abort the build in case it is 
> the first run and the job is configured to listen on webhooks (e.g. Bitbucket 
> or GitHub), then after installing the fresh environment, just loop through 
> all jobs (with groovy) and trigger all which have a hook configured and let 
> the first run fail on purpose.
> - problem 2: extends 
> https://github.com/jenkinsci/basic-branch-build-strategies-plugin 
> <https://github.com/jenkinsci/basic-branch-build-strategies-plugin> to some 
> how skip some branches at the initial organisation scanning, I already 
> created an issue for this: https://issues.jenkins-ci.org/browse/JENKINS-54861 
> <https://issues.jenkins-ci.org/browse/JENKINS-54861> 
> 
> But to be very honest, most of this sound some how hackisch and I hope 
> someone else has a better idea on how to do this stuff properly.
> 
> Many thanks 
> Domi
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/FA18D443-D4CA-4512-BAD1-255D6E3385C8%40fortysix.ch
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/FA18D443-D4CA-4512-BAD1-255D6E3385C8%40fortysix.ch>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> James
> ---
> Twitter: @jstrachan
> Blog: https://medium.com/@jstrachan/ <https://medium.com/@jstrachan/>
> 
> Jenkins X

Disposable Jenkins & GitOps do not make a good match

[domi]

Hi,

Since we now have JCasC and the job-dsl plugin it is easier then ever to treat 
jenkins as a disposable resource and just recreate it from scratch whenever you 
feel the need for it.
We do have build everything around this idea and reinstall our whole build 
infrastructure every time we need to update jenkins or even just a plugin (we 
create a docker image with all required plugins preinstalled).

But there are two issues which hurt us quite a bit:

1. Pipeline jobs do not listen on any commit webhooks before the job was not 
executed at least once (in our case Bitbucket, but the same is true for Github)
2. A multi branch pipeline (organizationFolder, *-branch-source-plugin) job 
will trigger a build for every single branch just discovered. This is quite a 
problem in case you have build your processes around git (some call it GitOps). 
e.g. if every time your master branch gets build something special happens: 
build a new release version of a library or even install something to some 
environment.

These two issues together cause us quite some problem, because every time we 
setup a new environment the following happens:

The branch source plugin (in our case Bitbucket) scans the whole organisation 
for branches, will trigger builds and therefore: new releases of libraries and 
artefacts get build and some stuff gets installed because the builds for many 
of our ‘master’ branches are triggered too.
Then I somehow have to trigger a build for all other pipelines (not managed by 
the branch-source-plugin) which should listen on any git webhooks, because 
otherwise they will never be triggered


Does anyone have the same experience? How do you work around them?

I have some ideas on how to solve/ workaround it:
- problem 1: write a plugin which is able to abort the build in case it is the 
first run and the job is configured to listen on webhooks (e.g. Bitbucket or 
GitHub), then after installing the fresh environment, just loop through all 
jobs (with groovy) and trigger all which have a hook configured and let the 
first run fail on purpose.
- problem 2: extends 
https://github.com/jenkinsci/basic-branch-build-strategies-plugin to some how 
skip some branches at the initial organisation scanning, I already created an 
issue for this: https://issues.jenkins-ci.org/browse/JENKINS-54861 

But to be very honest, most of this sound some how hackisch and I hope someone 
else has a better idea on how to do this stuff properly.

Many thanks 
Domi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/FA18D443-D4CA-4512-BAD1-255D6E3385C8%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Validate Jenkinsfile while using oauth

[domi]

Thanks guys, I must have made a typo somewhere... - I did a clean setup and 
tried the whole ting again - now it works!
Many thanks!

> On 20 Nov 2018, at 06:05, Richard Bywater  wrote:
> 
> I also just today set the password in Visual Code Studio to be my API token 
> and it worked like a charm. 
> 
> Richard. 
> 
> On Tue, 20 Nov 2018, 9:36 AM Christopher Orr,  <mailto:ch...@orr.me.uk>> wrote:
> FWIW, I had no problems setting it up with an API token last week (in place 
> of a password), on a Jenkins instance that uses the Google Login plugin for 
> authentication.
> 
> 
> On Mon, 19 Nov 2018, at 13:29, domi wrote:
> > Unfortunately this does not seem to work :(
> > 
> > > On 16 Nov 2018, at 20:18, Jesse Glick  > > <mailto:jgl...@cloudbees.com>> wrote:
> > > 
> > > On Fri, Nov 16, 2018 at 8:12 AM domi  > > <mailto:d...@fortysix.ch>> wrote:
> > >> I really like the way I can validate my Jenkinsfile from within VS Code 
> > >> now: https://jenkins.io/blog/2018/11/07/Validate-Jenkinsfile/ 
> > >> <https://jenkins.io/blog/2018/11/07/Validate-Jenkinsfile/>
> > >> 
> > >> But how can I do this when I use any of the Oauth-Plugins like the one 
> > >> for Github[1] or Bitbucket [2]?
> > > 
> > > I presume that `jenkins.pipeline.linter.connector.pass` could be an
> > > API token rather than a password. In fact, it really should be, even
> > > if you are using a password-based security realm. Probably this is
> > > just a matter of fixing the documentation to clarify that.
> > > 
> > > -- 
> > > You received this message because you are subscribed to the Google Groups 
> > > "Jenkins Developers" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to jenkinsci-dev+unsubscr...@googlegroups.com 
> > > <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
> > > To view this discussion on the web visit 
> > > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3xpZPi6qU%2BaEg37Ov7Bxn7GLAP29tdc7S1_d4SCAr-jw%40mail.gmail.com
> > >  
> > > <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3xpZPi6qU%2BaEg37Ov7Bxn7GLAP29tdc7S1_d4SCAr-jw%40mail.gmail.com>.
> > > For more options, visit https://groups.google.com/d/optout 
> > > <https://groups.google.com/d/optout>.
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to jenkinsci-dev+unsubscr...@googlegroups.com 
> > <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/jenkinsci-dev/1FB72438-6AB1-4EAD-AFBF-9540101F6424%40fortysix.ch
> >  
> > <https://groups.google.com/d/msgid/jenkinsci-dev/1FB72438-6AB1-4EAD-AFBF-9540101F6424%40fortysix.ch>.
> > For more options, visit https://groups.google.com/d/optout 
> > <https://groups.google.com/d/optout>.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/1542659752.819570.1582362288.7C8253F4%40webmail.messagingengine.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/1542659752.819570.1582362288.7C8253F4%40webmail.messagingengine.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwemaOPAp-LyPJv30Eos%3D9yCdxhAOvaL4bJBg5esrnU2aA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwemaOPAp-LyPJv30Eos%3D9yCdxhAOvaL4bJBg5esrnU2aA%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/C58CA518-A25A-4807-B4B8-D30CC184525D%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Validate Jenkinsfile while using oauth

[domi]

Unfortunately this does not seem to work :(

> On 16 Nov 2018, at 20:18, Jesse Glick  wrote:
> 
> On Fri, Nov 16, 2018 at 8:12 AM domi  wrote:
>> I really like the way I can validate my Jenkinsfile from within VS Code now: 
>> https://jenkins.io/blog/2018/11/07/Validate-Jenkinsfile/
>> 
>> But how can I do this when I use any of the Oauth-Plugins like the one for 
>> Github[1] or Bitbucket [2]?
> 
> I presume that `jenkins.pipeline.linter.connector.pass` could be an
> API token rather than a password. In fact, it really should be, even
> if you are using a password-based security realm. Probably this is
> just a matter of fixing the documentation to clarify that.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3xpZPi6qU%2BaEg37Ov7Bxn7GLAP29tdc7S1_d4SCAr-jw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/1FB72438-6AB1-4EAD-AFBF-9540101F6424%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Validate Jenkinsfile while using oauth

[domi]

Hi,
I really like the way I can validate my Jenkinsfile from within VS Code now: 
https://jenkins.io/blog/2018/11/07/Validate-Jenkinsfile/ 
<https://jenkins.io/blog/2018/11/07/Validate-Jenkinsfile/>

But how can I do this when I use any of the Oauth-Plugins like the one for 
Github[1] or Bitbucket [2]?

/Domi

[1] https://plugins.jenkins.io/github-oauth 
<https://plugins.jenkins.io/github-oauth>
[2] https://plugins.jenkins.io/bitbucket-oauth

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/85C6A2FC-AA90-4B84-8FF9-185426EA606F%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Latest plugin not showing up in Update Center

[domi]

Actually, there was a glitch in the update center job just until a couple of 
minutes ago - Daniel just fixed it and it should be ok again now…
/Domi

> On 2 Nov 2018, at 08:32, Sameer  wrote:
> 
> Hi,
> 
> I have released the next version of Nirmata-Plugin a couple of hours back and 
> I find it strange for not showing up in the Plugin Manager. The plugin build 
> has also succeed 
> (https://github.com/jenkinsci/nirmata-plugin/commits/master). In past I have 
> been able to fetch the updated versions of this plugin almost instantaneously 
> post release.
> 
> Any thoughts/comments here?
> 
> Thanks,
> Sameer
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/dcd3a961-066f-44c1-a7fc-79f17751c8ce%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/dcd3a961-066f-44c1-a7fc-79f17751c8ce%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/FB2CB0B0-A441-4916-BD8C-F144ABBFD7EF%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Scriptler alpha version

[domi]

Hi all,

I finally managed to pump out a new Version of the Scriptler Plugin. It used to 
have a couple of security issues which are solved now.
Do to all the changes made, I decided to do a major version update and also 
first release a alpha version to the experimental update center (3.0-alpha): 
https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/

What do I have to do to make Scripler appear on https://plugins.jenkins.io 
again?

Regards 
Domi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6322B2D6-D97A-4B2B-BA6E-6662EECDF72B%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: repository-connector plugin maintainence

[domi]

Hey Jae,

I don’t know why my last email did not reach you, but I did answer you a few 
days ago…
Here is a copy:


Hi Jae,

There is no need to enable travis, as every Jenkins Plugin hosted in the 
Jenkins GH Org, we can make use of the Jenkins Project Infrastructure - also it 
would be very strange to have a Jenkins project to need Travis to build there 
PRs…
The Repository Connector seem not yet integrated into this env, but I think we 
should aim for this solution. Most probably the only thing missing is the 
“Jenkinsfile”: 
https://github.com/jenkinsci/config-file-provider-plugin/blob/master/Jenkinsfile
 
<https://github.com/jenkinsci/config-file-provider-plugin/blob/master/Jenkinsfile>
Here is an example of an other plugin of mine: 
https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fconfig-file-provider-plugin/activity
 
<https://ci.jenkins.io/blue/organizations/jenkins/Plugins/config-file-provider-plugin/activity>
 
In terms of the future… I think the first would be to upgrade the parent pom to 
 org.jenkins-ci.plugins:plugin this would ease a lot of things and should keep 
us up to date with the latest requirements when it comes to plugin maintenance.
Other things:
- pipeline support, I did not have the time to check 
https://github.com/jenkinsci/repository-connector-plugin/pull/21 
<https://github.com/jenkinsci/repository-connector-plugin/pull/21>
- upgrade/replace of aether, aether is no longer an active project and is now 
(as far as I understand) replaced by https://maven.apache.org/resolver/ 
<https://maven.apache.org/resolver/>

PRs: unfortunate I’m very limited in terms of time right now - but I fully 
trust you and you can move things forward! If you want me to have a look to, 
just mention me in the PR comments (@imod) and I will do my best.
Releases: the same rule as with PRs: I trust you! If you think a release is 
ready, go for it or ask me to do one. The only thing I ask you for here, is 
that you try to update the release notes on the wiki too - as a user, I hate 
releases where I have no idea what changed.

…in general: I trust you and I think that we only can move forward if we both 
do so.

Regards Domi



> On 22 Jan 2018, at 22:19, Jae Gangemi <jgang...@gmail.com> wrote:
> 
> 
>   would it be possible to get admin access to this repo? i'd like to set up 
> travis to build pull requests but i don't currently have access.
> 
>   i have cc-ed domi here. i tried reaching out to touch base and discuss this 
> last week but i have not heard back and wanted to cover my bases.
> 
>   thanks!!
> 
> 
> On Sun, Jan 14, 2018 at 1:21 PM, Baptiste Mathus <m...@batmat.net 
> <mailto:m...@batmat.net>> wrote:
> Thanks for your patience. 
> Just added you as a committer Jae. 
> 
> Obviously you will want to go through PRs for changes, and leave some time to 
> Domi to review it as much as possible.
> 
> When/if you wish to release, you'll need to file a PR against the permissions 
> repo, but that's probably not needed yet at that point. 
> 
> Cheers and welcome!
> 
> 2018-01-10 16:38 GMT+01:00 Jae Gangemi <jgang...@gmail.com 
> <mailto:jgang...@gmail.com>>:
> 
>   awesome!
> 
>   jenkins: jgangemi (jgangemi at gmail)
>   github: jgangemi
> 
> On Tuesday, January 9, 2018 at 11:39:56 PM UTC-7, domi wrote:
> Hi Jae,
> 
> I’m more then happy if you want to help out with the repository-connector!
> The reason why I did not answer to your first mail is, that my subscription 
> to the jerkins-dev googlegroup does not work anymore - I’m fighting with it 
> since months and have no idea why it does not work…
> /Domi
> 
>> On 10 Jan 2018, at 00:22, Jae Gangemi <jgan...@gmail.com <>> wrote:
>> 
>> 
>>   thanks! 
>> 
>>   adding original maintainers (as listed in wiki page) to cc list.
>> 
>> On Tue, Jan 9, 2018 at 2:36 PM, Baptiste Mathus <m...@batmat.net <>> wrote:
>> Hello!
>> 
>> Thank you for your interest! We've documented the process on this page: 
>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin 
>> <https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin>
>> 
>> To sum up, you want to put them in CC (hint: use git history, there should 
>> be a bunch of emails there in commits) here, and either they answer, or we 
>> have a typical 2 weeks timeout before giving you the necessary permissions 
>> to take over.
>> 
>> Thanks again
>> 
>> 2018-01-08 18:59 GMT+01:00 Jae Gangemi <jgan...@gmail.com <>>:
>> i'm trying to reach the maintainers of the repostitory-connector plugin to 
>> see if they are still interested in maintaining it and if not, what steps i 
>> need to do in order to take over and provide support.
>

Re: repository-connector plugin maintainence

[domi]

Hey Jae,

I don’t know why my last email did not reach you, but I did answer you a few 
days ago…
Here is a copy:


Hi Jae,

There is no need to enable travis, as every Jenkins Plugin hosted in the 
Jenkins GH Org, we can make use of the Jenkins Project Infrastructure - also it 
would be very strange to have a Jenkins project to need Travis to build there 
PRs…
The Repository Connector seem not yet integrated into this env, but I think we 
should aim for this solution. Most probably the only thing missing is the 
“Jenkinsfile”: 
https://github.com/jenkinsci/config-file-provider-plugin/blob/master/Jenkinsfile
 
<https://github.com/jenkinsci/config-file-provider-plugin/blob/master/Jenkinsfile>
Here is an example of an other plugin of mine: 
https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fconfig-file-provider-plugin/activity
 
<https://ci.jenkins.io/blue/organizations/jenkins/Plugins/config-file-provider-plugin/activity>
 
In terms of the future… I think the first would be to upgrade the parent pom to 
 org.jenkins-ci.plugins:plugin this would ease a lot of things and should keep 
us up to date with the latest requirements when it comes to plugin maintenance.
Other things:
- pipeline support, I did not have the time to check 
https://github.com/jenkinsci/repository-connector-plugin/pull/21 
<https://github.com/jenkinsci/repository-connector-plugin/pull/21>
- upgrade/replace of aether, aether is no longer an active project and is now 
(as far as I understand) replaced by https://maven.apache.org/resolver/ 
<https://maven.apache.org/resolver/>

PRs: unfortunate I’m very limited in terms of time right now - but I fully 
trust you and you can move things forward! If you want me to have a look to, 
just mention me in the PR comments (@imod) and I will do my best.
Releases: the same rule as with PRs: I trust you! If you think a release is 
ready, go for it or ask me to do one. The only thing I ask you for here, is 
that you try to update the release notes on the wiki too - as a user, I hate 
releases where I have no idea what changed.

…in general: I trust you and I think that we only can move forward if we both 
do so.

Regards Domi


> On 23 Jan 2018, at 00:07, Daniel Beck <m...@beckweb.net> wrote:
> 
> 
>> On 22. Jan 2018, at 22:19, Jae Gangemi <jgang...@gmail.com> wrote:
>> 
>>  would it be possible to get admin access to this repo? i'd like to set up 
>> travis to build pull requests but i don't currently have access.
> 
> I changed the accurev-plugin Developers team to admin access.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8F25043B-4151-435A-BA45-4B2CD82CE31D%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: repository-connector plugin maintainence

[domi]

Hi Jae,

I’m more then happy if you want to help out with the repository-connector!
The reason why I did not answer to your first mail is, that my subscription to 
the jerkins-dev googlegroup does not work anymore - I’m fighting with it since 
months and have no idea why it does not work…
/Domi

> On 10 Jan 2018, at 00:22, Jae Gangemi <jgang...@gmail.com> wrote:
> 
> 
>   thanks! 
> 
>   adding original maintainers (as listed in wiki page) to cc list.
> 
> On Tue, Jan 9, 2018 at 2:36 PM, Baptiste Mathus <m...@batmat.net 
> <mailto:m...@batmat.net>> wrote:
> Hello!
> 
> Thank you for your interest! We've documented the process on this page: 
> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin 
> <https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin>
> 
> To sum up, you want to put them in CC (hint: use git history, there should be 
> a bunch of emails there in commits) here, and either they answer, or we have 
> a typical 2 weeks timeout before giving you the necessary permissions to take 
> over.
> 
> Thanks again
> 
> 2018-01-08 18:59 GMT+01:00 Jae Gangemi <jgang...@gmail.com 
> <mailto:jgang...@gmail.com>>:
> i'm trying to reach the maintainers of the repostitory-connector plugin to 
> see if they are still interested in maintaining it and if not, what steps i 
> need to do in order to take over and provide support.
> 
> thanks!!
> 
> --
> -jae
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/cec61c51-0840-4dd8-ab7a-57136056cd49%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/cec61c51-0840-4dd8-ab7a-57136056cd49%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/jenkinsci-dev/X3nHpfaeD9M/unsubscribe 
> <https://groups.google.com/d/topic/jenkinsci-dev/X3nHpfaeD9M/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS62Kvt8Y76s4h8ep3yirks9dye1FuiCncFfPY1ODHv_qg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS62Kvt8Y76s4h8ep3yirks9dye1FuiCncFfPY1ODHv_qg%40mail.gmail.com?utm_medium=email_source=footer>.
> 
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> -jae

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7DEC60E3-A73A-4FAE-B104-E4F8188D9D9C%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

config-files on folder removed

[domi]

Hi all,

I got a very strange issue reported for the config-file-provider-plugin: 
https://issues.jenkins-ci.org/browse/JENKINS-42389 
<https://issues.jenkins-ci.org/browse/JENKINS-42389>
Basically it says that as soon as the folder configuration is changed, all 
config-files stored on that folder are removed from the folder too.

One idea that came up was that this could be caused by the fact that the 
config-file-provider uses its own screen to show the config-files and not as 
part of the settings screen of the folder itself. 
But I’m completely lost and have no idea how I could possible fix this.

Has anyone any idea?

I pushed a branch containing a test case that demonstrates the issue: 
https://github.com/jenkinsci/config-file-provider-plugin/tree/JENKINS-42389 
<https://github.com/jenkinsci/config-file-provider-plugin/tree/JENKINS-42389>
https://github.com/jenkinsci/config-file-provider-plugin/commit/679be2283e7bf812745d6278edcfdf5533a0b4d9
 
<https://github.com/jenkinsci/config-file-provider-plugin/commit/679be2283e7bf812745d6278edcfdf5533a0b4d9>

Thanks!
/Domi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/552F9732-CE6C-4043-AC8B-B97B003FCA89%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

new version not in update center

[domi]

Hi,

last Friday I made a new realise of the config-file-provider plugin (version 
2.15.3). The release went smooth, but after 3 days, the new version is still 
not visible in the update center :(

…but the artefact is available in the repo
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/config-file-provider/2.15.3/config-file-provider-2.15.3.hpi
 
<https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/config-file-provider/2.15.3/config-file-provider-2.15.3.hpi>

has any one any idea whats wrong?

thanks Domi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/86A03F31-620B-40EB-815B-EF17AAA0092C%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: connecting jenkins to artifactory

[domi]

This is exactly what 'repository connector' does - it downloads artifacts from 
a maven repository (which artifactory is just one of, an other could be nexus 
or archiva)
/domi

> Am 30.03.2016 um 20:05 schrieb sara_jenkins <sahara...@gmail.com>:
> 
> Hello Dominik, 
> 
> Thank you for your reply. 
> It seems what I am trying to achieve is different than what these plugins 
> does. 
> so here is the scenario, 
> 
> I am trying to copy alerady build files ( for instance war or zip file) from 
> artifactory and copy them to location A or Z. 
> Do you know how can I do that?
> Thank you :) 
> 
>> On Friday, March 25, 2016 at 4:42:06 PM UTC-4, sara_jenkins wrote:
>> Hello, 
>> 
>> I apologize if my question is bad or not well explained in advance. 
>> I am very new to jenkins.
>> 
>> I am trying to connect Jenkins to an existing artifactory repository. 
>> i have installed jenkins artifactory plugin and i was able to connect 
>> jenkins to existing repository( artifactory) 
>> then  installed repository connect plugin. and finally installed maven 
>> artifactory plugin 
>> 
>> i am trying to create a project to deploy codes from artifactory but i would 
>> like to have all the build( from artifactory) in a drop down menu. this drop 
>> down menu should contain all version of build inside artifactory repository.
>> i am still having an issue and i dont know what i am missing.
>> any idea? 
>> 
>> much appreciated 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/87723918-e888-4284-b39d-29ef87b3662c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/394411EB-E61E-44DA-A544-2294D0E3BD6E%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: connecting jenkins to artifactory

[domi]

I do something similar and I have the best result with combination of these two 
plugins (not using artifactory, but an other maven repo server):

https://wiki.jenkins-ci.org/display/JENKINS/Maven+Metadata+Plugin
—> get a parameter dropdown with all the artefact versions in the maven 
repository
https://wiki.jenkins-ci.org/display/JENKINS/Repository+Connector+Plugin
—> use the parameters set by the previous plugin to download the artifact to 
the workspace

/Domi



> On 28 Mar 2016, at 15:13, Oleg Nenashev <o.v.nenas...@gmail.com> wrote:
> 
> I've added jenkinsci-users to Cc.
> Most likely somebody has a hands-on experience with the latest Artifactory 
> plugin version.
> 
> BR, Oleg
> 
> пятница, 25 марта 2016 г., 21:42:06 UTC+1 пользователь sara_jenkins написал:
> Hello, 
> 
> I apologize if my question is bad or not well explained in advance. 
> I am very new to jenkins.
> 
> I am trying to connect Jenkins to an existing artifactory repository. 
> i have installed jenkins artifactory plugin and i was able to connect jenkins 
> to existing repository( artifactory) 
> then  installed repository connect plugin. and finally installed maven 
> artifactory plugin 
> 
> i am trying to create a project to deploy codes from artifactory but i would 
> like to have all the build( from artifactory) in a drop down menu. this drop 
> down menu should contain all version of build inside artifactory repository.
> i am still having an issue and i dont know what i am missing.
> any idea? 
> 
> much appreciated 
>  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/ff6715fc-15d0-48cd-a8d7-48345e7127fa%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/ff6715fc-15d0-48cd-a8d7-48345e7127fa%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4A9F5F32-C7AD-4647-85D7-F1C041D0E637%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Meet jenkins.io

[domi]

Really nice work!!!
/Domi

> On 24 Mar 2016, at 07:02, R. Tyler Croy <ty...@monkeypox.org> wrote:
> 
> I finished up the final work for migration from https://jenkins-ci.org to
> https://jenkins.io today. The final step of the switchover was to redirect
> non-mapped URLs from jenkins-ci.org over to jenkins.io.
> 
> 
> This project has been a tremendous amount of work with Gus Reiber, Baptiste
> Mathaus, James Dumay, Daniel Beck, Oleg Nenashev  and a number of other
> contributors filling in the new website with CSS, Haml, and most importantly
> AsciiDoc (for documentation!)
> 
> 
> Some of the features of jenkins.io that are important to me, I'd like to 
> share:
> 
> * Visual priority given to the LTS release line (yay)
> * Built-in support for three layers of documentation: solution pages, getting
>   started guides and the "handbook".
> * Visual elements to highlight upcoming events
> * Certificates automated via letsencrypt.org (this is my favorite ;))
> 
> The site is statically generated and contributions are welcome here:
><https://github.com/jenkins-infra/jenkins.io>
> 
> 
> As I mentioned in our last project meeting, migration of other properties such
> as wiki.jenkins-ci.org to the jenkins.io domain will take a bit more time. 
> This
> is an important first step however!
> 
> 
> 
> Cheers
> - R. Tyler Croy
> 
> --
> Code: <https://github.com/rtyler>
>  Chatter: <https://twitter.com/agentdero>
> 
>  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
> --
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/20160324060209.GB15060%40blackberry.coupleofllamas.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/509BAC1C-7F4D-47B6-85BA-5964EF6695DE%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: react on failed tests in pipeline script

[domi]

Thanks!
For now I go with this (I hate whitelisting...):
if(currentBuild.result != null && !"SUCCESS".equals(currentBuild.result)) {
...
}

> On 22 Mar 2016, at 09:42, Robert Sandell  wrote:
> 
> Pro tip, requires some "custom whitelisting":
> 
> AbstractTestResultAction testResultAction = 
> currentBuild.rawBuild.getAction(AbstractTestResultAction.class)
> if (testResultAction != null) {
>echo "Tests: ${testResultAction.failCount} 
> ${testResultAction.failureDiffString} failures of 
> ${testResultAction.totalCount}.\n\n"
> }
> 
> On Tue, Mar 22, 2016 at 5:12 AM, Michael Neale  > wrote:
> OK sorry for the confusion, 
> 
> but you should be able to do what you do (so it doesn't fail on the sh step, 
> but then marks the build as UNSTABLE in the junit archive step).
> Then currentBuild.result should have the current build status (or another 
> item in currentBuild, sorry am not sure). 
> 
> On Tuesday, March 22, 2016 at 3:03:12 PM UTC+11, Michael Neale wrote:
> Right but then without the step failure how can you trap the failure to send 
> the failure email (seems clumsy to have to let the step fail, and then record 
> archive results in the exception handler). 
> 
> On Tuesday, March 22, 2016 at 2:51:31 PM UTC+11, Andrew Bayer wrote:
> I think the Junit result archiver should mark the build as unstable if there 
> are failures...
> 
> On Mar 21, 2016 7:16 PM, "Michael Neale" > wrote:
> I am assuming that ignoring test failures doesn't make the shell step fail? 
> (Ie it returns a success code?)
> 
> If so, removing that and putting try/catch around it and then the archive 
> step in the exception handler along with email could work. There may be a 
> better way though (as that seems clumsy)
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-de...@googlegroups.com <>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/8617dfa6-1348-4a16-93c3-eff3dfca871a%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/26c5a998-58e2-423b-bc53-8fae37399207%40googlegroups.com
>  
> .
> 
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Robert Sandell
> Software Engineer
> CloudBees Inc.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS38jF3XSveXTp_J2KW3UYF5YnsNuACfVAg235PQpBuc1g%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/E5A89E0B-CA64-4FA0-88EE-9B8C994D8F29%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

react on failed tests in pipeline script

[domi]

Hi,

I’m trying to find a way how I can react on test failures. e.g. I run maven 
with the flag to ignore test failures so the job does not stop. But in case a 
test failure was discovered, I would like to send a mail or  chat message - how 
can I do that?

   sh 'mvn clean install -B -Dmaven.test.failure.ignore'
   step([$class: 'JUnitResultArchiver', testResults: 
'**/target/surefire-reports/*.xml’])

   if(testFailure) {
   // send notification
   }

regards Domi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/A81A74D0-1EC9-41DA-A258-328768D6E7A7%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: I dont want "Restrict where this project can be run"

[domi]

You can define some restrictions on where a job is allowed to be executed with 
this https://wiki.jenkins-ci.org/display/JENKINS/Job+Restrictions+Plugin 
<https://wiki.jenkins-ci.org/display/JENKINS/Job+Restrictions+Plugin>
/Domi

> On 16 Mar 2016, at 16:12, Brian Stinson <br...@bstinson.com> wrote:
> 
> On Mar 16 07:40, Oleg Nenashev wrote:
>> Hi,
>> 
>> AFAIK there is no feature in Jenkins core allowing to hide it. I doubt you 
>> can solve it via plugin.
>> Could you clarify the use-case?
>> 
>>   - Why do you want to hide it? 
>>   - What behavior do you expect from Jenkins scheduler when it's hidden?
>> 
>> In any case, you can hide the control using siome Javascript code in 
>> SimpleThemePlugin.
>> 
>> 
>> BR, Oleg
>> 
>> среда, 16 марта 2016 г., 12:31:31 UTC+1 пользователь rahul gupta написал:
>>> 
>>> 
>>> Hi Team,
>>> 
>>> 
>>> 
>>> I am new to this group but using Jenkins from last many years. I need one 
>>> help/suggestion before I start writing own Jenkins Plug-in.
>>> 
>>> 
>>> 
>>> *Issue:*
>>> 
>>> 
>>> 
>>> On Every Jenkins job configuration, we have option "Restrict where this 
>>> project can be run". I don't want this option visible to the developers who 
>>> configure.
>>> 
>>> I couldn’t find any alternate so planning to write own plugin.
>>> 
>>> 
>>> 
>>> Kindly suggest.
>>> 
>>> 
>>> 
>>> Kr,
>>> 
>>> Rahul
>>> 
>>> 
>>> 
>>> 
> 
> I can think of a use-case where you would want to administratively set
> the labels based on username/group in a multi-tenant installation.
> 
> Example:
> jobs created by users in the 'project1' group always get routed to the
> 'project1' label
> 
> Cheers!
> 
> --Brian 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/20160316151211.GI27133%40ender.bstinson.lan
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/20160316151211.GI27133%40ender.bstinson.lan>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/05DD4B92-194F-4220-B6CA-55313ACD5450%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub Organization Folder polish

[domi]

I fully agree, but that in my opinion just means we need a generalisation with 
specific implementations for each of the supported SCM host implementations.
…and some might actually just change the labels…
The only thin I wanted to bring a cross, is that everyone is only talking about 
GH, but there are others on the marked too and they have the exact same concept 
- so if thing like this get implemented, then it would be wise to have some 
kind of abstraction.
my 2cents…
/Domi



> On 07 Mar 2016, at 13:01, Robert Sandell <rsand...@cloudbees.com> wrote:
> 
> and IIRC GitLab calls an Organisation/Team for Group and merge requests 
> instead of pull requests, but it's still the same thing in the end.
> 
> But the terminology chosen is imho quite important, because teams adopt the 
> terms used by their tools in everyday "shop talk". So I find that it's quite 
> important that there are as many commonalities as possible and Jenkins should 
> try to use the same terms as the scm it is modelling, at least in the UI, or 
> confusion will arise.
> 
> /B
> 
> 
> On Sat, Mar 5, 2016 at 2:42 PM, domi <d...@fortysix.ch 
> <mailto:d...@fortysix.ch>> wrote:
> A team in BB is pretty much the same as an organization in GH. I know the 
> current implementation is based in GH proprietary implementations, but I just 
> wanted to say that this is maybe possible to generalize. E.g. The 
> organization/team is used to distinguish and group repositories on both GH 
> and BB, also both are part of the git repository url. Also both support PRs. 
> So from an outside perspective I don' see why the concepts of this plugins 
> would not work for both (independent of how the are currently implemented).
> Also, think about it - at many places in IT we talk about being independent 
> of any vendor stuff. How about being able to switch from BB to GH or anywhere 
> else but not having to change anything in the build pipeline except the repo 
> url?
> /Domi
> 
> > Am 05.03.2016 um 10:54 schrieb Manuel Jesús Recena Soto <rec...@gmail.com 
> > <mailto:rec...@gmail.com>>:
> >
> > Hello Domi,
> >
> > GitHub uses: Organization, repository, collaborator, etc..
> > BitBucket uses: Team, repository, groups, etc..
> >
> > I'm not sure how to generalize all these services and products.
> >
> > Additionally, this plugin declares a dependency with
> > github-branch-source. It seems clearly focused on GitHub.
> >
> > Regards,
> >
> > 2016-03-05 10:07 GMT+01:00 domi <d...@fortysix.ch 
> > <mailto:d...@fortysix.ch>>:
> >> Would it be possible to generalize this GH stuff a bit more? From what I 
> >> know, most git hosting services have the notion of 
> >> organizations,repos,PRs... eg. GH,Bitbucket,gitlab?,gitblit?
> >> I know GH is the most prominent, but ... yeah...
> >> /Domi
> >>
> >>> Am 05.03.2016 um 01:12 schrieb Daniel Beck <m...@beckweb.net 
> >>> <mailto:m...@beckweb.net>>:
> >>>
> >>>
> >>>> On 05.03.2016, at 00:45, Kohsuke Kawaguchi <k...@kohsuke.org 
> >>>> <mailto:k...@kohsuke.org>> wrote:
> >>>>
> >>>> I've synced up with Jesse & Manuel offline, and now the work is in here 
> >>>> if anyone is interested.
> >>>
> >>> Correct link (not much to look at on master yet): 
> >>> https://github.com/jenkinsci/github-organization-folder-plugin/pull/1 
> >>> <https://github.com/jenkinsci/github-organization-folder-plugin/pull/1>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups 
> >>> "Jenkins Developers" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send an 
> >>> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> >>> <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
> >>> To view this discussion on the web visit 
> >>> https://groups.google.com/d/msgid/jenkinsci-dev/B99A9F05-F3FA-4550-88AA-069E291DA7E6%40beckweb.net
> >>>  
> >>> <https://groups.google.com/d/msgid/jenkinsci-dev/B99A9F05-F3FA-4550-88AA-069E291DA7E6%40beckweb.net>.
> >>> For more options, visit https://groups.google.com/d/optout 
> >>> <https://groups.google.com/d/optout>.
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "Jenkins Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, sen

Re: GitHub Organization Folder polish

[domi]

A team in BB is pretty much the same as an organization in GH. I know the 
current implementation is based in GH proprietary implementations, but I just 
wanted to say that this is maybe possible to generalize. E.g. The 
organization/team is used to distinguish and group repositories on both GH and 
BB, also both are part of the git repository url. Also both support PRs. So 
from an outside perspective I don' see why the concepts of this plugins would 
not work for both (independent of how the are currently implemented).
Also, think about it - at many places in IT we talk about being independent of 
any vendor stuff. How about being able to switch from BB to GH or anywhere else 
but not having to change anything in the build pipeline except the repo url?
/Domi

> Am 05.03.2016 um 10:54 schrieb Manuel Jesús Recena Soto <rec...@gmail.com>:
> 
> Hello Domi,
> 
> GitHub uses: Organization, repository, collaborator, etc..
> BitBucket uses: Team, repository, groups, etc..
> 
> I'm not sure how to generalize all these services and products.
> 
> Additionally, this plugin declares a dependency with
> github-branch-source. It seems clearly focused on GitHub.
> 
> Regards,
> 
> 2016-03-05 10:07 GMT+01:00 domi <d...@fortysix.ch>:
>> Would it be possible to generalize this GH stuff a bit more? From what I 
>> know, most git hosting services have the notion of 
>> organizations,repos,PRs... eg. GH,Bitbucket,gitlab?,gitblit?
>> I know GH is the most prominent, but ... yeah...
>> /Domi
>> 
>>> Am 05.03.2016 um 01:12 schrieb Daniel Beck <m...@beckweb.net>:
>>> 
>>> 
>>>> On 05.03.2016, at 00:45, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
>>>> 
>>>> I've synced up with Jesse & Manuel offline, and now the work is in here if 
>>>> anyone is interested.
>>> 
>>> Correct link (not much to look at on master yet): 
>>> https://github.com/jenkinsci/github-organization-folder-plugin/pull/1
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/B99A9F05-F3FA-4550-88AA-069E291DA7E6%40beckweb.net.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/7D293532-AB0D-4335-BC09-0E14F3093A3D%40fortysix.ch.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Manuel Recena Soto
> * manuelrecena.com [/blog]
> * linkedin.com/in/recena
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CABa-Uod%2BRWb6mX6jaDTfPEts_iz07yTqB1pRNCtOH06kG%3DBQ7w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/B8F92295-C428-4D5A-9A61-760EDF91319B%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub Organization Folder polish

[domi]

Would it be possible to generalize this GH stuff a bit more? From what I know, 
most git hosting services have the notion of organizations,repos,PRs... eg. 
GH,Bitbucket,gitlab?,gitblit?
I know GH is the most prominent, but ... yeah...
/Domi

> Am 05.03.2016 um 01:12 schrieb Daniel Beck <m...@beckweb.net>:
> 
> 
>> On 05.03.2016, at 00:45, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
>> 
>> I've synced up with Jesse & Manuel offline, and now the work is in here if 
>> anyone is interested.
> 
> Correct link (not much to look at on master yet): 
> https://github.com/jenkinsci/github-organization-folder-plugin/pull/1
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/B99A9F05-F3FA-4550-88AA-069E291DA7E6%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7D293532-AB0D-4335-BC09-0E14F3093A3D%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [update] SimpleBuild DSL for pipeline (now a plugin)

[domi]

This sounds interesting, although I have to admit that the number of DSL 
plugins do get me confused a bit…
- How does this one relate to the pipeline plugin? hmm, can they work together?
- I thought the Jenkinsfile belong to the multi branch plugin?
…I'm confused… and I’m sure others are too…

...oh and there is the Job DSL plugin, it has a totally different purpose, but 
I think people will mix up this one into the game too

..confusing

/Domi


> On 18 Feb 2016, at 08:58, Michael Neale <mne...@cloudbees.com> wrote:
> 
> I mentioned some time back 
> <https://groups.google.com/forum/#!searchin/jenkinsci-dev/simpleBuild/jenkinsci-dev/XalfegulIEQ/VhY8xbzxCwAJ>
>  a bout the simpleBuild DSL for easy builds. 
> 
> This let you do things like: 
> 
> simpleBuild {
> docker_image = "golang"
> 
> env = [
> FOO : 42,
> BAR : "YASS"
> ]
> 
> 
> before_script = "echo before"
> script = 'echo after $FOO'
> 
> 
> notifications = [
> email : "mne...@cloudbees.com"
> ]
> 
> 
> }
> 
> Well thanks to Andrew Bayer and looking at how GlobalVariable works, this is 
> now a plugin: 
> 
> https://github.com/michaelneale/jenkinsfile
> 
> so no messing around with global lib or whitelists (it comes with its own). 
> 
> If people are interested I will fork this over into jenkinsci org and 
> possibly do a release (to main repo) so people can easily kick it around 
> (also very very interested in feature requests in how to grow it to match 
> what people expect). 
> 
> 
> Side effect: Adding a DSL to make a plugin is as easy as 1) writing the DSL 
> and 2) creating a class like: 
> https://github.com/michaelneale/jenkinsfile/blob/master/src/main/java/org/jenkinsci/plugins/simplebuild/SimpleBuildDSL.java
>  and wrapping it up as a plugin. This is pattern I would like to encourage as 
> it gives you versioning and easy distribution - and even TESTING of your DSL!
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/b4898c98-f01a-4c09-9f85-3db738ca1e8d%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/b4898c98-f01a-4c09-9f85-3db738ca1e8d%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7B709F07-ECF4-462D-9B73-D6FA36A4DA7E%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Hints for Jenkins Plugin Development

[domi]

Maybe worth to take a look at this: 
https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over
/Domi

> On 12 Feb 2016, at 15:52, 'konrad' via Jenkins Developers 
> <jenkinsci-dev@googlegroups.com> wrote:
> 
> I'm about to develop a plugin for Jenkins which should post some build 
> artifacts of some builds of some jobs to an external service.
> 
> More specifically:
> 
> on a per-project basis, configure one or more files to be 
> deployable/releasable and add some file specific properties that influence 
> the HTTP post triggered later by the user
> in the build details view (e.g. build #12), display a 'release file x', 
> 'release file y' button for every configured file (similar location on the UI 
> side like the 'keep this build forever' button)
> then post this file to the service
> Maybe someone who knows the plugin API a bit more than me can give me a hint 
> on which extension points I'll need. Right know I am looking into the 
> BuildWrapper for the per-job configuration and I think I'll need a customer 
> Action which I register to the build details view, but I am not sure how to 
> do that. I don't think I can use the ArtifactManager because it looks like 
> this one automatically iterates over all archived files as a build step.
> 
> Thanks you :-)
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/b545ad1d-3b61-490a-93ec-991312cd3db2%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/b545ad1d-3b61-490a-93ec-991312cd3db2%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/83B371A6-BFDF-4A97-951B-E65985ACE3D4%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Bitbucket Server plugin

[domi]

Ok, i see - then this has to be made very clear in the names, artifactids and 
the documentation. As artifactids of existing plugins can't be changed without 
any impact for the enduser (we don't have an alias system), this should at 
least be done for new ones.
So then yes I think renaming should be fine (this was done for other plugins 
too) - maybe add a comment to the docu about the original name.
Domi

> Am 04.02.2016 um 20:02 schrieb Tomas Bjerre <tomas.bjerr...@gmail.com>:
> 
> When responding to this, you should know that "Bitbucket" and "Bitbucket 
> Server" are two different products, with different API:s.
> 
> Get commits from Bitbucket:
> https://confluence.atlassian.com/bitbucket/commits-or-commit-resource-389775478.html#commitsorcommitResource-GETacommitslistforarepositoryorcomparecommitsacrossbranches
> 
> Get commits from Bitbucket Server:
> https://developer.atlassian.com/static/rest/bitbucket-server/4.3.1/bitbucket-rest.html#idp2523328
> 
> Browse the API:s and you will see more examples.
> 
> In my opinion, the naming is confusing. But that is a decision made by 
> Atlassian and nothing we can change. We can reduce the confusion by renaming 
> the stash-plugins to bitbucket-server-plugins. Because as more and more users 
> move to Bitbucket Server, people will forget that it was once called Stash.
> 
> 
> 2016-02-04 16:39 GMT+01:00 domi <d...@fortysix.ch>:
>> not sure about this, there are already a couple of bitbucket plugins and all 
>> of these address the hosted service bitbucket.
>> /Domi
>> 
>> 
>>> On 04 Feb 2016, at 16:38, Tomas Bjerre <tomas.bjerr...@gmail.com> wrote:
>>> 
>>> Now that "Atlassian Stash" has changed name to "Atlassian Bitbucket 
>>> Server", perhaps some of the plugins 
>>> (https://github.com/jenkinsci?utf8=%E2%9C%93=stash) should also 
>>> change name. Or they can all be merged into 1 single plugin "Bitbucket 
>>> Server plugin". What do you think?
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/3c33d9b6-8b8a-490e-83f6-9bc424de2bbf%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-dev/ZZNVeE6mdA0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/9F4305C0-80FF-4180-B7AD-9B4C4BB61FBD%40fortysix.ch.
>> 
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAK89W5KKNePJphN6BgN1_nR6cGiDwYnnJmoJT4MwoBrGg8vpNQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CC39C8AA-D251-44A0-B307-51A2DE15F05B%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Bitbucket Server plugin

[domi]

not sure about this, there are already a couple of bitbucket plugins and all of 
these address the hosted service bitbucket.
/Domi


> On 04 Feb 2016, at 16:38, Tomas Bjerre <tomas.bjerr...@gmail.com> wrote:
> 
> Now that "Atlassian Stash" has changed name to "Atlassian Bitbucket Server", 
> perhaps some of the plugins 
> (https://github.com/jenkinsci?utf8=%E2%9C%93=stash) should also change 
> name. Or they can all be merged into 1 single plugin "Bitbucket Server 
> plugin". What do you think?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/3c33d9b6-8b8a-490e-83f6-9bc424de2bbf%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/3c33d9b6-8b8a-490e-83f6-9bc424de2bbf%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/9F4305C0-80FF-4180-B7AD-9B4C4BB61FBD%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: simpleBuild - a pipeline DSL (and a sad tale about sandboxes)

[domi]

I guess you already tried to prove the required calls in the script security 
plugin?
https://wiki.jenkins-ci.org/display/JENKINS/Script+Security+Plugin
/Domi


> On 04 Feb 2016, at 09:07, Michael Neale <mne...@cloudbees.com> wrote:
> 
> Inspired by Jesse's example 
> <https://github.com/jenkinsci/workflow-examples/blob/master/global-library-examples/global-function/standardBuild.groovy>
>  DSL using docker workflow, I thought I would see how far I could take things 
> in making DSLs. 
> I wanted to make things that looked very similar to what people do with tools 
> like travis - something at home in a Jenkinsfile that anyone can open, and 
> read and immediately comprehend, for simple cases, what the build 
> instructions are. 
> 
> This is mostly pretty easy: I have put it here for now 
> https://github.com/michaelneale/jenkinsfile 
> <https://github.com/michaelneale/jenkinsfile> (until I sort out some issues). 
> It can work with or without docker workflow (you just specify an image, or 
> not), sends emails (even in failure), set environment variables etc, of 
> course I would love for it to do more. 
> 
> However, one road block has been my use of literal maps and the sandbox. This 
> all works grand if I don't use the sandbox, but use the sandbox (or 
> multibranch/SCM, which enables sandbox), and sadness results that I can't 
> work out how to get around:
> 
> org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts 
> not permitted to use field java.util.HashMap$Node key
>   at 
> org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectField(StaticWhitelist.java:169)
>   at 
> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.rejectField(SandboxInterceptor.java:195)
>   at 
> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:
> 
> - this shows up when I enable the sandbox (sadbox?). 
> 
> It seems NOTHING in java.util.Map is whitelisted. I am using maps at the 
> moment as it makes for a nice DSL similar to what people may see elsewhere. 
> For example: 
> 
> simpleBuild {
> 
> script = 'echo after $FOO'
> 
> notifications = [
> email : "mne...@cloudbees.com"
> ]
> 
> env = [
> FOO = "well hello",
> BAR = "I don't even need to be here"
> ]
> 
> }
> 
> This is valid and works great *without* sandbox, but fails on notifications 
> with sandbox on.  The notifications item (config.notifications in the DSL, 
> from the closure passed into simpleBuild) is a java.util.Map. If I look 
> closer, its actually a LinkedHashMap. 
> 
> Does any one have ideas on ways to get around this? the literal map notation 
> is very neat, and would take no time for someone to glance at and follow, 
> however, I don't see a way of working with a Map (I can call size() it seems, 
> but nothing else, I can't get the values() or keySet() collections etc). 
> 
> Any ideas appreciated (perhaps using maps is inferior to another approach, 
> which I would like to see, however, I love the idea of staying in 
> pipieline-groovy script, with a DSL, as this takes away NONE of the power). 
> 
> 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/685d07ee-0748-4666-924b-015113392ad7%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/685d07ee-0748-4666-924b-015113392ad7%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6498A1FA-11AB-457E-802F-3A2248A5F73D%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[domi]

+100

> Am 18.01.2016 um 10:35 schrieb arodrig...@cloudbees.com:
> 
> Hi all,
> 
> Please find below a proposal for a new parent POM for Jenkins Plugins.
> 
> Motivation
> 
> The main driver to propose a revision of the parent plugin POM is to decouple 
> this artifact from the Jenkins Core:
> Simplifying the mechanism to build and test a plugin against different core 
> versions.
> Decoupling build-related aspects, such as static analysis tools, JRE 
> signatures, etc. from the baseline core versions, as they are totally 
> independent concerns, reducing the need to include otherwise common 
> configuration in each plugin POM just because we want to support and older 
> baseline.
> 
> One use case that would greatly benefit from this change is for example, 
> jenkins#1530, where it is necessary to propose API changes in core and 
> matching plugin usages. The current plugins/pom.xml does not work if you mvn 
> deploy a SNAPSHOT revision. Plugin Compatibility Testing can also benefit 
> from this change.
> 
> Approach
> 
> As stated above the approach is based in making the plugin parent POM 
> independent of the main Jenkins core project, and performing the following 
> actions:
> Make the Jenkins Core version to use configurable via a property, so that a 
> simple mvn -Djenkins.version= hpi:run is enough to compile and run a 
> plugin with a different core version. 
> Make the Jenkins Test Harness version to use also configurable (the default 
> being the same Jenkins core version), for those cases that may need it, such 
> as copyartifact#76.
> Reduce the number of Maven plugin pinned versions to those really used.
> Reduce the number of number of elements (versions, etc) overridable via 
> properties to those that have a specific reason, setting the values to those 
> intended to be used. There’s no reason to make everything overridable as the 
> parent pom evolution is now independent of the baseline Jenkins Core versions.
> 
> Other aspects included:
> Default configuration for findbugs, including the possibility of 
> automatically activating exclusions, and a property to define if findbug 
> errors should break the build (default true).
> JRE signature verification configured to the Java level defined for the build 
> (using a property as well).
> Regarding releases:
> Launching javadoc:javadoc in the prepare phase, in order to avoid the 
> inconvenience “stricter” Java 8 javadoc breaking builds in the release phase.
> Skipping tests in the release phase, cutting release build times for plugins 
> with a great number of tests.
> General cleanup.
> 
> Ok, show me the code
> 
> The current proposal is being pushed to 
> https://github.com/andresrc/plugin-pom. It is not deployed to any repository 
> yet, so in order to test it a local install is required. The artifactId is 
> intentionally changed to avoid confusion. JIRA issue [JENKINS-32493] has been 
> filed.
> 
> Some plugins have been used to verify the current proposal, including:
> Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
> Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
> Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
> Script Security: https://github.com/jenkinsci/script-security-plugin/pull/36
> Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
> 
> There is also an update on the Maven archetype at 
> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
> 
> Next Steps
> 
> After collecting feedback from the community and if there’s certain consensus 
> about going forward the next steps would be:
> Create a repository for the artifact in jenkinsci.
> Decide the final artifact maven coordinates.
> Perform a release.
> Update the documentation (wiki, etc.)
> Upgrade some plugins to use the new POM in order to drive adoption.
> Upgrade to PCT to support it.
> 
> Thanks!
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/a0668ee9-908d-42c1-9b18-a98751869572%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/45406653-4295-4BD6-AC1B-B8624354F0A6%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Looking for input: Workflow scripting best practices

[domi]

This might be an interesting one: 
http://technologyconversations.com/2015/12/08/blue-green-deployment-to-docker-swarm-with-jenkins-workflow-plugin/
 
<http://technologyconversations.com/2015/12/08/blue-green-deployment-to-docker-swarm-with-jenkins-workflow-plugin/>
/Domi

> On 10 Dec 2015, at 15:47, Andrew Bayer <andrew.ba...@gmail.com> wrote:
> 
> Hey all!
> 
> I'm about to start working on a resource for Workflow scripting best 
> practices, and thought I'd ask y'all if you have any good pointers to start 
> from - existing blog posts, docs, etc, examples of what you think are 
> particularly good Workflow scripts in GitHub or elsewhere, and so on. I'll 
> pull those together with what I've already got to get the core of things 
> together, and then open it up to everyone to edit and update going forward. 
> Thanks!
> 
> A.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOYx_682u%3DQ2Mw4Jnxr%2BS-z909fxsja%2BgDkppkdQeaO1dA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOYx_682u%3DQ2Mw4Jnxr%2BS-z909fxsja%2BgDkppkdQeaO1dA%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/73B1B186-4D42-4CAB-A31C-CFD9CAD2DBFA%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

DigitalOcean plugin has no docu

[domi]

Also the DigitalOcean plugin has no wiki page, but has successfully done a 
release…
/Domi

> Begin forwarded message:
> 
> From: Dominik Bartholdi <dominik.bartho...@yooture.com>
> Date: 3 December 2015 at 21:09:15 GMT+1
> To: d...@fortysix.ch
> Subject: Tweet by Jenkins releases on Twitter
> 
>   Jenkins releases (@jenkins_release 
> <https://twitter.com/jenkins_release?refsrc=email=11>)
> 03.12.15 18:50 
> <https://twitter.com/jenkins_release/status/672473002118742018?refsrc=email=11>
> DigitalOcean plugin 0.8 dlvr.it/CvvBcL <https://t.co/4vgE1EYG4y> #jenkinsci 
> <https://twitter.com/search?q=%23jenkinsci=hash>
> Download <https://twitter.com/download?ref_src=MailTweet-iOS> the Twitter app

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/88C12297-0D00-4AB9-8E49-597E383954E0%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: DigitalOcean plugin has no docu

[domi]

I think thats a good idea - and yes I think we should not tweet about such 
plugins either.
Actually the @ejnkins_release should be cleaned up a bit to, it tweets every 
release twice with just some minutes difference.
/Domi


> On 04 Dec 2015, at 10:24, Baptiste Mathus <m...@batmat.net> wrote:
> 
> Hi Domi,
> 
> Not sure there's currently plan to forbid releases upfront who don't have a 
> wiki page, though that could indeed be more direct. Don't know if like with 
> Nexus one can write such things in Artifactory.
> BUT as Andrew's thread, the thing is that those plugins are soon gonna become 
> invisible from the update center. Question is indeed, then, if we want to 
> keep tweeting them btw. 
> 
> Interesting for those trying to keep this clean, but maybe not for the bigger 
> crowd indeed. I guess I'll add an item to the next gov meeting about it? WDYT?
> 
> Cheers
> 
> 2015-12-04 9:10 GMT+01:00 domi <d...@fortysix.ch <mailto:d...@fortysix.ch>>:
> Also the DigitalOcean plugin has no wiki page, but has successfully done a 
> release…
> /Domi
> 
>> Begin forwarded message:
>> 
>> From: Dominik Bartholdi <dominik.bartho...@yooture.com 
>> <mailto:dominik.bartho...@yooture.com>>
>> Date: 3 December 2015 at 21:09:15 GMT+1
>> To: d...@fortysix.ch <mailto:d...@fortysix.ch>
>> Subject: Tweet by Jenkins releases on Twitter
>> 
>>  Jenkins releases (@jenkins_release 
>> <https://twitter.com/jenkins_release?refsrc=email=11>)
>> 03.12.15 18:50 
>> <https://twitter.com/jenkins_release/status/672473002118742018?refsrc=email=11>
>> DigitalOcean plugin 0.8 dlvr.it/CvvBcL <https://t.co/4vgE1EYG4y> #jenkinsci 
>> <https://twitter.com/search?q=%23jenkinsci=hash>
>> Download <https://twitter.com/download?ref_src=MailTweet-iOS> the Twitter app
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/88C12297-0D00-4AB9-8E49-597E383954E0%40fortysix.ch
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/88C12297-0D00-4AB9-8E49-597E383954E0%40fortysix.ch?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> Baptiste  MATHUS - http://batmat.net <http://batmat.net/>
> Sauvez un arbre,
> Mangez un castor !
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS66v2qxn3QKDWoAnWNBLSENTDev013N6NomnTA8EsZm7w%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS66v2qxn3QKDWoAnWNBLSENTDev013N6NomnTA8EsZm7w%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/C0CA94C2-F040-4FCF-965B-40B4E7E7C237%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Procedure for submitting new repositories to github/jenkinsci?

[domi]

there is also the repos for all kind of scripts: 
https://github.com/jenkinsci/jenkins-scripts 
<https://github.com/jenkinsci/jenkins-scripts>
/Domi


> On 24 Nov 2015, at 20:56, R. Tyler Croy <ty...@monkeypox.org> wrote:
> 
> (replies inline)
> 
> On Tue, 24 Nov 2015, Jorge Castro wrote:
> 
>> Hello Jenkins community!
>> 
>> The Ubuntu Cloud team has been maintaining a service deployment script 
>> (called a charm) for Jenkins for a few years now:
>> 
>> - https://jujucharms.com/jenkins/ <https://jujucharms.com/jenkins/>
> 
> 
> I suggest following this procedure:
> https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Requesthosting
>  
> <https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Requesthosting>
> and just mentally redact the word "plugin" from the instructions :)
> 
> 
> 
> 
>> It uses the official Jenkins packages and let's users model a multi-node 
>> Jenkins deployment for a variety of clouds. Last year I added it as a 
>> deployment option on the Ubuntu page for Jenkins, and I recently updated it 
>> with the latest information. We now consider the charm to be production 
>> ready, has tests, and is used in production for all of our Jenkins needs at 
>> Ubuntu and Canonical. 
>> 
>> We're interested in putting this closer to Jenkins users (like the puppet 
>> and chef modules) so that people who are interested in cloud deployments of 
>> Jenkins can benefit from the work we've put into it, and of course 
>> contribute if they're so inclined. We're committed to maintaining this code 
>> in github.com/jenkinsci. Since our charm isn't a plugin per se I just 
>> wanted to post on the list for some feedback on how to proceed. 
>> 
>> Thanks! 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/2a968b60-b096-4bda-8c59-d4a6c693c42d%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> - R. Tyler Croy
> 
> --
> Code: <https://github.com/rtyler <https://github.com/rtyler>>
>  Chatter: <https://twitter.com/agentdero <https://twitter.com/agentdero>>
> 
>  % gpg --keyserver keys.gnupg.net <http://keys.gnupg.net/> --recv-key 3F51E16F
> --
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/20151124195636.GJ23766%40blackberry.coupleofllamas.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/20151124195636.GJ23766%40blackberry.coupleofllamas.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/D955851B-36AF-4D83-9F53-B65D395713EF%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: New Plugin Request: slack-webhook-plugin

[domi]

+1 for merging and adding a feature flag in the global configuration to enable 
one or/and the other functionality 
/Domi


> On 22 Nov 2015, at 21:27, Daniel Beck <m...@beckweb.net> wrote:
> 
> Would it make sense to integrate this into the Slack Plugin? I mean, it's in 
> the other direction, but still…
> 
> On 22.11.2015, at 07:32, David Pires <david.pi...@gmail.com> wrote:
> 
>> Hi all,
>> 
>> I'd like to host my plugin on jenkins-ci.org.
>>  • url: https://github.com/dpires/jenkins-slack-webhook-plugin
>>  • name: slack-webhook
>>  • github username: dpires
>>  • jenkins-ci.org username: dpires
>>  • description: A Jenkins plugin that exposes an endpoint to be used by 
>> a Slack outgoing-webhook for ChatOps interactions (listing projects, 
>> building projects, getting build information etc.)
>> Thanks,
>> David
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/0f4bc3d7-d490-4eb8-b052-7d4c1b793488%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/33BCC4B0-2E04-47AB-A57E-0D83C22E7B7D%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/51E91CDE-1D99-4DF7-B203-D35E59E668C9%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: New Plugin hosting request: Docker Ephemeral Cloud

[domi]

To be honest, the whole list of jenkins docker plugins feels like a zoo and 
there is no way a normal user can keep up and make the right choice.
I think this work should be coordinated better and an uptodate comparison 
should be kept at a central place.
..my 2cents
/Domi


> On 18 Nov 2015, at 15:26, Kanstantsin Shautsou <kanstantsin@gmail.com> 
> wrote:
> 
> 
> 
> On Tuesday, November 17, 2015 at 7:28:00 PM UTC+3, Jesse Glick wrote:
> On Mon, Nov 16, 2015 at 10:02 PM, kmbulebu <kmbu...@gmail.com > 
> wrote: 
> > I believe the real horse race is between the 
> > underlying docker libraries. In the end, we'll likely have a clear winner, 
> > and can standardize a group of plugins around that. Perhaps docker-commons 
> > becomes that focal point, and we have smaller plugins that deliver slaves, 
> > build steps, workflow DSL, etc. 
> 
> Seems reasonable to me to have smaller plugins with focused features, 
> and a little competition. I would not object to hosting as is, 
> provided that plugin wikis clearly link to alternatives. 
> 
> IIUC the main differences between your plugin and the `Cloud` portion 
> of the `docker` plugin are 
> 
> · Different client libraries. No clear winner yet. 
> I created small thread between docker-java and docker-client to unify 
> efforts, but obviously it will be long time action and probably will have no 
> results. Both libraries missing different things, but technically 
> docker-client doesn't support callbacks for long running commands. 
> 
> · Slave launcher: yours uses JNLP; `docker` plugin currently ships 
> SSH, has JNLP support in code but disabled. 
> It was disabled because of lack of integration tests, ssh launching 
> stabilisation was very hard and i didn't want to have broken instances with 
> one more untested launcher. Those PR that tried enable JNLP was not exactly 
> how it was planned to work from design view point.
> 
> If you can later reach consensus with the `docker` plugin devs on the 
> approach to take for a general-purpose Docker cloud provider, it 
> should be possible to unify code into a new plugin release. Automatic 
> migration of user settings will be a bit trickier but is possible. 
> As soon as @magnayn likes "master development" without test cases he will of 
> course merge any changes. So you are free to submit any PRs to docker-plugin 
> now.  
> 
> By the way your comparison chart neglected to mention 
> 
> https://github.com/ndeloof/docker-slaves-plugin 
> <https://github.com/ndeloof/docker-slaves-plugin> 
> 
> which is a novel approach that I think is very promising. 
> Very promising thing will be finally implement normal Cloud API in core (or 
> in plugin but provide normal extension points) because docker is not only the 
> single cloud provider.
> 
> PS i'm co-maintainer of docker-java atm and working on one more docker cloud 
> plugin for jenkins which from my viewpoint will have the best implementation 
> of currently possible state. 
> TLS support in docker-plugin is also possible (or even already works) because 
> docker-java resolves system variables for connection builder (though there is 
> no right implementation for this field).
> PPS From tech viewpoint i see that "ephemeral cloud" has queue lock issues 
> and shading. But if this plugin solves user issue, then it should be hosted 
> and allow people experiment on it.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/d10a18f3-1c8c-4398-aecb-b9e474818ff4%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/d10a18f3-1c8c-4398-aecb-b9e474818ff4%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/127A6A84-F1F2-42C6-9195-922972EA3D68%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Access Environment variables

[domi]

or use the token-macro plugin - it also expands environment variables:
https://wiki.jenkins-ci.org/display/JENKINS/Token+Macro+Plugin
/Domi


> On 29 Oct 2015, at 11:57, Ullrich Hafner <ullrich.haf...@gmail.com> wrote:
> 
> See 
> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/Util.java#L139
>  
> <https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/Util.java#L139>
> 
>> Am 29.10.2015 um 11:53 schrieb Thilina Madhusanka <thili...@wso2.com 
>> <mailto:thili...@wso2.com>>:
>> 
>> Hi
>> 
>> thanks for the reply 
>> 
>> this  is what i need to do. 
>> 
>> i need to save a report that generate from a plugin with user given env 
>> variable append to report file name. 
>> 
>> user need to input file name any string but when user input string with env 
>> variable  
>> 
>> for example id user enter report name as reportname-${BUILD_NUMBER} 
>> is there a way to directly convert this env variable in to the value? 
>> 
>> or i have to check it and then call get method to get value for that env 
>> variable and append it to report name? 
>> 
>> thanks
>>  
>> On Thursday, October 29, 2015 at 4:14:06 PM UTC+5:30, Ullrich Hafner wrote:
>> Yes.
>> 
>> You can get the variables e.g. from the current build:
>> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L2207
>>  
>> <https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Run.java#L2207>
>> 
>> 
>>> Am 29.10.2015 um 10:52 schrieb Thilina Madhusanka <thil...@wso2.com 
>>> >:
>>> 
>>> Hi
>>> 
>>> Is there a way to access jenkins env variables via a plugin ? 
>>> 
>>> take input like ${BUILD_NUMBER}  to a plugin via test input box? 
>>> 
>>> thanks
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to jenkinsci-de...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/535f94c2-85c1-46b3-9cf4-6a7054a05146%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/535f94c2-85c1-46b3-9cf4-6a7054a05146%40googlegroups.com?utm_medium=email_source=footer>.
>>> For more options, visit https://groups.google.com/d/optout 
>>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com 
>> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/2bc65ecf-ebc0-4656-b1cf-2940f65d0d5f%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/2bc65ecf-ebc0-4656-b1cf-2940f65d0d5f%40googlegroups.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/D41EFD48-2C04-4FF2-BFB9-D507B305787E%40gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/D41EFD48-2C04-4FF2-BFB9-D507B305787E%40gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/75EB133F-1744-410D-A471-8F887AA2C382%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Request review and comments: Copyartifact 2.0

[domi]

please also consider good workflow integration and think about this can be 
easily configured in a DSL style
Domi


> On 27 Oct 2015, at 23:58, Ikedam <de...@ikedam.jp> wrote:
> 
> Hello.
> 
> I'm developing a big change for copyartifact plugin, which I plan to release 
> as copyartifact-2.0.
> I want reviews and comments for this change.
> 
> https://wiki.jenkins-ci.org/display/JENKINS/Preview+for+Copy+Artifact+2.0
> https://github.com/jenkinsci/copyartifact-plugin/pull/71
> https://github.com/ikedam/copyartifact-plugin/tree/feature/JENKINS-24892_CopyArtifact2.0
> 
> I plan to start beta-testing as git-plugin did 
> (https://wiki.jenkins-ci.org/display/JENKINS/Git+plugin+2.0+beta+testing),
> after adding more texts (javadocs and helps) and unit tests for new features.
> 
> Regards,
> ikedam
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/f818a86d-3cf7-40c7-8982-9744c7e269be%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/f818a86d-3cf7-40c7-8982-9744c7e269be%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2BE14BB0-EB5D-48CC-A04C-6D85CBD48544%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [proposal] coding style for core (jenkins 2.0?)

[domi]

I think formatting is a must and I would have loved to have such rules when I 
started to work on jenkins some years ago. Personally I think that the longer 
we wait to introduce this, the more it will hurt.
I’m happy to volunteer in the adoption of such formatting rules for my plugins 
- but I would love to have them defined in a central place.
Domi


> On 26 Oct 2015, at 23:53, Mark Waite <mark.earl.wa...@gmail.com> wrote:
> 
> 
> 
> On Mon, Oct 26, 2015 at 4:24 PM Nigel Magnay <nigel.mag...@gmail.com 
> <mailto:nigel.mag...@gmail.com>> wrote:
> Both will be acceptable in styling. That lines are about logic that analysing 
> tool can’t know.
> 
> ​Bingo.
> 
> "Automatic code formatters"​ don't know the semantics of what they're 
> formatting, so you apply them end up with gigantic concatented lines 
> (sometimes split to 80 columns, as if we're still producing punched cards). 
> 
> This is clearly worse than the "unformatted" case - where the author has 
> carefully aided the maintainer by splitting on semantically distinct sections.
> 
> By all means, have some IDE defaults that can be picked up (e.g: spaces or 
> tabs, tabstops, whether to use '*' imports or not), but auto-code formatters 
> are evil.
> 
> 
> You describe things with a very broad brush.  Earlier you extrapolated from a 
> request to format code into a comment about management measuring the 
> irrelevant.  Now you're declaring that the benefits my team of 10+ (using 
> extreme programming as our methodology, pair programming everything, test 
> driven development, etc.) found from automated code formatting over multiple 
> years of working together should be ignored because "auto-code formatters are 
> evil".  The sole specific example you offer is that calls to fluent API's 
> aren't we'll preserved by automatic code formatters.
> 
> Can you offer other concrete examples of cases (preferably in the existing 
> code) where an automatic formatter will have a serious negative impact?
> 
> When I look at the git-client-plugin source code, I find relatively few cases 
> of the fluent calls being badly damaged by an automatic formatter.  There are 
> many fluent calls, but most of them will be untouched by an automatic 
> formatter.
> 
> There is a trade-off between the simplicity of automatically maintained code 
> format (with occasional sub-optimal formatting as a result of the automation) 
> and the work I must do on every pull request to not make code formatting 
> consistency worse in the two plugins I maintain.
> 
> I only maintain two plugins of the 1000+, so I accept that I should not be 
> considered as a major influence in the final decision.
> 
> Mark Waite
>  
>  
> or 
> periodFormatter = new 
> PeriodFormatterBuilder().printZeroAlways().appendDays().appendSuffix("d 
> ").appendHours().appendSuffix("h ")
> .appendMinutes().appendSuffix("m").toFormatter();
> <——— scroll ——>
> 
> P.S. Am i alone who receives emails from Nigel with small blue font?
> 
> 
>> On Oct 27, 2015, at 01:02, Nigel Magnay <nigel.mag...@gmail.com 
>> <mailto:nigel.mag...@gmail.com>> wrote:
>> 
>> You don't need to trial automatic code formatting it to know it's going to 
>> produce a terrible result.
>> 
>> Trivial example 101. Which is the more easily parseable to the human eye?
>> 
>> periodFormatter = new PeriodFormatterBuilder()
>> .printZeroAlways()
>> .appendDays().appendSuffix("d ")
>> .appendHours().appendSuffix("h ")
>> .appendMinutes().appendSuffix("m")
>> .toFormatter();
>> 
>> or
>> 
>> periodFormatter = new PeriodFormatterBuilder().printZeroAlways().appendDays()
>>   .appendSuffix("d ").appendHours().appendSuffix("h 
>> ")
>>   .appendMinutes().appendSuffix("m").toFormatter();
>> 
>> 
>> I know which I'd rather be faced with when maintaining code.
>> 
>> On Mon, Oct 26, 2015 at 9:55 PM, Mark Waite <mark.earl.wa...@gmail.com 
>> <mailto:mark.earl.wa...@gmail.com>> wrote:
>> 
>> 
>> On Mon, Oct 26, 2015 at 1:21 PM Stephen Connolly 
>> <stephen.alan.conno...@gmail.com <mailto:stephen.alan.conno...@gmail.com>> 
>> wrote:
>> I think that the best way to do this is via an experiment in plugins... If 
>> we get a critical mass of plugins adopting a mostly similar set of rules 
>> then and only then should we think about applying them 

Re: Jenkins 2.0 proposal

[domi]

Yes, I also think it's more about the system configuration then about projects.
Domi

> On 23.10.2015, at 23:39, Richard Bywater <rich...@byh2o.com> wrote:
> 
> My impression was that they were talking about system configuration which 
> presumably isn't touched in the areas you mention?
> 
> Richard.
> 
> 
>> On Fri, 23 Oct 2015 10:13 pm Jesse Glick <jgl...@cloudbees.com> wrote:
>> On Fri, Oct 23, 2015 at 4:53 AM, d...@fortysix.ch <d...@fortysix.ch> wrote:
>> > They have some points compared to jerkins: 
>> > http://concourse.ci/concourse-vs.html#jenkins
>> > ..specially:
>> > - every configuration must be backed in a version control system
>> > - first class support for pipelines
>> 
>> Yes, it is an interesting read. I think multibranch Workflow plus
>> Docker integration starts to close the gap on these two bullet points.
>> (See my recent webinar for background.) It is not the same as having a
>> system designed according to these principles from the start.
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr11DM64CJYwBPga7YN3fRWz7tUqpqpgbKLucR-K2eZYpA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMui944Q9mBvbkzEx3DgQax%2Bum1UqxGG9R%2BfMV%2BVs1kV3LJctA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4309F0EE-54A7-4C8F-B965-21903F2F9031%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.0 proposal

[domi]

Yes, and that's also the reason why I think Jenkins should not get a database 
backend  for any configuration but only for build results and tracking 
Domi

> On 24.10.2015, at 12:37, Christopher Orr <ch...@orr.me.uk> wrote:
> 
> It seems they're talking about both system configuration and job
> configuration — in the next section, talking about Travis, they refer to
> keeping job config in SCM (via `.travis.yml`) as a good thing.
> 
> 
>> On 23/10/15 23:39, Richard Bywater wrote:
>> My impression was that they were talking about system configuration
>> which presumably isn't touched in the areas you mention?
>> 
>> Richard.
>> 
>> 
>> On Fri, 23 Oct 2015 10:13 pm Jesse Glick <jgl...@cloudbees.com
>> <mailto:jgl...@cloudbees.com>> wrote:
>> 
>>On Fri, Oct 23, 2015 at 4:53 AM, d...@fortysix.ch
>><mailto:d...@fortysix.ch> <d...@fortysix.ch
>><mailto:d...@fortysix.ch>> wrote:
>>> They have some points compared to jerkins:
>>http://concourse.ci/concourse-vs.html#jenkins
>>> ..specially:
>>> - every configuration must be backed in a version control system
>>> - first class support for pipelines
>> 
>>Yes, it is an interesting read. I think multibranch Workflow plus
>>Docker integration starts to close the gap on these two bullet points.
>>(See my recent webinar for background.) It is not the same as having a
>>system designed according to these principles from the start.
>> 
>>--
>>You received this message because you are subscribed to the Google
>>Groups "Jenkins Developers" group.
>>To unsubscribe from this group and stop receiving emails from it,
>>send an email to jenkinsci-dev+unsubscr...@googlegroups.com
>><mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
>>To view this discussion on the web visit
>>
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr11DM64CJYwBPga7YN3fRWz7tUqpqpgbKLucR-K2eZYpA%40mail.gmail.com.
>>For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to jenkinsci-dev+unsubscr...@googlegroups.com
>> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAMui944Q9mBvbkzEx3DgQax%2Bum1UqxGG9R%2BfMV%2BVs1kV3LJctA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMui944Q9mBvbkzEx3DgQax%2Bum1UqxGG9R%2BfMV%2BVs1kV3LJctA%40mail.gmail.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/562B5F80.4050401%40orr.me.uk.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/A2EEDA2C-A0BB-42CD-8FAF-2C59245AE0ED%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin releases Twitter bot source?

[domi]

and by the way: it also tweet every release twice…
/Domi

> On 20 Oct 2015, at 15:07, Christopher Orr <ch...@orr.me.uk> wrote:
> 
> Hi all,
> 
> I just saw this, which claims Log Parser 2.0 is a new plugin:
> https://twitter.com/jenkins_release/status/656450179571150849
> 
> I know it's not a new plugin, and the artifactId hasn't changed, and the
> Update Centre JSON looks good (i.e. we haven't accidentally released a
> duplicate of the existing plugin).
> 
> So I *assume* the Twitter bot flagged it as a new release because the
> *groupId* changed in the POM since the last release?  It would be nice
> to confirm this, but I don't know where the source code is, or where the
> bot runs.
> 
> This is just out of curiosity, so it's not really important — but I find
> it quite a useful resource, so it would be nice to know where it runs,
> and how contributions can be made.  Does anybody know? :)
> 
> Regards,
> Chris
> 
> PS. If anyone knows where the JIRA SCM link daemon lives, that would
> also be nice to know!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/56263C96.6070605%40orr.me.uk.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/84392762-167A-4D59-B312-811AC25EF0A0%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Problems releasing plugin "[ERROR] ssh: Could not resolve hostname : Name or service not known"

[domi]

Do you have the credentials for the maven repo defined in your settings.xml as 
described here? 
https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Releasingtojenkinsci.org
Domi

> On 19 Oct 2015, at 08:34, Joachim Kuhnert <joachim.kuhn...@piketec.com> wrote:
> 
> Hello everybody,
>  
> I am still unable to release our plugin. As described I can release to GitHub 
> if I omit the password and user name parameters but copying to the Jenkins 
> maven repository fails. If I declare Dusername and Dpassword mvn release will 
> fail to push anything to GitHub because it tries to use password an username 
> instead of ssh. I would be grateful if anybody can help. James Nord already 
> indicated that I do not need to use password and username parameters but it 
> is a bit frustrating that I do not get the last step working.
>  
> Best Regards
> Joachim
>  
> ---
> Joachim Kuhnert
> fon: +49 30 394 09 683 39
>  
> PikeTec GmbH, Waldenserstr 2-4, 10551 Berlin
> Geschäftsführer: Eckard Bringmann, Andreas Krämer, Jens Lüdemann
> Sitz der Gesellschaft: Berlin
> Handelsregister: Amtsgericht Berlin HRB 105491 B
> LinkedIn <https://www.linkedin.com/company/piketec-gmbh>|Facebook 
> <https://www.facebook.com/PikeTec>|Twitter 
> <https://twitter.com/piketec>|Youtube <https://www.youtube.com/user/piketec>
>  
> Von: jenkinsci-dev@googlegroups.com <mailto:jenkinsci-dev@googlegroups.com> 
> [mailto:jenkinsci-dev@googlegroups.com 
> <mailto:jenkinsci-dev@googlegroups.com>] Im Auftrag von Joachim Kuhnert
> Gesendet: Dienstag, 13. Oktober 2015 11:15
> An: jenkinsci-dev@googlegroups.com <mailto:jenkinsci-dev@googlegroups.com>
> Betreff: AW: Problems releasing plugin "[ERROR] ssh: Could not resolve 
> hostname : Name or service not known"
>  
> Thank you for your answer. If I omit username and password the maven 
> execution will run much longer and is nearly successful but will fail to copy 
> the hpi-File to Jenkins-ci.org <http://jenkins-ci.org/> which seems 
> reasonable to me.
>  
> [INFO] [INFO] --- maven-deploy-plugin:2.6:deploy (default-deploy) @ 
> piketec-tpt ---
> [INFO] [INFO] Uploading: 
> http://maven.jenkins-ci.org:8081/content/repositories/releases/com/piketec/jenkins/plugins/piketec-tpt/6.1/piketec-tpt-6.1.hpi
>  
> <http://maven.jenkins-ci.org:8081/content/repositories/releases/com/piketec/jenkins/plugins/piketec-tpt/6.1/piketec-tpt-6.1.hpi>
> [INFO] [INFO] Uploading: 
> http://maven.jenkins-ci.org:8081/content/repositories/releases/com/piketec/jenkins/plugins/piketec-tpt/6.1/piketec-tpt-6.1.pom
>  
> <http://maven.jenkins-ci.org:8081/content/repositories/releases/com/piketec/jenkins/plugins/piketec-tpt/6.1/piketec-tpt-6.1.pom>
> [INFO] [INFO] 
> 
> [INFO] [INFO] BUILD FAILURE
> [INFO] [INFO] 
> 
> [INFO] [INFO] Total time: 50.538 s
> [INFO] [INFO] Finished at: 2015-10-13T09:31:00+02:00
> [INFO] [INFO] Final Memory: 58M/574M
> [INFO] [INFO] 
> 
> [INFO] [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on 
> project piketec-tpt: Failed to deploy artifacts: Could not transfer artifact 
> com.piketec.jenkins.plugins:piketec-tpt:hpi:6.1 from/to maven.jenkins-ci.org 
> <http://maven.jenkins-ci.org/> 
> (http://maven.jenkins-ci.org:8081/content/repositories/releases 
> <http://maven.jenkins-ci.org:8081/content/repositories/releases>): Failed to 
> transfer file: 
> http://maven.jenkins-ci.org:8081/content/repositories/releases/com/piketec/jenkins/plugins/piketec-tpt/6.1/piketec-tpt-6.1.hpi
>  
> <http://maven.jenkins-ci.org:8081/content/repositories/releases/com/piketec/jenkins/plugins/piketec-tpt/6.1/piketec-tpt-6.1.hpi>.
>  Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
> [INFO] [ERROR]
> [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with 
> the -e switch.
> [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [INFO] [ERROR]
> [INFO] [ERROR] For more information about the errors and possible solutions, 
> please read the following articles:
> [INFO] [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException 
> <http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException>
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> ---

Re: Jenkins 2.0 proposal

[domi]

Hey Baptiste, this is a really great idea!!!
since a while I’m not in the position to deal with the setup of my instance 
myself, but I remember when I had to give advices to all different departments 
in my old organisation - automated setup of a new CI/CD environment is a really 
important thing and specially in big organisations where things are to be setup 
in a more controlled manner.
Also I could imagine that this wold also be very helpful in the scope of 
testing jenkins itself, e.g. integration tests or even unit tests.
/Domi


> On 07 Oct 2015, at 22:05, Baptiste Mathus <m...@batmat.net> wrote:
> 
> Another idea I'll dump here. it's still a bit fluffy, but anyway.
> 
> I think that with the config-management/devops trend, it would be a good 
> thing that Jenkins can really be configured from scratch through (most simple 
> possible) CLI/API calls. It's currently possible but requires a quite 
> high-level knowledge of Jenkins internals to achieve (groovy scripts, and so 
> on).
> 
> For the jobs part, IMO things like the Job DSL Plugin to handle job 
> versioning and durable management are great. And that would be great to have 
> an equivalent for the instance. 
> Something like a high-level language (say DSL) to describe the server 
> configuration.config itself.
> 
> Maybe this is not something necessarily breaking things, hence not 
> necessarily related to 2.0, but perhaps some contract/interface could be 
> introduced in plugins to kind of standardize that discovery and be able to 
> offer a standard API to configure Jenkins?
> 
> The area to handle off the top of my head:
> * Core configuration (slaves, tools...)
> * Plugins to install (see also 
> https://github.com/jenkinsci/docker/blob/master/README.md#installing-more-tools
>  
> <https://github.com/jenkinsci/docker/blob/master/README.md#installing-more-tools>
>  for reference/example)
> * Plugins config
> * Jobs
> 
> My 2 cents
> 
> 2015-10-07 19:39 GMT+02:00 Kohsuke Kawaguchi <k...@kohsuke.org 
> <mailto:k...@kohsuke.org>>:
> Right, I remember looking at DotCi and thinking that the way it moved the 
> storage to mongodb points toward an abstraction we can build.
> 
> Similar hook already exists for artifacts, and then we can provide auxiliary 
> BLOB store for plugins that write random bits of data under builds, jobs, etc.
> 
> Over time we can move things one by one to the BLOB store like that, then at 
> that point we have filesystem free Jenkins.
> 
> 
> 2015-10-06 11:18 GMT-07:00 Surya Gaddipati <suryapraka...@gmail.com 
> <mailto:suryapraka...@gmail.com>>:
> Regarding backend solution. We use DotCi and store all builds/logs in 
> mongodb.( Still experimenting how to properly store logs in the db, but we 
> have it working on staging). 
> 
> The only things on disks are plugins and folder config.xml ( because of this 
> issue https://github.com/jenkinsci/jenkins/pull/1762 
> <https://github.com/jenkinsci/jenkins/pull/1762>, jenkins deletes anything 
> not on disk from memory ). I need to spend time to fix the issue in jenkins 
> properly. 
> 
> 
> Once that is done. We can have things like, deploying on heroku , true load 
> balancing with multiple masters. 
> 
> One more thing that is preventing from from jenkins from being used in any 
> serious installations is heavily thread locked Queue implementation. We are 
> having to do strange workarounds with our jenkins because it threadlocks 
> under even medium loads ( I saw this mentioned in google's slides for JUC 
> too, curious what their solution was ) . 
> 
> An extension point for queue would be great so we can store queue in redis or 
> something.
> 
> 
> Surya
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/9d9e1968-b7c7-4296-899c-f2b05f10ac6a%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/9d9e1968-b7c7-4296-899c-f2b05f10ac6a%40googlegroups.com?utm_medium=email_source=footer>.
> 
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> Kohsuke Kawaguchi
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...

Re: Jenkins 2.0 proposal

[domi]

I feel the same way as Andrew, I remember when we where talking about things we 
would have loved to do but where afraid to do because of backward compatibility 
- the answer coming up that time always was: we can do this with v2.0, but not 
now yet. Although I really think the direction we are going now is the right 
one, I sometimes would wish for more courage - I’m sure the v2.0 label will be 
accepted by our users to take some extra effort when upgrading.
/Domi


> On 07 Oct 2015, at 21:57, Andrew Bayer <andrew.ba...@gmail.com> wrote:
> 
> So looking back over the thread - my concerns have pretty much all been about 
> missed opportunities to address stability and performance issues that may 
> require more work in core than we normally do in a release (not necessarily 
> compatibility-breaking ones). In the 7 or so years I've been involved with 
> the project, there've been many times when we've said "Well, maybe we'll do 
> that in Jenkins 2.0" so seeing 2.0 coming without the opportunity to make 
> those sorts of changes takes a bit to get used to. =)
> 
> But! The branding/messaging stuff has value - well, most of it - I'll fight 
> to the death against jenkins.cd <http://jenkins.cd/>. =) I know I've been a 
> really big fan of curated plugin packs or something along those lines to help 
> users get up and running, and the UI framework definitely needs a complete 
> refresh. Yeah, my dreams of Jenkins 2.0 going out the door with a drastically 
> revamped storage backend and better support for analytics aren't going to 
> happen - but that doesn't mean they *won't* happen in 2.20, 2.30, etc. The 
> plugin compatibility testing is going to be something hugely useful for 
> making significant changes to the core in the future - if we can get a good 
> regression testing framework that covers a broad array of plugin use cases, 
> we can be more liberal in changing core in the future. 
> 
> 2.0 isn't going to be what I've always thought 2.0 would be. It's not going 
> to fit the semantic versioning definition of a major version change. But 2.0 
> is still a good way to label the kind of UX/on boarding changes that are so 
> central to what Kohsuke's proposing. Let's take this as an opportunity to 
> figure out how to do planning for significant changes and new features in 
> core that take time to deliver - this time, it's user experience, look and 
> feel, and out of the box that are the main focus, but perhaps when 2.0 is out 
> the door, we will focus another couple months of work on storage and memory 
> utilization, or plugin cleanup, or...
> 
> A.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOZaTbv6LQqPvDV56tWSxbX1Au%3DBC2uBcAwc0cxqL17OpA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOZaTbv6LQqPvDV56tWSxbX1Au%3DBC2uBcAwc0cxqL17OpA%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/89E9EE3F-FD8E-44FD-9BF5-AF5FB05770CA%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Good pratices for workflow plugin support

[domi]

These are some really good hints, they should be added to the workflow 
documentation 
Domi

> On 15.09.2015, at 20:28, Jesse Glick <jgl...@cloudbees.com> wrote:
> 
>> On Tue, Sep 15, 2015 at 9:24 AM, jcsirot <jcsi...@gmail.com> wrote:
>> I am currently working on the support of the workflow plugin for the ansible
>> plugin and I'm facing some questions.
> 
> Happy to help! BTW if you have a PR in progress, feel free to CC
> @jglick on it. Also if there is a JIRA issue open, mark with the
> `workflow` label, and make sure
> `jenkinsci/workflow-plugin/COMPATIBILITY.md` links to it.
> 
> Did you attend my recent Office Hour on Workflow-related plugin
> development, or watch the recorded video?
> https://www.youtube.com/watch?v=4zdy7XGx3PA
> 
> Also: 
> https://github.com/jenkinsci/workflow-plugin/blob/master/COMPATIBILITY.md#plugin-developer-guide
> 
>> 1. I wonder which versions of jenkins and workflow plugin I should use in
>> the pom.xml? For the moment I'm using Jenkins 1.580.1 and workflow 1.4.2 but
>> the docker workflow plugin is using Jenkins 1.596.1 and workflow
>> 1.7-alpha-1.
> 
> Or the latest versions of Workflow (1.8+) requires 1.609.1+. Up to
> you; depends on your sensitivity to locking out users of old LTS
> lines, vs. being able to use features of, and test against, the latest
> upstream software. WF 1.4.2 + Jenkins 1.580.1 is the most conservative
> choice.
> 
>> 2. Should I extend AbstractSynchronousNonBlockingStepExecution or
>> AbstractStepExecutionImpl?
> 
> If you are indeed using WF 1.10+ with
> `AbstractSynchronousNonBlockingStepExecution` available, use it in
> preference to `AbstractSynchronousStepExecution` in most cases.
> 
>> I'm not sure the clearly understand the impact of
>> synchronous and asynchronous executions on the workflow engine. An example
>> of AbstractStepExecutionImpl implementation would be greatly appreciated
> 
> So if you *are* writing a custom step, you would use the more general
> `AbstractStepExecutionImpl` if your step needs to initiate some
> process, then wait (say, for an external service to call you back),
> then do something else later. You would also use it if your step
> `takesImplicitBlockArgument` (so invoked with a `{…}` closure). If the
> step just does something and exits as soon as it can, it is a
> synchronous step.
> 
>> 3. Should I upgrade the Builder subclass to implement the SimpleBuildStep
>> interface?
> 
> That is the easiest approach to compatibility. There is no need for
> any Workflow APIs at all. Your builder will behave exactly as it does
> in a freestyle build. You get less flexibility this way: for example,
> you lose the option of running the build step outside of a `node {}`
> block, even if it does not actually need a slave/workspace.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3qzE5AbOs-gY%2B9etdPSA%2Bb5GZhf1CyPLiyPu4MCYKqZQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6730167D-41A0-44A9-BA3C-F1DE741C60BA%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Hosting a new Plugin - Percentage DiskSpace usage column

[domi]

would this not make more sense to be included in 
https://wiki.jenkins-ci.org/display/JENKINS/Disk+Usage+Plugin ?
/Domi

On 02 Sep 2015, at 11:58, Victor Martinez <victormartinezru...@gmail.com> wrote:

> I've already created the wiki page: 
> https://wiki.jenkins-ci.org/display/JENKINS/PercentageColumn+Plugin
> 
> Cheers
> 
> On Tuesday, 1 September 2015 23:26:35 UTC+2, Victor Martinez wrote:
> Hi there,
> 
> I've been working on some Jenkins automation to monitor those slaves and have 
> some specific disk space cleanup policy, rather than using absolute diskspace 
> usage metrics I wanted to use % disk space usage column in the Manage Nodes 
> page.
> Github repo: https://github.com/v1v/percentagecolumn-plugin
> repository name: percentagecolumn-plugin
> Github user: v1v
> jenkins-ci.org: v2v
> Description: This plugin just shows the percentage of disk space usage column 
> on "Manage Nodes" page.
> Wiki: https://wiki.jenkins-ci.org/display/JENKINS/PercentageColumn+Plugin 
> (Not Yet)
> Looking forward for having some feedback.
> 
> Thanks,
> 
> Víctor
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/11ecf834-9753-4fd7-a1a1-9311d69ccb57%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7FE97DEE-386C-4931-8382-99E398FF26D7%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Hosting a new Plugin - Percentage DiskSpace usage column

[domi]

>From an enduser perspective I think these two things provide similar 
>information (one just more fine grained) and I would rather have both in the 
>same plugin - the name DiskUsage Plugin just screens for this functionality
…just my 2 cents
/Domi

On 02 Sep 2015, at 16:31, Victor Martinez <victormartinezru...@gmail.com> wrote:

> Exactly, it does provide a simple use case for monitoring total disk space & 
> percentage of usage since Jenkins doesn't provide those details
> Víctor
> 
> On Wednesday, 2 September 2015 13:52:22 UTC+2, Richard Bywater wrote:
> I'm not sure they are the same thing. If I read it correctly, one (Disk Usage 
> Plugin) appears to be the amount of usage a job uses, whilst the % Disk Space 
> plugin proposed here simply translates the free/total disk space to a 
> percentage on the Nodes list.
> 
> Richard.
> 
> On Wed, 2 Sep 2015 at 23:29 domi <do...@fortysix.ch> wrote:
> would this not make more sense to be included in 
> https://wiki.jenkins-ci.org/display/JENKINS/Disk+Usage+Plugin ?
> /Domi
> 
> On 02 Sep 2015, at 11:58, Victor Martinez <victormar...@gmail.com> wrote:
> 
>> I've already created the wiki page: 
>> https://wiki.jenkins-ci.org/display/JENKINS/PercentageColumn+Plugin
>> 
>> Cheers
>> 
>> On Tuesday, 1 September 2015 23:26:35 UTC+2, Victor Martinez wrote:
>> Hi there,
>> 
>> I've been working on some Jenkins automation to monitor those slaves and 
>> have some specific disk space cleanup policy, rather than using absolute 
>> diskspace usage metrics I wanted to use % disk space usage column in the 
>> Manage Nodes page.
>> Github repo: https://github.com/v1v/percentagecolumn-plugin
>> repository name: percentagecolumn-plugin
>> Github user: v1v
>> jenkins-ci.org: v2v
>> Description: This plugin just shows the percentage of disk space usage 
>> column on "Manage Nodes" page.
>> Wiki: https://wiki.jenkins-ci.org/display/JENKINS/PercentageColumn+Plugin 
>> (Not Yet)
>> Looking forward for having some feedback.
>> 
>> Thanks,
>> 
>> Víctor
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/11ecf834-9753-4fd7-a1a1-9311d69ccb57%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/7FE97DEE-386C-4931-8382-99E398FF26D7%40fortysix.ch.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/f4d74d56-0b16-4e66-aabb-1edac0d13b02%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8D1061BF-9985-4E4F-8680-77083F85358A%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: hpi:run error

[domi]

yes, just follow the presented link


On 31 Aug 2015, at 13:38, Gilad Baruchian  wrote:

> is it because I need to go to localhost:8080/jenkins/ ?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/b5cd2f6e-6cc7-4e27-8f79-0a0a9a95a005%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/A9273B48-20AC-45F5-BBF6-FA977FD47616%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting bundled plugins

[domi]

I don't have a solution for this, but to be honest, I think this is just way to 
complicated and just screams for issues in the long run. We should go for less 
magic and more transparency - I think we should just inform the users about 
this changes and not try to heal the world. We can also inform the users with 
an info message right within Jenkins after he updated to a version where no 
plugins are bundled anymore.
...just my 2cents...
/Domi



 Am 18.08.2015 um 23:03 schrieb Tom Fennelly tom.fenne...@gmail.com:
 
 
 On Tuesday, August 18, 2015 at 10:01:28 PM UTC+1, Tom Fennelly wrote:
 Something I was wondering in order to help with upgrades ... could we use a 
 simple plugin that needs to be installed that captures and records all split 
 plugin info from the instance. This info can then be used on the subsequent 
 install so as to install the exact versions of split plugins. An upgrade 
 would be aborted if that info was not present during startup. Or is there a 
 better way or existing info that can be used?
 
 Prob not practical where there's a lot of Masters? 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/35c09963-21aa-450a-8f47-4e87bb5015d9%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7DB55897-A5EC-4DBC-8F7E-0F26C21FA6F1%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Request hosting a plugin

[domi]

IMO, History has shown that maintenance will more likely not been maintained.
…sure, everyone wants his own plugin, but its not the best for the community 
and the endusers too
my 2 cents...

On 24 Jul 2015, at 08:03, Jochen-A-Fuerbacher m...@jochen-fuerbacher.de wrote:

 Does ist really reduce the risk of bad maintained plugins? I don't think so.
 When merging plugins then the risk is higher that none of the features will
 get maintained any longer. But when the features are implemented in own
 plugins, then maybe some of the plugins aren't maintained, but some others
 are.
 
 
 Åsmund Østvold wrote
 I like the destination of the plugin but
 As the number of jobs grow the number of plugins grow.  Many plugins are
 not maintained for a long period. Keeping similar features in one plugin
 reduce the risk of this happening. This increase the ease of use and
 administration of a Jenkins installation.
 
 IMHO +1 for integration
 
 
 
 
 
 --
 View this message in context: 
 http://jenkins-ci.361315.n4.nabble.com/Request-hosting-a-plugin-tp4761476p4761925.html
 Sent from the Jenkins dev mailing list archive at Nabble.com.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/1437717839669-4761925.post%40n4.nabble.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/57127380-9162-4188-BF93-87D7B3AF8830%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Request hosting

[domi]

I think this should better be integrated with 
https://wiki.jenkins-ci.org/display/JENKINS/testng-plugin
/Domi

On 22 Jul 2015, at 19:08, Carlos Gonzales carledr...@gmail.com wrote:

 Name: summarize-testng-reports
 Github: https://github.com/carledriss/summarize-testng-reports
 Github User: carledriss
 Jenkins-CI.org User: carledriss
 Description: Summarize testng reports when executing several jobs in parallel 
 (each job generates a testng-results.xml)
 Copying as artifact the reports of each job and then generating a Summarize 
 Report html
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/a0217736-fa72-451e-8252-69ca6bf84dfd%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/E5C94ACD-EC5F-4DA8-A127-E560634F30A2%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Request hosting a plugin

[domi]

+1 for an integration/merge


On 22 Jul 2015, at 10:19, Jochen-A-Fuerbacher m...@jochen-fuerbacher.de wrote:

 The FailedJobDeactivator plugin was developed as part of a bachelor thesis.
 It not just detects wrong configured jobs, it also detects well configured
 jobs, which are orphaned.
 Example: A job gets nightly built. After a while, the project is old and
 gets deleted from SCM (SVN, Git, ...). But the Job remains on the Jenkins.
 So building the job fails and nobody takes care of it.
 
 But thank you very much for giving me the info about the JenkinsLint plugin.
 This looks pretty nice.
 
 Jochen
 
 
 
 --
 View this message in context: 
 http://jenkins-ci.361315.n4.nabble.com/Request-hosting-a-plugin-tp4761476p4761496.html
 Sent from the Jenkins dev mailing list archive at Nabble.com.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/1437553157289-4761496.post%40n4.nabble.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/C7DE41F1-57B9-443F-8ECC-8DAD439F9117%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Improvements to the developer docs

[domi]

one thing I never really got my head around was the API of the folders plugin.
Many plugins could really improve if they would integrate properly with the 
folders plugin - but every time I started this, I gave up because it was not 
obvious how to do this.
e.g. how to implement a config hierarchy on different levels:
- global
- folder
- user
- job

Domi


On 17 Jul 2015, at 07:05, Daniel Beck m...@beckweb.net wrote:

 
 On 17.07.2015, at 01:13, John Tatum john.ta...@live.com wrote:
 
 It seems like I had trouble finding good information about entry points.
 
 What do you mean by entry points? The ExtensionPoint/@Extension mechanism? 
 The Plugin class? @Initializer? Stapler request routing? Jelly 
 views/st:include?
 
 It also did not seem like there were any references to the javadoc from the 
 wiki(I always found what I needed using google).
 
 Is this related to using the Script Console? I'm asking because, when writing 
 plugins you should be able to configure your IDE to download and display the 
 Javadoc for Jenkins, so you should need the Javadoc on the web less.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/5048EC38-1E29-403B-88C1-290013F45FCE%40beckweb.net.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/81B8AA9F-15B3-4D75-961F-0DC372CD8CD7%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Idea - download multiple files to workspace via HTTP requests

[domi]

seems like a very specific use case - I would not write a plugin, but use the 
“managed scripts plugin” to share the script within different jobs:
https://wiki.jenkins-ci.org/display/JENKINS/Managed+Script+Plugin
/Domi

On 13 Jul 2015, at 14:07, Vince Webb vince.w...@gmail.com wrote:

 I want a plugin that will read URLs, and filenames from a file in the 
 workspace, request each URL and store the content as the given filename in 
 the workspace.
 
 If these files existed in source control then obviously I would pull them 
 from GIT, SVN or whatever. If they existed in Maven then I would pull them 
 from there but these are files which we want to pull using HTTP or HTTPS from 
 a list of URLs.
 
 I have written a toy town version of this as a bash script:
 /
 while read -r filename url
 
 do
 
 
 curl -o $filename $url
 
 done  url_list.txt
 
 /
 
 It works but I want to replace the script with a plugin for the following 
 reasons:
 We need to repeat it in multiple Jenkins projects
 It needs to have good error reporting
 Needs to do HTTPS as well as HTTP
 
 Has anybody written a plugin similar to this ?
 
 I am a complete newbie when it comes to both Maven and writing Jenkins 
 plugins but I will give it a go if there is nothing else out there.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/c3152928-f9f0-456d-9b2b-a4620785c4ae%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/94324EAB-4D6F-461A-93D0-AE258FEF1631%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: @reviewbybees pull requests

[domi]

I think this is just fine, but I just noticed that its actually not so easy to 
see whether a comment is really coming from a CB developer or not. Most of the 
user ids used on GitHub are not associated to a CB email.
Just because you add :bug: or :bee: to a comment know one knows if this is 
coming from a CB employee. I think many people will actually start to use these 
icons just because they have seen it on any jenkins PR and think it a common 
thing to do in this organisation.
/Domi


On 02 Jul 2015, at 22:32, Stephen Connolly stephen.alan.conno...@gmail.com 
wrote:

 To give some background.
 
 I initially set up the reviewbybees GitHub account *for our closed source 
 repos only*... But people pick up habits and it crept out to OSS plugins 
 *because*:
 
 1. it is easy to use
 2. It makes it easy to find pull requests using a query
 3. Other than the mention `@reviewbybees` it's low impact
 
 Very quickly though, you just get used to appending all your pull requests 
 with the tag.
 
 There are side-effects of the tag and our conducting internal review in the 
 open:
 
 1. All those +1 votes can become intimidating to plugin maintainers. You have 
 a pull request who's direction you are not entirely happy with and a couple 
 of CloudBees people look to be saying: super this should be a no brainer to 
 merge. That is not what our review is about. We want plugin maintainers to 
 retain control of their repositories. If they don't like a change, they 
 should be able and free to say so. Using +1/-1 for our own internal quality 
 process doesn't help... Hence the move to :bee: (it is review by bees after 
 all) and :bug: (I wanted :poo: but that proposal was rejected :-( )
 
 2. We could use the line a lot of other companies use, where we keep our 
 changes hidden on a private fork (so our review could be hidden) and only 
 push up once review is complete. The down side of that is that we would then 
 be building up larger units of change in secret and then landing them on 
 the plugin maintainer. It can be harder for a plugin maintainer to assert the 
 direction they want to follow if they are facing a big piece of work that has 
 just landed without notice at the door of your repo. Thus why we prefer to 
 work in the open and let the plugin maintainer shout stop that's not the 
 direction I want before we even finish our PR. I believe this is best for 
 the community. Additionally the comments in the code review can help the 
 plugin maintainer understand why we have gone for a specific design. Code 
 review in secret deprives the maintainer of that information.
 
 3. Some of our employees will (initially) be strangers to the community. 
 Plugin maintainers should be given an explanation of why a bunch of strangers 
 are littering pull requests with :bee; and :bug: comments. So we have added 
 that a bit adds a comment explaining that we have a process and we are not 
 going to ask for it to be merged until our process is done - but plugin 
 maintainers can do whatever they want. 
 
 4. Some of us have two hats. I am a plugin maintainer for some plugins and 
 also a core committer. It may not be obvious when I am wearing each hat. To 
 help clarify we have the bot provide a formal request for the pull request to 
 be merged. Thus my actions after the review is complete can be more clearly 
 differentiated. The formal request, we also believe, is good to let plugin 
 maintainers know that our review is complete.
 
 In saying that, we don't want to antagonise the community. We want to do self 
 code review and we want plugin maintainers to be free to decide what 
 contributions they accept. We value community feedback, hence this thread.
 
 - Stephen
 
 On Thursday, July 2, 2015, Kanstantsin Shautsou kanstantsin@gmail.com 
 wrote:
 Was this discussed/allowed on some Jenkins meeting? 
 Can such actions be documented/allowed somewhere in Jenkins project 
 documentation?
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/69b68969-0436-40bd-a3cb-0e30424f6d12%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 Sent from my phone
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxanAQzOaSOPy68C3wB44xyiW4bEd5j5gdbXLXnfB7-iA%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group

Re: Cloning a Job

[domi]

The “create job advanced plugin” does something like this - you can check its 
sources
https://wiki.jenkins-ci.org/display/JENKINS/Create+Job+Advanced+Plugin
/Domi


On 24 Jun 2015, at 16:28, Cletus D'Souza cletusdso...@hotmail.com wrote:

 Hello All,
 
 Is it possible to (by configuration or programmatically) prevent or reset 
 certain plugin parameters when a Job is cloned?  Does someone have an example 
 that could be shared with me?
 
 Thanks!
 Cletus
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web 
 visithttps://groups.google.com/d/msgid/jenkinsci-dev/SNT153-W202510FDD599332A6F5C8BC1AF0%40phx.gbl.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/0E7DA5F6-4E1D-4A1D-93A7-2F56CC401303%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Duplicated plugin titles in Update Centre

[domi]

I fully agree with Chris, we should remove the suffix, as the plugin names are 
always shown in a context where its clear its nothing else.
/Domi


On 18 Jun 2015, at 16:26, Christopher Orr ch...@orr.me.uk wrote:

 Yeah, I don't have too strong an opinion either way on removing plugin.
 
 I agree that when I'm on the Jenkins wiki, it's clear that everything relates 
 to Jenkins.  But similarly, when I'm inside my Jenkins instance, and click on 
 Manage Plugins and end up in the Plugin Manager, I am fairly sure that it 
 relates to Jenkins plugins and nothing else — so in this case it's not really 
 necessary to suffix everything with plugin :)
 
 Other software that has extensions or plugins tend to do the same, e.g.:
  https://chrome.google.com/webstore/category/extensions
  https://addons.mozilla.org/en-US/firefox/extensions/
  https://wordpress.org/plugins/browse/popular/
 
 
 Also, note that these plugin display names do not exist in isolation — the 
 plugin description text is always displayed underneath each name (many of 
 which include the text this plugin...), e.g. for git it would say:
 
  Git
This plugin allows use of Git as a build SCM. [...]
 
 
 But again, my proposals are just proposals :)
 
 Regards,
 Chris
 
 
 On 18/06/15 07:09, Mirko Friedenhagen wrote:
 Hello Christopher,
 
 while I am a big fan of cleanups and appreciate the work you did here I
 do not like removing plugin.
 When I look at the page name it should be obvious what kind of kind of
 page I have in front of me. I am in the Jenkins Wiki, so Jenkins is not
 needed. But more generic words like git or cloudbees could describe
 anything, from how to use git while developing or what Cloudbees, Docker
 etc is.
 
 Maybe abstract plugins like git-client could be named consistently as
 base-plugin to indicate that they are not usable by themselves?
 
 Regards
 Mirko
 --
 Sent from my mobile
 
 Am 17.06.2015 17:55 schrieb Kanstantsin Shautsou
 kanstantsin@gmail.com mailto:kanstantsin@gmail.com:
 
 
 
Sent from my iPad
 
  On Jun 17, 2015, at 5:16 PM, Christopher Orr ch...@orr.me.uk
mailto:ch...@orr.me.uk wrote:
 
  On 17/06/15 09:23, Daniel Beck wrote:
 
  On 17.06.2015, at 00:47, Christopher Orr ch...@orr.me.uk
mailto:ch...@orr.me.uk wrote:
 
  I made a quick report of what the current and new names would
be (where they differ from one another), and a list of proposed
clean-up rules (e.g. remove Jenkins from every name, and remove
plugin from the end):
  https://gist.github.com/orrc/7a6e2b0605306f6d215e
 
  'Jenkins' prefix already gets removed in the Jenkins UI. And the
others can be done some other time, we already had these same issues
with wiki page names.
 
  Well, fixing these plugins requires updating the name tag and
making a release.
 
  After removing the Jenkins  prefix, there are still at least 69
that have Jenkins or Hudson in the name — it seems unlikely that
somebody is likely to fix them (in a consistent way) and release them.
 
 
  Also, this will finally resolve the issue that installed plugins
have a different name than available plugins, right?
 
  Since there is already basic stripping of the Jenkins  prefix
inside of Jenkins itself, how about we extend that with the few
extra clean-up rules I proposed?
 
  As you say, fixing the original issue by making Update Centre use
name as the plugin name would mean then both the Available and
Installed tabs will display names consistently.
 
  Adding the extra clean-ups would remove more redundancy,
improving names like Hudson Testability Explorer Plug-in, Maven
Metadata Plugin for Jenkins CI server, and Computer-queue-plugin.
 
  I updated the Gist with the cleaned-up names; to me, it appears
to work well in virtually every case:
  https://gist.github.com/orrc/7a6e2b0605306f6d215e
 
  What do you think?
 
  Regards,
  Chris
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/5582D503.6050602%40orr.me.uk.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/63EB8F79-52D7-4959-8C35-AA47E9332442%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] Semi-automated detection of unmaintained plugins

[domi]

+1 for Stephens suggestion.
in the long run this would hopefully even allow to finally remove deprecated 
stuff…
/Domi

On 09 Jun 2015, at 11:28, Stephen Connolly stephen.alan.conno...@gmail.com 
wrote:

 On 9 June 2015 at 09:37, Vincent Latombe vincent.lato...@gmail.com wrote:
 You might get compilation errors because of plugin extracted from core when 
 applying such a process.
 
 Some plugins are really simple and may not need evolution because they just 
 work as is.
 
 But they can all benefit from a more recent core (to fix issues with jelly 
 pages, etc)
  
 How would the attic be represented ? Should it be exposed to users in update 
 center?
 
 
 
 
 
 Vincent
 
 2015-06-09 10:24 GMT+02:00 Stephen Connolly stephen.alan.conno...@gmail.com:
 In pseudocode:
 
 FOR repo IN (SELECT repo FROM github WHERE last_commit  now - 3 months)
   CREATE PULL REQUEST update base jenkins version to LTS-1
 END
 WAIT 1 month
 
 I suggest that any repo that has not commented / merged / rejected those pull 
 requests is a dead plugin
 
 I suggest that we would subsequently start a campaign to either find 
 maintainers or move those into an attic/deprecated status.
 
 We can lather rinse and repeat the above process every couple of months.
 
 With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.
 
 I think an attic status is a better name for such a cull. It's different 
 from deprecated, it's more saying nobody was playing with these toys, so 
 we'll put them in the attic until somebody decides to play with them again.
 
 Thoughts?
 
 -Stephen
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAH-zGCis6qGaKXzS5X6t-_2FZH%3D1LSjoKDK40tQHJEYUJdHfLQ%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwyQvoDnYYQeSjqj7gnrmdtqfYQy3CsJLDp5DWgS0ZiKA%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CC6191C9-EC2C-4E39-B425-150638A026D7%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Hosting Request: Violations Reboot Plugin

[domi]

-1 
I think its very strange to complain about the maintenance state of a plugin 
and therefore fork the same and release it with the reason to mark it as 
unstable…
this will simple just lead to an other unmaintained plugin with no additional 
value for any user.
my 2c
Domi


On 01 Jun 2015, at 00:30, Tomas Bjerre tomas.bjerr...@gmail.com wrote:

 Plugin Name: Violations Reboot
 My GitHub username: tomasbjerre
 Existing repo: https://github.com/tomasbjerre/violations-reboot-plugin
 Doc: https://github.com/tomasbjerre/violations-reboot-plugin
 
 This is very similar to Violations 
 (https://github.com/jenkinsci/violations-plugin). The Violations plugin has 
 been poorly maintained lately. Alot of features, and bug fixes, in PR:s are 
 left unmerged. Which is very sad since its a very nice plugin!
 
 What I have done here is:
 * Fork Violations
 * Added LICENSE, README and a coding standard (for Eclipse)
 * Reformatted the code according to the coding standard (will make it much 
 easier to merge PR:s in the future)
 
 I think the major reason why PR:s are not merged in Violations is because of 
 the heavy testing job that should be carried out before a release. I, 
 therefore, suggest releasing this (much more unstable) reboot so that 
 existing users can continue using the stable Violations release while Reboot 
 becomes more stable. I'd like to implement better automated testing and 
 create releases after more or less every new feature.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/ba38fabe-ff19-4828-a737-d2320ea5681f%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/95F76D76-4F8C-4F86-AE5D-9A4DD1614BDB%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [UX] Jenkins controls compaction proposal

[domi]

I also don’t like it - the left navigation is a really cluttered menu which I 
think needs some more thinking too
/Domi


On 28 May 2015, at 10:40, Marius Gedminas mar...@gedmin.as wrote:

 On Thu, May 28, 2015 at 10:03:03AM +0200, oliver gondža wrote:
 One of the things that bothers me about Jenkins layout is the way some
 buttons are placed on the page rather randomly. Namely: Disable Project,
 Keep this build forever, Mark this node temporarily offline, Launch
 slave agent and friends. Things can get even worse when different plugins
 contribute floatingBoxes with graphs making the buttons on the right edge of
 the screen visually disappear.
 
 What I propose[1] is moving all these icons to sidepannel, where controls
 ware always supposed to be.
 
 WDYT?
 
 Not a fan of the idea.  The left sidebar is rather cluttered.  Also,
 clicking on a link is not as enjoyable as clicking on a large button.
 
 [1] https://github.com/jenkinsci/jenkins/pull/1703
 
 Marius Gedminas
 -- 
 We did it for smallpox, we'll also win over on ISO 8859-1 ... ;-)
   -- Markus Kuhn after eradicating one more ISO 8859-1 file from his disk
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web 
 visithttps://groups.google.com/d/msgid/jenkinsci-dev/20150528084041.GA3880%40platonas.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/83B15BE0-6E9E-4CD4-8834-04FFEB15079A%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Propagate JAAS Subject from Core Jenkins to Custom step plugin

[domi]

This is actually a subject a couple of user wanted to come up with, but at the 
end I think all discarded the idea…
If still wanna do this, then you also have to think about scheduled jobs, these 
are triggered by no user interaction, which JAAS subject would you use in these 
cases?
/Domi


On 27 May 2015, at 16:48, Guillaume Delory gdel...@gmail.com wrote:

 Actually after thinking a bit more about that. I guess that the user is 
 authenticated only when he start the job and add it to the queue. Then the 
 executor wil take care of it but user has nothing to do with it. So it makes 
 sense there is no Subject associated to it.
 
 If I'm right, the only option would be to intercept the build creation and 
 somehow store the Subject somewhere if it's available, to make it available 
 for the actual build one by the Jenkins user. I have no idea if it's possible.
 
 Any thoughts?
 
 Thank you :)
 
 Le mardi 26 mai 2015 14:24:19 UTC+2, Guillaume Delory a écrit :
 Hi everyone,
 
 I'm running Jenkins in WebSphere 8.5 to manage authentication. It works fine 
 and I can get the JAAS Subject in the Script Console by doing:
 println com.ibm.websphere.security.auth.WSSubject.getCallerSubject()
 
 I also wrote a plugin that adds a simple custom step (extending the Builder 
 class). I would like to use this plugin to contact some application also 
 running in WAS. To do this I need to get the caller Subject as I did in the 
 console. However, the code above in the perform method returns null. I guess 
 Jenkins runs the step in a different thread without pushing the JAAS Subject.
 
 Is there any way (by configuration or programmatically) to force Jenkins to 
 push the Subject to the build step so I can use it? Or maybe a different way 
 to get the caller Subject from the plugin?
 
 Thank you very much for your help.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/fb1f9ab7-f118-42e6-9314-35f9aa509c9b%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/A9328AD6-B3C4-47B8-8CFC-A91E65A4FC79%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin hosting request

[domi]

The I guess its about the same as:
https://wiki.jenkins-ci.org/display/JENKINS/Envfile+Plugin
/Domi

On 25 May 2015, at 21:07, Daniel Olausson d.olaus...@gmail.com wrote:

 Hi,
 
 GitHub:
 https://github.com/rednuht/retainenvironment
 
 Description can be found at:
 https://github.com/rednuht/retainenvironment/blob/master/README.md
 
 Shares some similarities with the EnvInject plugin but my plugin doesn't 
 require the user to use any additional build steps.
 
 Br,
 Daniel Olausson
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/1ec4cf30-7ff8-48b4-af3c-c8e703c6e778%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/763677F7-B8CD-4CDA-B724-D908834F28A2%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Help logging into http://scriptlerweb.appspot.com/

[domi]

Hi Scott,

I’m the creator of that app. It was the first implementation of a hosted 
catalog for scriptler, since then we created an other catalog hosted on GitHub: 
https://github.com/jenkinsci/jenkins-scripts/tree/master/scriptler
The one on GitHub is the one which you should use for new scripts (please make 
sure to read the README on GH).
Actually I have not looked at scritlerweb for about a year and I’m quite 
surprised it still has activity :) 

regards Domi



On 19 May 2015, at 19:31, Scott Hebert sco...@gmail.com wrote:

 Hi,
 
 Does anyone know who runs and maintains http://scriptlerweb.appspot.com/?
 
 I have a groovy script that needs updating and it is hosted there. For some 
 reason, I am unable to login using the Google OpenID facility. I can create a 
 new provider, but I am unable to edit a script that was created by another 
 provider.
 
 Barring that, I guess I can turn to hosting the script here: 
 https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Script+Console
 
 Thanks for your help
 
 Scott
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CALtL2uFeJoZy%3DX%2BNDRVzugVF8F3nj_%2B8PNPxbM5s4uh5rNrM5g%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/68901794-E82C-4661-9CC5-F0127B00A6AE%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Request hosting for Serena Deployment Automation Deploy plugin

[domi]

I think this is irritating for the users…
Also you should include “serena” in the name of the new plugin, as SDA is not a 
well known acronym and users not familiar with serena should know by the name 
whether the plugin is interesting for them or not.
/Domi

On 18 May 2015, at 21:33, PoisoN PoisoN poiso...@gmail.com wrote:

 No, the plugin was rebranded to work with rebranded Serena product (which is 
 now SDA - Serena Deploymen Automation). Also to avoid upgrade issues it 
 should be separate plugin with new plugin id.
 I work for Serena and I'm maintainer of both plugins. So, both plugins are 
 official but old one is deprecated and will not be supported by Serena 
 anymore. Once new plugin will be published old one can be deleted.
 
 
 понедельник, 18 мая 2015 г., 21:04:29 UTC+3 пользователь Daniel Beck написал:
 
 On 18.05.2015, at 10:49, PoisoN PoisoN pois...@gmail.com wrote: 
 
  New plugin cannot be merged into old one 
 
 Isn't it the exact same code with a few classes and fields renamed and the 
 package name changed? The POM is basically identical. 
 
 What's the difficulty in just declaring it version 2.0 or something, or e.g. 
 removing some of the branding and calling it 'unofficial' if the vendor 
 doesn't want to support it anymore? 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/a6caf8b6-d6f0-40d4-88ec-996a37868d96%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/EE3AA4E1-DAED-47DF-BAE2-E6FA94B9A992%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: wiki page for Chat Room jenkins plugin

[domi]

…and please make more clear what this plugin is all about, think about your 
(hopefully new) users - do they understand what they can use the plugin for? 
Personally I would not have a clue why I should choose this plugin instead of 
all the other plugins integrating a chat systems? Also screenshots help a lot 
more then anything else!
like:
https://wiki.jenkins-ci.org/display/JENKINS/Jabber+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/IRC+Plugin

so what is the difference? (did we really need an other chat plugin?)

and if it is different, then it might also integrate with?:
https://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Plugin

/Domi



On 29 Apr 2015, at 07:47, domi d...@fortysix.ch wrote:

 You need to update the url in the plugins pom.xml and do a new release.
 /Domi
 
 
 On 29 Apr 2015, at 07:37, anitha vivedhan anitha24vived...@gmail.com wrote:
 
 Respected,
 
 I created a wiki page for Chat Room jenkins plugin.But that wiki page not 
 listed in jenkins Update center .can You please suggest the solution.
 
 ChatRoom:{buildDate:Apr 25, 
 2015,dependencies:[],developers:[{developerId:anitha,name:anitha}],excerpt:A
  Build status publisher that notifies on Chat 
 Room,gav:org.jvnet.hudson.plugins:ChatRoom:1.0,name:ChatRoom,releaseTimestamp:2015-04-25T21:58:58.00Z,requiredCore:1.509.3,scm:github.com,sha1:1TTT/ZmU2SckjdTRkON+drWO0ts=,title:Jenkins
  Chat Room 
 Plugin,url:http://updates.jenkins-ci.org/download/plugins/ChatRoom/1.0/ChatRoom.hpi,version:1.0}
 
 https://wiki.jenkins-ci.org/display/JENKINS/ChatRoom+Plugin
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAD9nYjt_GTQQWx9mxi80v5sORMGYds4Bvs5s8FoLEtijF8bq-A%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/BC57B361-E3B2-4AE3-94C3-B68D9B919B55%40fortysix.ch.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2CC82E31-DC73-40E8-8778-6F5C0C566619%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Posting closed source plugin on Jenkins site

[domi]

how do we deal with closed source plugins which only have the documentation on 
the jenkins wiki?
e.g.: https://wiki.jenkins-ci.org/display/JENKINS/CxSuite+Jenkins+Plugin

Domi



On 21 Apr 2015, at 12:10, Stephen Connolly stephen.alan.conno...@gmail.com 
wrote:

 If you come across a plugin on the OSS update center that is in fact closed 
 source, please alert the community so that either the plugin can be removed 
 or the plugin author can be nagged to open source it.
 
 And FTR CloudBees while has (quite a lot of) closed source plugins, but we 
 only host closed source ones on our own update center, in accordance with the 
 wishes of the Jenkins community.
 
 Any plugin that CloudBees publishes on the community's update center is open 
 source... (part of our internal sign-off process before releasing a plugin to 
 the OSS update center is to ensure that all source code is open source. For 
 example the now defunct cloudbees-deployer-plugin which was to deploy 
 applications to our old RUN@cloud product. That plugin started off as open 
 source, then some changes required that it depend on a library we had that 
 was closed source, so we had to fork it in-house for 2 years or so, then 
 finally we got the full chain of dependencies open source again and re-open 
 sourced the plugin... of course 6 months after that the business decided to 
 shut down RUN@cloud... so we subsequently refactored the plugin to spin out 
 the (to our thinking - quite useful) deployment framework as separate from 
 the RUN@cloud specific deployment engine)
 
 On 21 April 2015 at 10:49, Christopher Orr ch...@orr.me.uk wrote:
 No, closed source plugins shouldn't be available in the update centre.
 
 You can install your closed source plugins manually, or host your own update 
 centre, e.g. see this previous discussion:
 https://groups.google.com/forum/#!topic/jenkinsci-users/NArW8EeRgMs/discussion
 
 Regards,
 Chris
 
 
 On 21/04/15 11:09, Sergey Kadaner wrote:
 Hi,
 is there an option to post closed source plugin on
 https://wiki.jenkins-ci.org/display/JENKINS/Plugins or at least make it
 available in automatic update notifications inside Jenkins?
 
 I cannot find any option to do so.
 
 Thanks in advance,
 Sergey
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/55361D2D.8050507%40orr.me.uk.
 
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzjyJYqKqujNu3rRPfSW9EJuJD1k4jzt0MZSEy-fFg8sw%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/36308A4A-E206-4232-B478-C860FB6A99A5%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Request hosting for amazon-ecs-plugin

[domi]

something like: “for now its better to release it that way” - we hear this a 
lot, but experience clearly shows: in most of the cases plugins will never be 
merged again after they are separated
my 2cent
Domi


On 21 Apr 2015, at 14:19, Nguyen Anh Phu phun...@gmail.com wrote:

 Hi Ullrich,
 A name of amazon-container-service would make it looks clearer?
 To combine them into one is a good idea which I'll discuss with Amazon EC2's 
 maintainers. Anyway I think for now other people can already have benefit of 
 using this plugin for their jenkins environment.
 
 Best regards,
 Phu
 
 On Tue, Apr 21, 2015 at 5:33 PM, Ullrich Hafner ullrich.haf...@gmail.com 
 wrote:
 I think the name should clearly indicate what is different from the existing 
 one. 
 
 On the other hand, couldn’t these two approaches combined into *one* plug-in?
 
 Am 21.04.2015 um 05:45 schrieb Nguyen Anh Phu phun...@gmail.com:
 
 Hi,
 Any feedback for this? I'd like to know if it's OK or not or should I 
 improve it to provide better benefit to the community.
 
 Thanks,
 
 On Sat, Apr 18, 2015 at 8:22 AM, Nguyen Anh Phu phun...@gmail.com wrote:
 Hi, so doesn't it sound different? :)
 
 On Thu, Apr 16, 2015 at 7:31 PM, Nguyen Anh Phu phun...@gmail.com wrote:
 I haven't tried the EC2 plugin you mentioned but I think it uses EC2 
 instances as slaves directly, whilst my plugin uses docker containers inside 
 EC2 instances as slaves (via ECS' API). Theoretically using ECS gives us 
 more control on resource utilization, e.g. in simplest case we can, when 
 launching slave, check which instance has enough resource to launch. We can 
 also implement more complex scheduler than that.
 
 On Thu, Apr 16, 2015 at 4:34 PM, Ullrich Hafner ullrich.haf...@gmail.com 
 wrote:
 How does it differ from 
 https://wiki.jenkins-ci.org/display/JENKINS/Amazon+EC2+Plugin?
 
 Am 16.04.2015 um 05:08 schrieb Phu Nguyen Anh phun...@gmail.com:
 
 Hi,
 I've made a plugin for dynamically provision a slave on Amazon ECS, could I 
 host it on jenkins?
 My information:
 - Github plugin name: amazon-ecs-plugin
 - Personal Github ID: phuna
 - Github repository: https://github.com/phuna/amazon-ecs-plugin
 
 The plugin is still simple but works (per my test), best if jenkins master 
 is in the same VPC with ECS' container instances. Any suggestions are very 
 much appreciate.
 
 Best regards,
 Phu
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email tojenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/612ddd18-8947-4334-9e17-39b600cd4ce1%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups Jenkins Developers group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/jenkinsci-dev/F3kP3q2uriQ/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/ECAEBC9E-2CAD-48FA-A1BC-CBE75862BDD2%40gmail.com.
 
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 -- 
 Nguyen Anh Phu
 
 
 
 -- 
 Nguyen Anh Phu
 
 
 
 -- 
 Nguyen Anh Phu
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAAkRrg4L1WDrae_Hqb_aCiHgBw2uNxtCUyFwVJCcKNO8vJfeOg%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Jenkins Developers group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/jenkinsci-dev/F3kP3q2uriQ/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/A4A4D19A-8BB8-4127-8D3E-0C04CB547C90%40gmail.com.
 
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 -- 
 Nguyen Anh Phu
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAAkRrg6o%2B6h5%3DUTK05cBvP5d%3DA%3DLD2%2BBD6JupaMX-YUoKi2%3DTg%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received

Re: Posting closed source plugin on Jenkins site

[domi]

added it to the next meeting…
https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda


On 21 Apr 2015, at 14:57, Stephen Connolly stephen.alan.conno...@gmail.com 
wrote:

 I don't know the answer to that. I suggest adding it to the next governance 
 meeting agenda.
 
 PERSONALLY:
 
 My understanding is that you should only be using the OSS infrastructure 
 (wiki, jira, maven repo, update center, etc) if your plugin is OSS. 
 
 While could accept a wiki page entry as an advertisement for a closed source 
 plugin, I would prefer a simple clear policy of: only open source plugins can 
 use the community infrastructure. 
 
 If we want to host a closed source plugins wiki page to maintain links to 
 non-OSS plugins then I think that would be a reasonable compromise.
 
 On 21 April 2015 at 13:39, domi d...@fortysix.ch wrote:
 how do we deal with closed source plugins which only have the documentation 
 on the jenkins wiki?
 e.g.: https://wiki.jenkins-ci.org/display/JENKINS/CxSuite+Jenkins+Plugin
 
 Domi
 
 
 
 On 21 Apr 2015, at 12:10, Stephen Connolly stephen.alan.conno...@gmail.com 
 wrote:
 
 If you come across a plugin on the OSS update center that is in fact closed 
 source, please alert the community so that either the plugin can be removed 
 or the plugin author can be nagged to open source it.
 
 And FTR CloudBees while has (quite a lot of) closed source plugins, but we 
 only host closed source ones on our own update center, in accordance with 
 the wishes of the Jenkins community.
 
 Any plugin that CloudBees publishes on the community's update center is open 
 source... (part of our internal sign-off process before releasing a plugin 
 to the OSS update center is to ensure that all source code is open source. 
 For example the now defunct cloudbees-deployer-plugin which was to deploy 
 applications to our old RUN@cloud product. That plugin started off as open 
 source, then some changes required that it depend on a library we had that 
 was closed source, so we had to fork it in-house for 2 years or so, then 
 finally we got the full chain of dependencies open source again and re-open 
 sourced the plugin... of course 6 months after that the business decided to 
 shut down RUN@cloud... so we subsequently refactored the plugin to spin out 
 the (to our thinking - quite useful) deployment framework as separate from 
 the RUN@cloud specific deployment engine)
 
 On 21 April 2015 at 10:49, Christopher Orr ch...@orr.me.uk wrote:
 No, closed source plugins shouldn't be available in the update centre.
 
 You can install your closed source plugins manually, or host your own update 
 centre, e.g. see this previous discussion:
 https://groups.google.com/forum/#!topic/jenkinsci-users/NArW8EeRgMs/discussion
 
 Regards,
 Chris
 
 
 On 21/04/15 11:09, Sergey Kadaner wrote:
 Hi,
 is there an option to post closed source plugin on
 https://wiki.jenkins-ci.org/display/JENKINS/Plugins or at least make it
 available in automatic update notifications inside Jenkins?
 
 I cannot find any option to do so.
 
 Thanks in advance,
 Sergey
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/55361D2D.8050507%40orr.me.uk.
 
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzjyJYqKqujNu3rRPfSW9EJuJD1k4jzt0MZSEy-fFg8sw%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/36308A4A-E206-4232-B478-C860FB6A99A5%40fortysix.ch.
 
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwMO0pi_kZPRSBV0dTZH7e2RnK%3Dtx0y8pSBf9eQumzH9Q%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers

Re: Hosting Request BehaveHTMLResults plugin

[domi]

What makes this plugin different from 
https://wiki.jenkins-ci.org/display/JENKINS/Cucumber+Test+Result+Plugin ?
/Domi


On 15 Apr 2015, at 09:58, Chaitanya Channella channel...@gmail.com wrote:

 Bump
 
 On Wednesday, February 25, 2015 at 12:51:21 PM UTC+1, Chaitanya Channella 
 wrote:
 Hi,
 
 I have created a plugin to display Behave Test results, details below
 
 Plugin name: Behave HTML Results
 Github id:ChaitanyaChannella
 Github url:https://github.com/ChaitanyaChannella/BehaveResultsJenkinsPlugin
 
 Thanks,
 Chaitanya
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/cb72640f-0a4c-4453-9954-78f4fda8523a%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/3CE058C0-C869-44A9-8574-7F8FFF4D2772%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin hosting request: AdvancedInstaller Plugin

[domi]

I agree with Daniel and Oleg, I also think it is misleading - maybe not to he 
ones how know this tool - but to everyone else and I would say thats about 90%
..my 2cents
/Domi


On 25 Mar 2015, at 14:42, advinst caphyon advinst.caph...@gmail.com wrote:

 Hi,
 
 Advanced Installer is a recognized name in the packaging solutions market. 
 The id will not be misleading to our users which requested this plugin.
 Also we would like to use the same naming scheme as similar products (wix, 
 InstallShield).
 So if it is not inconvenient we would like to keep this artifactId. 
 
 Thanks
 
 On Wednesday, March 25, 2015 at 3:25:41 PM UTC+2, Oleg Nenashev wrote:
 Do you consider changing the artifactId?
 The current one is quite confusing. I think that Daniel's proposal could be a 
 right choice for your plugin
 
 2015-03-25 16:01 GMT+03:00 advinst caphyon advinst...@gmail.com:
 Hi,
 
 Here is the plugin repo:
 https://github.com/advinst/advinst-jenkins-plugin
 
 Any update o this?
 
 Thanks.
 
 
 On Tuesday, March 24, 2015 at 8:48:57 AM UTC+2, Oleg Nenashev wrote:
 As I see, the plugin does not exist in your repo.
 Could you clarify the purpose of the plugin (e.g. describe the use-case in 
 details)? There're many plugins, which may address your use-case. As example, 
 Custom Tools allows to setup an environment for builds.
 
 вторник, 24 марта 2015 г., 9:27:51 UTC+3 пользователь advinst caphyon написал:
 
 
 
 
 Hello
 
 I would like to request to host a Jenkins CI plugin for building setups using 
 Advanced Installer
 
 Characteristics of plugin:
 - Plugin will add a build step allowing  setup builds using Advanced 
 Installer.
 
 
 INFORMATION REQUESTED
 
 GitHub plugin name : advancedinstaller-plugin
 
 Personal GitHub ID : advinst
 
 
 Thanks!
 
 -- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Jenkins Developers group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/jenkinsci-dev/e93hBJE6vDM/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/3755ca11-a32d-47d3-bfdc-34535065b275%40googlegroups.com.
 
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/cf627c04-2223-4c30-a645-5abbdd40a67b%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/24FB7954-4373-4ABA-9802-2A26603BB43C%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Hosting for Stash Pull Request Builder

[domi]

Done: https://github.com/jenkinsci/stash-pullrequest-builder-plugin
A component on the issue tracker is created too..
Please also make sure this is not valid information anymore: 
https://github.com/nemccarthy/stash-pullrequest-builder-plugin/blob/dbff56b/src/main/java/stashpullrequestbuilder/stashpullrequestbuilder/stash/ApiTest.java#L9

btw. on the wiki, you don’t have to mention the minimal Jenkins Version and the 
dependency to other plugins - this will be generated out of the pom.xml and 
placed in the summery on top of the page as sonn as you released the first 
version. Tshi way this information will be kept in sync.
/Domi


On 23 Mar 2015, at 09:33, Nathan McC nathan.e@gmail.com wrote:

 Thanks. Updated the wiki with how to. 
 
 Would it be possible to get this into the jenkins ci on github to make this 
 official.  
 
 I'm assuming once I have a repo and permissions to do a relase the rest of 
 the info on the wiki page will populate. 
 
 On Monday, March 23, 2015 at 6:04:23 PM UTC+11, Dominik Bartholdi wrote:
 Thats about the info I would expect on the plugins wiki page…
 Domi
 
 On 23 Mar 2015, at 01:24, Nathan McC nathan...@gmail.com wrote:
 
 Add a blog post with some screenshots; http://blog.nemccarthy.me/?p=387 
 
 On Sunday, March 22, 2015 at 9:08:59 PM UTC+11, Nathan McC wrote:
 Hey guys,
 
 I've made a new Pull Request builder plugin for Stash, this plugin is 
 inspired by the GitHub and BitBucket PR builder plugins. 
 
 plugin name: stash-pullrequest-builder-plugin 
 github username: nemccarthy
 github repo: https://github.com/nemccarthy/stash-pullrequest-builder-plugin 
 
 Wiki page; 
 https://wiki.jenkins-ci.org/display/JENKINS/Stash+pullrequest+builder+plugin 
 
 It would be awesome if I could get this one hosted.
 
 Cheers,
 Nathan
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/fb3a0eed-4bb7-4c07-a674-ace54f0c0ac7%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/bc32495a-e3a0-4b7e-9689-ffa8377a6f7a%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/A8765EAF-355F-4FEB-BECD-707C28DC1EF8%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Hosting for Stash Pull Request Builder

[domi]

Thats about the info I would expect on the plugins wiki page…
Domi

On 23 Mar 2015, at 01:24, Nathan McC nathan.e@gmail.com wrote:

 Add a blog post with some screenshots; http://blog.nemccarthy.me/?p=387 
 
 On Sunday, March 22, 2015 at 9:08:59 PM UTC+11, Nathan McC wrote:
 Hey guys,
 
 I've made a new Pull Request builder plugin for Stash, this plugin is 
 inspired by the GitHub and BitBucket PR builder plugins. 
 
 plugin name: stash-pullrequest-builder-plugin 
 github username: nemccarthy
 github repo: https://github.com/nemccarthy/stash-pullrequest-builder-plugin 
 
 Wiki page; 
 https://wiki.jenkins-ci.org/display/JENKINS/Stash+pullrequest+builder+plugin 
 
 It would be awesome if I could get this one hosted.
 
 Cheers,
 Nathan
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/fb3a0eed-4bb7-4c07-a674-ace54f0c0ac7%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/002A648B-06A8-4FD4-87FA-00FE39A09396%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: New plugin - New Relic Deployment Notifier Plugin

[domi]

Nice!
I was thinking about implementing this one my self…
Things I would like to see:
- integration with the credentials plugin (no need to repeat the API key 
allover)
- support for notifications of multiple applications in on build

/Domi


On 02 Mar 2015, at 21:02, Mads Mohr Christensen hr.m...@gmail.com wrote:

 Hi guys,
 
 I have written a new plugin for submitting deployment notifications to New 
 Relic:
 
 https://github.com/hrmohr/newrelic-deployment-notifier-plugin
 
 I would appreciate any comments or suggestions for me to improve the plugin 
 before it is released.
 
 (The wiki page is not yet created but there is some basic documentation in 
 the README file)
 
 Thanks!
 
 Mads.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/3421E691-0DB2-4CC8-87E4-F1EDFA997899%40gmail.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/43E13F5A-BEB9-4CA2-BEFC-AAD6E494D543%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Postbuild - Programatically filter all non-svn-triggered builds

[domi]

What you are looking for is the ‘Cause' of a build, like here:
https://github.com/jenkinsci/buildtriggerbadge-plugin/blob/master/src/main/java/org/jenkinsci/plugins/buildtriggerbadge/RunListenerImpl.java#L34
The one you are looking for is most probably of type SCMTriggerCause (not sure 
if Svn Plugin has a more specific implementation of it)
But be aware, that every build can have multiple Causes (e.g. SCMTriggerCause 
and UserIdCause), so you have to check the whole list.
A couple of possible Causes are listed here:
https://github.com/jenkinsci/buildtriggerbadge-plugin/blob/master/src/main/java/org/jenkinsci/plugins/buildtriggerbadge/IconFinder.java#L67-L81

/Domi


On 02 Mar 2015, at 18:27, Peter Rader p.ra...@gmx.net wrote:

 Hi,
  
 i build a internal plugin (extends hudson.tasks.Builder) that parses 
 svn-commit-comments.
 How can i programatically findout if the build was triggered by a subversion 
 change?
  
 By instinct i try to inspect the hudson.Launcher, unfortunatelly i found no 
 indication for a clean classification of how the build is launched. According 
 to the package this class looks more like a reference to the environment of 
 jenkins himself that i (respectfully) never expected as an direct argument of 
 the method perform.
  
 Can anyone guide me to the correct way of find-out how the build is triggered?
  
 Best regards
 Grim
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/trinity-9dff2547-0235-4aba-b804-f3437d74a560-1425317221487%403capp-gmx-bs20.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/3AC04DBB-FA54-4138-8669-D5A88326505A%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: New plug-in: Uno Choice Plug-in for dynamic parameters

[domi]

To be honest, the “Uno” in the name stopped my from looking closer into it - 
because the name was just confusing…
…my 2cents
Domi

On 19 Feb 2015, at 08:05, Daniel Beck m...@beckweb.net wrote:

 
 On 18.02.2015, at 22:01, Jesse Glick jgl...@cloudbees.com wrote:
 
 I would pick a plugin named “Dynamic Parameter”
 and skip right over “Uno Choice”.
 
 There is already 'Dynamic Extended Choice' and 'Dynamic Parameter'. At least 
 with the 'Uno' it has a less generic name and you're not going to confuse it 
 with another plugin all the time.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/81CE5C0F-3BAE-4C51-948F-70FA87DDA9A6%40beckweb.net.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/10A2CFD1-D4BE-4E7A-9D47-D5F3BEC9FB35%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Request Hosting

[domi]

There is even one more to the list: 
https://wiki.jenkins-ci.org/display/JENKINS/Oki+Docki+Plugin
regards Domi

On 08 Jan 2015, at 10:17, James Nord te...@teilo.net wrote:

 Hi David,
 
 How is this different from the other docker plugins that already exist and 
 would seem to achieve the same end goal?
 
 https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin
 https://wiki.jenkins-ci.org/display/JENKINS/Docker+build+step+plugin
 https://wiki.jenkins-ci.org/display/JENKINS/Docker+build+publish+Plugin
 
 it would be better for the community to only have a single well maintained 
 plugin for a specific task - so what does yours do differently - could you 
 not improve the existing plugins if they didn't do something that you need?
 
 alternatively to the maintainers of those other plugins - does this do enough 
 to superceed all of these plugins that it is worth having a single plugin and 
 would you be willing to contribute to this?
 
 Regards,
 
 /James
 
 On 08/01/2015 04:45, David Capwell wrote:
 jenkins-ci.org name is the same: dcapwell
 
 On Wednesday, January 7, 2015 8:42:53 PM UTC-8, David Capwell wrote:
 Hi,
 
 I created a plugin that lets you run your build steps inside a docker 
 container; I would like to get listed.
 
 Plugin name: CIBorium
 Github ID: dcapwell
 Github Repo: https://github.com/pivotalsoftware/CIBorium
 
 Thanks!
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/4d0bfa5b-8779-40a9-bc8a-c36bc69680da%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/54AE4B37.5090003%40teilo.net.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/64238FA6-CB54-4426-8EAA-4AA36D075870%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

docu for workflow plugin

[domi]

Hi,

I just had a look at the documentation plugin, or more I tried to, there is no 
documentation on confluence for any of these plugins:

Workflow: Aggregator
1.0

Workflow: API
1.0

Workflow: Basic Steps
1.0

Workflow: Groovy CPS Execution
1.0

Workflow: Global Shared Library for CPS workflow
1.0

Workflow: Durable Task Step
1.0

Workflow: Job
1.0

Workflow: SCM Step
1.0

Workflow: Step API
1.0
Workflow: Execution Support

Is there any other location with some details about these?

regards Domi

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/EA516CE9-67CB-4ED6-A9BC-02195CC84BF7%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Is there any way to transport through sockets in java of jenkins object such as views jobs .

[domi]

There is also a plugin implementing a master-to-master communication contract - 
maybe that could help you some how too…
https://github.com/jenkinsci/master-to-master-api-plugin
Domi


On 20.11.2014, at 21:14, oliver gondža ogon...@gmail.com wrote:

 On Thu, 20 Nov 2014 20:53:35 +0100, rakesh ranjan rakesh.nit@gmail.com 
 wrote:
 
 Hi ,
 
 I want to transport freestyle project object from one jenkins to another
 by socket in java .
 when i tried it gave me java.io.WriteAbortedException: writing aborted;
 java.io.NotSerializableException: .
 
 Well, not all objects are designed to be serializable and Job implementations 
 fall into this category. What exactly are you trying to achieve? There are 
 existing tools to transfer configuration or whole builds (with corresponding 
 job).
 
 https://wiki.jenkins-ci.org/display/JENKINS/Build+Publisher+Plugin
 https://github.com/olivergondza/jenkins-config-cloner
 
 -- 
 oliver
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Further component renames/deletions in Jira

[domi]

+1 for the rename, 
but would we not need some kind of aliasing in the core for to ease renaming.
after all, there are plugins which have dependencies to others in the code by 
there name like this (or similar):  updateCenter.getPlugin(“ghprb”) 
Domi

On 10.11.2014, at 14:38, Daniel Beck m...@beckweb.net wrote:

 
 On 10.11.2014, at 11:30, Stephen Connolly stephen.alan.conno...@gmail.com 
 wrote:
 
 There should be two components:
 
 literate-api
 literate-plugin
 
 The literate-api is a separate beast that is potentially independent of 
 Jenkins in order to allow people to develop additional tooling, we may even 
 move it to its own github org if it proves popular enough (which presupposes 
 I get enough time to push it to a 1.0)
 
 Thanks for the clarification!
 
 
 
 I'd like to add
 
rename ghprb-plugin to github-pull-request-builder-plugin
 
 to the list of suggestions. The current name appears to be difficult to find 
 for end users.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin usage statistics

[domi]

Feel free to sen PullRequests…
Domi

On 06.11.2014, at 12:29, martoe martin.ehrnhoe...@gmail.com wrote:

 Thanks Dominik for your reply.
 I already found the pages you mentioned - but they do not display all the 
 information I am looking for... I guess I will create my own statistics then.
 
 Cheers,
 Martin
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center is switched to v3.

[domi]

This change might have caused issues with the plugin-info-macro on confluence. 
Cannot Load Update Center
error 404 loading update-center.json



https://wiki.jenkins-ci.org/display/JENKINS/Scriptler+Plugin

Domi



On 06.11.2014, at 07:19, Kohsuke Kawaguchi k...@kohsuke.org wrote:

 I've just switched over http://updates.jenkins-ci.org/ from the previous v2 
 layout from the new v3 layout. To my testing everything is working as 
 expected, but if you see any hiccup or regressions in the next few days, let 
 me know.
 
 This is a backend change that's invisible from Jenkins instances out there.
 
 The main motivation of this change is to serve the not exactly the latest 
 but works with your Jenkins version of plugins from UC for older versions of 
 Jenkins out there. This in turn allows plugin developers to adopt newer core 
 features more aggressively, because doing so doesn't cut off users of earlier 
 versions. They still see some version available for them to install. I'm 
 using JENKINS-6097 to track this. This is a pain we started to feel as we try 
 to update plugins to be workflow-capable, which requires us to depend on 
 1.580.
 
 UC v3 attains this goal by generating 8 update sites for different version 
 ranges, and use the version Jenkins reports to serve the best site. 
 Previously we only had two, one for mainline and the other for LTS. As was 
 with v2, The landing URL is always the same, so that you don't have to change 
 update center config when you move from one version to another.
 
 I've captured some more details in here if anyone is interested.
 
 -- 
 Kohsuke Kawaguchi
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hosting request for bumblebee-HP-ALM-jenkins-plugin

[domi]

I see, so it makes sense then...
I'm currently online via mobile only, so maybe someone else could fork this 
repo?
Domi 



 Am 26.10.2014 um 04:35 schrieb Ali Raza ali.r...@agiletestware.com:
 
 I see what you mean. Bumblebee is a product of our company that is why we 
 need to add it in the plugin name.
 
 Ali
 
 On Oct 25, 2014 7:21 PM, domi d...@fortysix.ch wrote:
 Hi Ali,
 The question is just whether bumblebee should really be used in the name or 
 not, I don't think it adds any value to the user, as it does not point out 
 the purpose of the plugin. I would just call it hp-alm-plugin, that's more 
 compact and clear.
 ...just my 2cent...
 Regards Domi 
 
 
 
 Am 26.10.2014 um 01:45 schrieb Ali Raza ali.r...@agiletestware.com:
 
 Hi Domi,
 Not sure I fully understand the question. The bumblebee jenkins plugin 
 allows users to sends results from their jenkins jobs to HP ALM. 
 
 Ali
 
 On Sat, Oct 25, 2014 at 8:39 AM, domi d...@fortysix.ch wrote:
 I don't know the HP-ALM suite, but is bumblebee adding any value for the 
 user to identify the purpose of the plugin?
 If not, I would skip it.
 Domi
 
 
 Am 24.10.2014 um 10:08 schrieb Sergey Oplavin oplavin.ser...@gmail.com:
 
 Hello,
 
 We would like to put our plugin into Jenkins official plugin list.  The 
 plugin allows sending build reports to HP Quality Center/ALM.
 plugin name: bumblebee-HP-ALM-jenkins-plugin
 github id: ali.r...@agiletestware.com
 repository: https://github.com/agiletestware/bumblebee
 Thanks in advance!
 Best Regards
 Sergey Oplavin
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hosting request for bumblebee-HP-ALM-jenkins-plugin

[domi]

I don't know the HP-ALM suite, but is bumblebee adding any value for the user 
to identify the purpose of the plugin?
If not, I would skip it.
Domi


 Am 24.10.2014 um 10:08 schrieb Sergey Oplavin oplavin.ser...@gmail.com:
 
 Hello,
 
 We would like to put our plugin into Jenkins official plugin list.  The 
 plugin allows sending build reports to HP Quality Center/ALM.
 plugin name: bumblebee-HP-ALM-jenkins-plugin
 github id: ali.r...@agiletestware.com
 repository: https://github.com/agiletestware/bumblebee
 Thanks in advance!
 Best Regards
 Sergey Oplavin
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hosting request for bumblebee-HP-ALM-jenkins-plugin

[domi]

Hi Ali,
The question is just whether bumblebee should really be used in the name or 
not, I don't think it adds any value to the user, as it does not point out the 
purpose of the plugin. I would just call it hp-alm-plugin, that's more compact 
and clear.
...just my 2cent...
Regards Domi 



 Am 26.10.2014 um 01:45 schrieb Ali Raza ali.r...@agiletestware.com:
 
 Hi Domi,
 Not sure I fully understand the question. The bumblebee jenkins plugin allows 
 users to sends results from their jenkins jobs to HP ALM. 
 
 Ali
 
 On Sat, Oct 25, 2014 at 8:39 AM, domi d...@fortysix.ch wrote:
 I don't know the HP-ALM suite, but is bumblebee adding any value for the 
 user to identify the purpose of the plugin?
 If not, I would skip it.
 Domi
 
 
 Am 24.10.2014 um 10:08 schrieb Sergey Oplavin oplavin.ser...@gmail.com:
 
 Hello,
 
 We would like to put our plugin into Jenkins official plugin list.  The 
 plugin allows sending build reports to HP Quality Center/ALM.
 plugin name: bumblebee-HP-ALM-jenkins-plugin
 github id: ali.r...@agiletestware.com
 repository: https://github.com/agiletestware/bumblebee
 Thanks in advance!
 Best Regards
 Sergey Oplavin
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to publish a Jenkins plug-in

[domi]

done, welcome a board!
Domi


On 06.10.2014, at 07:49, Krishna Kishore clkkish...@gmail.com wrote:

 Hi Domi,
 
 Thanks for creating the repository. I just  signed up in the issue tracker 
 and my userid in JIRA is clkkishore, please created the required component.
 
 Thanks,
 Kishore
 
 On Friday, 3 October 2014 11:08:05 UTC+5:30, Dominik Bartholdi wrote:
 done: https://github.com/jenkinsci/teamconcert-git-plugin
 but creating a component for you in the issue tracker failed, what is your 
 userid in JIRA?
 
 ...I don't have permission to create a CI job, can someone else create one?
 Domi
 
 
 On 03.10.2014, at 06:19, Krishna Kishore clkki...@gmail.com wrote:
 
 Hi Jenkins Dev Team,
 
 Any update on my request to host a new plugin.
 
 Thanks,
 Kishore
 
 
 On Monday, 29 September 2014 14:46:39 UTC+5:30, Krishna Kishore wrote:
 Due to different dependencies we decided not to extend the functionality of 
 the existing plugin but write a new plugin. The existing plugin implements 
 the SCM extension point of Jenkins and the new plugin is much more lighter 
 and uses the Build extension point. The target audience for the two plugins 
 is also different. Their are some common aspects and we are looking a best 
 ways to create a common layer that can be used by the two plugins.
 
 Thanks,
 Kishore
 
 On Monday, 29 September 2014 11:03:54 UTC+5:30, Dominik Bartholdi wrote:
 How about extending the existing one with your functionality?
 From a users point of view this is what I would love to see - as I guess you 
 would provite of some of the existing features too
 Or maybe extract the parts the two plugins would have in common and create a 
 base plugin which can be extended by implementing EPs
 Domi
 
 On 28.09.2014, at 16:01, Krishna Kishore clkki...@gmail.com wrote:
 
 Hi,
 
 The existing plugin woks with the RTC Source control, it helps teams which 
 use RTC as SCC and Jenkins as CI engine. The new plugin will work with 
 projects which use Git as source control and integrate (i.e create 
 traceability links) Jenkins builds with RTC Work Items and Builds. This 
 plugin is for teams which use Git as Source control and want to use RTC for 
 Tracking and Planning.
 
 Thanks,
 Kishore
 
 On Sunday, 28 September 2014 12:37:47 UTC+5:30, Dominik Bartholdi wrote:
 How is this one different to the existing teamconcert plugin? [1]
 It seems very active.
 Domi
 
 [1] https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin
 
 Am 28.09.2014 um 06:09 schrieb Krishna Kishore clkki...@gmail.com:
 
 Hi Jenkins Dev team,
 
 I am with the Rational Team Concert(RTC) Development team in IBM  
 (www.ibm.com, www.jazz.net). We are developing a plugin which will 
 integrate Jenkins Builds using Git as Source control to RTC Work items and 
 builds. We would like to publish the plugin at jenkins-ci.org. Here are 
 the details related to plugin
 
 Plugin Name: Team Concert Git Plugin
 Github Repository: https://github.com/clkkishore/teamconcert-git-plugin
 Github id: clkkishore
 Plugin Description: Integrates Jenkins with Rational Team Concert for 
 Jenkins Builds which use Git as source control. This plugin will create 
 traceability links from a Jenkins build to RTC work items and build result.
 
 Can someone please clone this to jenkinsci and provide me access for the 
 same. 
 
 Thanks In advance,
 
 Regards,
 Kishore
 
 PS: Currently the project 
 https://github.com/clkkishore/teamconcert-git-plugin contains only a 
 readme file will add the sources once the repository is cloned into 
 jenkinssci space.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-de...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-de...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-de...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https

Re: Need of access to upload new plugin.

[domi]

Hey Dannis,
with no release I just mean, that I was not able to find a release in the 
update center and also not a repository on GH (the only thing there is is a 
Wiki page [1]) - but anyway as you say it seems not relevant.
So lets get some feedback from Kutzi :)
Gruss Domi

[1] https://wiki.jenkins-ci.org/display/JENKINS/elboca

On 03.10.2014, at 09:52, Dennis Jacobs jcbs.d...@gmail.com wrote:

 Hi Dominik,
 
 What exactly do you mean with no release, are you refering to the hpi-file?
 And you can ignore the elboca-plugin since i'm planning to merge it either 
 today or monday.
 It actually depends on what Kutzi thinks about the pubsub-feature and if it 
 can't be implemented into the jabber plugin.
 
 This does require that the elOyente plugin will remain seperate.
 Mainly since this is an implementation of the pubsub-feature, and therefore 
 no standard.
 Regarding the ownership, I don't mind taking up the responsibility.
 However if i can avoid it by merging it into the jabber-plugin I probably 
 will.
 
 Regards,
 Dennis Jacobs.
 
 On Thursday, October 2, 2014 5:30:43 PM UTC+2, Dominik Bartholdi wrote:
 
 Hi Dennis,
 
 The el-boca plugin seems not to have a release - or at least I can't find 
 it...
 In terms of how these plugins interact/integrate, I'm probably the wrong guy 
 to ask - I think Kutzi would be the right person, he is the maintainer of the 
 Jabber plugin.
 About the maintaining of your plugin - yes the idea would be that you take 
 over the ownership/maintenance of the plugin. You will then also be added as 
 the component owner in JIRA to get tickets assigned by users if any problems 
 come up.
 This is a very important part about the plugins and a reason why we take care 
 and ask about the need for the new plugins - releasing a new plugin is easy 
 but taking responsibility for it is something else.
 
 regards Domi
 
 
 On 02.10.2014, at 14:31, Dennis Jacobs jcbs...@gmail.com wrote:
 
 el-boca
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need of access to upload new plugin.

[domi]

Hi Dennis,
thanks for the update!
If you'r already thinking about merging the plugins, then I would strongly 
suggest not to publish anything before that - users will only be confused.
I also think that history has shown that most of the original promises to merge 
plugins actually never happen after a first release.
If you don't have time to do the merge right now, then just use your current 
implementation on your own installation as a private build, because as soon as 
you publish it a maintainer is required for the plugin too.
...just my 2cent...
regards Domi

On 02.10.2014, at 09:22, Dennis Jacobs jcbs.d...@gmail.com wrote:

 Hi Domi,
 
 i Thought this was clear due to the wiki pages, but i guess i still need to 
 update it a bit more.
 Basicly the jabber plugin can only send normal and group events, but no 
 pubsub.
 Since our company had previously written elOyente to pick up xmpp Pubsub 
 messages, and trigger builds based upon this info.
 We've quickly written the complimentory plugin to be able to send pubsub 
 messages.
 
 If i find the time later on, i'd like to merge both the ElOyente and the 
 ElBoca plugin in to one.
 But at this moment, i don't have the time do to so.
 However the ElBoca plugin can also be incorporated into the Jabber messenger 
 plugin.
 Don't know how the rest of the community feels about this?
 Suggestions are always welcome.
 
 Kind regards,
 Jacobs Dennis.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to publish a Jenkins plug-in

[domi]

done: https://github.com/jenkinsci/teamconcert-git-plugin
but creating a component for you in the issue tracker failed, what is your 
userid in JIRA?

...I don't have permission to create a CI job, can someone else create one?
Domi


On 03.10.2014, at 06:19, Krishna Kishore clkkish...@gmail.com wrote:

 Hi Jenkins Dev Team,
 
 Any update on my request to host a new plugin.
 
 Thanks,
 Kishore
 
 
 On Monday, 29 September 2014 14:46:39 UTC+5:30, Krishna Kishore wrote:
 Due to different dependencies we decided not to extend the functionality of 
 the existing plugin but write a new plugin. The existing plugin implements 
 the SCM extension point of Jenkins and the new plugin is much more lighter 
 and uses the Build extension point. The target audience for the two plugins 
 is also different. Their are some common aspects and we are looking a best 
 ways to create a common layer that can be used by the two plugins.
 
 Thanks,
 Kishore
 
 On Monday, 29 September 2014 11:03:54 UTC+5:30, Dominik Bartholdi wrote:
 How about extending the existing one with your functionality?
 From a users point of view this is what I would love to see - as I guess you 
 would provite of some of the existing features too
 Or maybe extract the parts the two plugins would have in common and create a 
 base plugin which can be extended by implementing EPs
 Domi
 
 On 28.09.2014, at 16:01, Krishna Kishore clkki...@gmail.com wrote:
 
 Hi,
 
 The existing plugin woks with the RTC Source control, it helps teams which 
 use RTC as SCC and Jenkins as CI engine. The new plugin will work with 
 projects which use Git as source control and integrate (i.e create 
 traceability links) Jenkins builds with RTC Work Items and Builds. This 
 plugin is for teams which use Git as Source control and want to use RTC for 
 Tracking and Planning.
 
 Thanks,
 Kishore
 
 On Sunday, 28 September 2014 12:37:47 UTC+5:30, Dominik Bartholdi wrote:
 How is this one different to the existing teamconcert plugin? [1]
 It seems very active.
 Domi
 
 [1] https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin
 
 Am 28.09.2014 um 06:09 schrieb Krishna Kishore clkki...@gmail.com:
 
 Hi Jenkins Dev team,
 
 I am with the Rational Team Concert(RTC) Development team in IBM  
 (www.ibm.com, www.jazz.net). We are developing a plugin which will 
 integrate Jenkins Builds using Git as Source control to RTC Work items and 
 builds. We would like to publish the plugin at jenkins-ci.org. Here are the 
 details related to plugin
 
 Plugin Name: Team Concert Git Plugin
 Github Repository: https://github.com/clkkishore/teamconcert-git-plugin
 Github id: clkkishore
 Plugin Description: Integrates Jenkins with Rational Team Concert for 
 Jenkins Builds which use Git as source control. This plugin will create 
 traceability links from a Jenkins build to RTC work items and build result.
 
 Can someone please clone this to jenkinsci and provide me access for the 
 same. 
 
 Thanks In advance,
 
 Regards,
 Kishore
 
 PS: Currently the project 
 https://github.com/clkkishore/teamconcert-git-plugin contains only a readme 
 file will add the sources once the repository is cloned into jenkinssci 
 space.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-de...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-de...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need of access to upload new plugin.

[domi]

What is the difference to this one?
https://wiki.jenkins-ci.org/display/JENKINS/Jabber+Plugin
Domi

On 01.10.2014, at 16:55, Dennis Jacobs jcbs.d...@gmail.com wrote:

 Hi,
 
 I've written a small jenkins plugin, in order to be able to send xmpp pubsub 
 events to an xmpp server.
 One can combine this plugin with the eloyente-plugin, which basicly triggers 
 builds upon recieved events.
 this allows jenkins-users to have inter-jenkins communiction, to start builds 
 on different servers.
 
 However I do want to be able to upload this plugin to the jenkins-repo.
 following the instructions from this page, I should provide both my github 
 id, along with the repo-url.
 I hope this suffices in order to get the proper permissions.
 
 ID: dnnsjcbs
 Repo:  https://github.com/dnnsjcbs/elboca.git
 
 With kind regards,
 Jacobs Dennis.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to publish a Jenkins plug-in

[domi]

How is this one different to the existing teamconcert plugin? [1]
It seems very active.
Domi

[1] https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin

 Am 28.09.2014 um 06:09 schrieb Krishna Kishore clkkish...@gmail.com:
 
 Hi Jenkins Dev team,
 
 I am with the Rational Team Concert(RTC) Development team in IBM  
 (www.ibm.com, www.jazz.net). We are developing a plugin which will integrate 
 Jenkins Builds using Git as Source control to RTC Work items and builds. We 
 would like to publish the plugin at jenkins-ci.org. Here are the details 
 related to plugin
 
 Plugin Name: Team Concert Git Plugin
 Github Repository: https://github.com/clkkishore/teamconcert-git-plugin
 Github id: clkkishore
 Plugin Description: Integrates Jenkins with Rational Team Concert for Jenkins 
 Builds which use Git as source control. This plugin will create traceability 
 links from a Jenkins build to RTC work items and build result.
 
 Can someone please clone this to jenkinsci and provide me access for the 
 same. 
 
 Thanks In advance,
 
 Regards,
 Kishore
 
 PS: Currently the project 
 https://github.com/clkkishore/teamconcert-git-plugin contains only a readme 
 file will add the sources once the repository is cloned into jenkinssci space.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to publish a Jenkins plug-in

[domi]

How about extending the existing one with your functionality?
From a users point of view this is what I would love to see - as I guess you 
would provite of some of the existing features too
Or maybe extract the parts the two plugins would have in common and create a 
base plugin which can be extended by implementing EPs
Domi

On 28.09.2014, at 16:01, Krishna Kishore clkkish...@gmail.com wrote:

 Hi,
 
 The existing plugin woks with the RTC Source control, it helps teams which 
 use RTC as SCC and Jenkins as CI engine. The new plugin will work with 
 projects which use Git as source control and integrate (i.e create 
 traceability links) Jenkins builds with RTC Work Items and Builds. This 
 plugin is for teams which use Git as Source control and want to use RTC for 
 Tracking and Planning.
 
 Thanks,
 Kishore
 
 On Sunday, 28 September 2014 12:37:47 UTC+5:30, Dominik Bartholdi wrote:
 How is this one different to the existing teamconcert plugin? [1]
 It seems very active.
 Domi
 
 [1] https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin
 
 Am 28.09.2014 um 06:09 schrieb Krishna Kishore clkki...@gmail.com:
 
 Hi Jenkins Dev team,
 
 I am with the Rational Team Concert(RTC) Development team in IBM  
 (www.ibm.com, www.jazz.net). We are developing a plugin which will integrate 
 Jenkins Builds using Git as Source control to RTC Work items and builds. We 
 would like to publish the plugin at jenkins-ci.org. Here are the details 
 related to plugin
 
 Plugin Name: Team Concert Git Plugin
 Github Repository: https://github.com/clkkishore/teamconcert-git-plugin
 Github id: clkkishore
 Plugin Description: Integrates Jenkins with Rational Team Concert for 
 Jenkins Builds which use Git as source control. This plugin will create 
 traceability links from a Jenkins build to RTC work items and build result.
 
 Can someone please clone this to jenkinsci and provide me access for the 
 same. 
 
 Thanks In advance,
 
 Regards,
 Kishore
 
 PS: Currently the project 
 https://github.com/clkkishore/teamconcert-git-plugin contains only a readme 
 file will add the sources once the repository is cloned into jenkinssci 
 space.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-de...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal : Jenkins to require Java 8

[domi]

I fully agree with Nicolas. And maybe we could use this chance to jump to v2 of 
Jenkins and even think about changing/removing/refactor some stuff we currently 
do with ugly workarounds. I'm sure there are a couple of things core developers 
would love to have fixed...
And plugins should?/could? then really express there compatibility with the new 
version. 
regards Domi

On 24.09.2014, at 10:17, nicolas de loof nicolas.del...@gmail.com wrote:

 Changed the thread topic, as it sounds it's not appealing enough to get 
 feedback :)
 
 2014-09-23 18:33 GMT+02:00 nicolas de loof nicolas.del...@gmail.com:
 Hi folks,
 
 we had discussions here about requiring java 6 for Jenkins. I don't see a 
 major benefit for using it, as new API/feature would offer border-line 
 changes to jenkins codebase. Same for Java 7 (which is announced EOL anyway)
 
 Makes me wonder if we could start discussion on migrating to Java 8. This 
 would allow use of default methods for interface based extension, lambdas, 
 and few other significant features for plugin and core developers. This won't 
 prevent people to build project on java 1.1 if they wish.
 
 wdyt ?
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.