Interested in building your plugin on ci.jenkins.io?

[R. Tyler Croy]

Howdy there, your friendly project infrastructure dude here. I'm hoping to get
more accurate usage requirements for our eventual migration of
https://ci.jenkins.io, and the rest of our infra, to Azure [0]. If your plugin
repository already has a `Jenkinsfile`, or you're interested in creating one
for your plugin, I would love to have your plugin built on our existing
Jenkins-on-Jenkins.


We already have a couple plugins [1] being built on ci.jenkins.io, but I need
more!


If you're interested in having your plugin built and/or helping out, please
reply or ping me (rtyler) in the #jenkins-infra channel.



[0] https://jenkins.io/blog/2016/05/18/announcing-azure-partnership/
[1] https://ci.jenkins.io/job/Plugins/


- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
------------------------------------------------------

[Mark Waite]

I'd like the git client plugin built on https://ci.jenkins.io/ if possible.  It already has a Jenkinsfile on its active branches, and has been running tests in my various development and test environments from that Jenkinsfile.

Mark Waite

--
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/20160808154816.GP22427%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Waite]

Is there an eventual evolution planned to move to using the GitHub Organizations Folder plugin to build and test pull requests for subsets of the jenkinsci GitHub organization?  

I was quite impressed with the results of my quick experiments with the GitHub Organizations Folder plugin.

Mark Waite

[R. Tyler Croy]

(replies inline)

On Mon, 08 Aug 2016, Mark Waite wrote:

> I'd like the git client plugin built on https://ci.jenkins.io/ if
> possible. It already has a Jenkinsfile on its active branches, and has
> been running tests in my various development and test environments from
> that Jenkinsfile.

It's already there :)

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtG86cA6duaro5vsfA57TPvfNMFL0cgrQ6TnJz-N5cxQYw%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

[Mark Waite]

I see the git plugin but not the git client plugin. What's the link?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20160808160932.GQ22427%40blackberry.coupleofllamas.com.

[Jesse Glick]

On Mon, Aug 8, 2016 at 11:48 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> If your plugin
> repository already has a `Jenkinsfile`, or you're interested in creating one
> for your plugin, I would love to have your plugin built on our existing
> Jenkins-on-Jenkins.

I continue to advocate having *all* plugins built via a predefined
script¹, as we do on jenkins.ci.cloudbees.com, rather than having
dozens of similar but subtly different `Jenkinsfile`s strewn around
the organization in various states of disrepair.


¹At least one per build technology, like Maven or Gradle.

[Mark Waite]

On Mon, Aug 8, 2016 at 12:06 PM Jesse Glick <jgl...@cloudbees.com> wrote:

On Mon, Aug 8, 2016 at 11:48 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> If your plugin
> repository already has a `Jenkinsfile`, or you're interested in creating one
> for your plugin, I would love to have your plugin built on our existing
> Jenkins-on-Jenkins.

I continue to advocate having *all* plugins built via a predefined
script¹, as we do on jenkins.ci.cloudbees.com, rather than having
dozens of similar but subtly different `Jenkinsfile`s strewn around
the organization in various states of disrepair.

I prefer the Jenkinsfile technique (rather than a pre-defined script) because it will allow me to adapt and refine interesting portions of the ci.jenkins.io build process, without granting me permission to modify the infrastructure.

I hope one day to be able to use the Jenkinsfile to run and report findbugs warnings, to run and report code coverage, and more.

The Jenkinsfile combined with pull request evaluation (like GitHub Organization Folders) would allow me to propose a Jenkinsfile change in a pull request, watch it be built, then decide if I want to merge it based on the results of the build.

Is there a way with the predefined script to still give plugin maintainers some control of the job definition, without defeating the benefits of the predefined script?

Mark Waite

 

¹At least one per build technology, like Maven or Gradle.

 

--

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/CANfRfr1jYz82Aw%2Bo6mnmoTD8V4_T4qhv_qywmWJNf4LDGCk3nA%40mail.gmail.com.

[R. Tyler Croy]

(replies inline)

This is a noble goal, but it simply is *not* enough (see the recent thread on
Travis CI for plugins). The loss of flexibility has centralized responsibility
for jenkins.ci.cloudbees.com in a way that has resulted unnecessary overhead
(manually creating jobs) and stagnation (you only get JDK7 and you'll like it).

I'm interested in having a few early adoptors for writing Jenkinsfiles for
ci.jenkins.io so we can identify commonalities that should be going into a
Global Library steps and uploaded appropriately. The top-down approach for
templates in jenkins.ci.c.c worked when there was nothing in its place, but to
me the Jenkinsfile and Pipeline is the correct means for distribution of
responsibility here.


I will not start inviting all plugins under jenkinsci/ until I'm confident
that:

* We have the right set of steps to reduce copy-paste
* We can run Jenkins Pipeline with hundreds of committers
and/or the right access control scheme that ensures system stability and
security



To me, this is the beginning of the iterative process to accomplish those tasks.

[R. Tyler Croy]

(replies inline)

On Mon, 08 Aug 2016, Mark Waite wrote:

> Is there an eventual evolution planned to move to using the GitHub
> Organizations Folder plugin to build and test pull requests for subsets of
> the jenkinsci GitHub organization?
>
> I was quite impressed with the results of my quick experiments with the
> GitHub Organizations Folder plugin.

So I misread earlier, git-client being a different thing than git. I'll look
into incorporating it.


I am very keen on incorporating the GitHub Organization Folder plugin, I was
experimenting heavily with it last week. I am trying to avoid opening the
flood-gates for all repositories, so getting the access-control list in order
is the first step for me :)

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFaZeOZ8Ph0H21%3D2-QSReoQuMhmcp%2B-LMzNjd_5MkpBkg%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

[Mark Waite]

On Mon, Aug 8, 2016 at 1:21 PM R. Tyler Croy <ty...@monkeypox.org> wrote:

(replies inline)

On Mon, 08 Aug 2016, Mark Waite wrote:

> Is there an eventual evolution planned to move to using the GitHub
> Organizations Folder plugin to build and test pull requests for subsets of
> the jenkinsci GitHub organization?
>
> I was quite impressed with the results of my quick experiments with the
> GitHub Organizations Folder plugin.


So I misread earlier, git-client being a different thing than git. I'll look
into incorporating it.


I am very keen on incorporating the GitHub Organization Folder plugin, I was
experimenting heavily with it last week. I am trying to avoid opening the
flood-gates for all repositories, so getting the access-control list in order
is the first step for me :)

The git plugin might be an interesting test case for a prototype of GitHub Organization Folders, since it has at least a few pull requests that include a Jenkinsfile.

Mark Waite

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20160808192142.GV22427%40blackberry.coupleofllamas.com.

[Jesse Glick]

On Mon, Aug 8, 2016 at 2:17 PM, Mark Waite <mark.ea...@gmail.com> wrote:
> I hope one day to be able to use the Jenkinsfile to run and report findbugs
> warnings, to run and report code coverage, and more.

I would expect all that to be part of the standard script; there is
nothing repository-specific about it.

> Is there a way with the predefined script to still give plugin maintainers
> some control of the job definition, without defeating the benefits of the
> predefined script?

Sure, options can be loaded from per-repository property files or
whatever format you like.

Tyler wrote:
> unnecessary overhead (manually creating jobs)

Of course the idea would be to use an organization folder so there is
no need to manually create jobs. (jenkins.ci handles this with an
ad-hoc script.)

> stagnation (you only get JDK7 and you'll like it)

As above, it is straightforward to provide overridable defaults on a
per-repository basis. (jenkins.ci handles this with template
attributes, though loading from SCM on the branch being built is
generally better.)

[Manfred Moser]

Hi Tyler,

Can you point me to some docs on setting that up. I would like to create that setup for the tfs jenkins plugin.

Manfred

--
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+unsubscribe@googlegroups.com.

[fkp...@gmail.com]

Hi,
will there be any support for Xbuild ? so that a combined java & c# plugin can be built?

if so, I'd like the hp automation tools plugin to be built on that and i'll write the Jenkinsfile.

thanks
Fima.

[R. Tyler Croy]

(replies inline)

On Tue, 09 Aug 2016, fkp...@gmail.com wrote:

> Hi,
> will there be any support for Xbuild ? so that a combined java & c# plugin
> can be built?
>
> if so, I'd like the hp automation tools plugin to be built on that and i'll
> write the Jenkinsfile.

I'm not clear on whether the XBuild plugin currently supports Pipeline. I'm
open to installing plugins in ci.jenkins.io if they provide utility via the
Pipeline DSL.

As of right now however, we have zero Windows-based agents
(https://issues.jenkins-ci.org/browse/INFRA-606) but that support is planned in
the near future.


Cheers

[R. Tyler Croy]

(replies inline)

On Mon, 08 Aug 2016, Manfred Moser wrote:

> Hi Tyler,
>
> Can you point me to some docs on setting that up. I would like to create
> that setup for the tfs jenkins plugin.

Does the tfs plugin require Windows-based agents to build? If so, you might be
blocked by https://issues.jenkins-ci.org/browse/INFRA-606

Either way, you're right to ask about docs, which I need to get written and
posted!


Will bump the thread with a link once they're done.

[Manfred Moser]

Tyler,

the TFS Plugin does not need a windows agent to run the build. For IT tests is needs a full TFS server but we are handling that separately already anyway. Just for simple build integration without the IT tests as we have not it might be a good simple start. We already have a build on the old infrastructure but it might be a good step to add the new one and then once we are happy turn off the old and therefore help you with the migration and get access to new features ;-) 

Manfred

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20160810172755.GA22427%40blackberry.coupleofllamas.com.

[Gavin Mogan]

Will there be any solutions for getting secrets available?

I've been working on a Jenkinsfile to run on our internal one (https://github.com/saucelabs/jenkins-sauce-ondemand-plugin/blob/master/Jenkinsfile) but want to hook up various external tools for "quality" checking.

Gavin

[Kanstantsin Shautsou]

Is it possible to run docker daemon?

[R. Tyler Croy]

(replies inline)

On Fri, 12 Aug 2016, Kanstantsin Shautsou wrote:

> Is it possible to run docker daemon?

Could you expand more on what you mean by this? Does this mean executing an
agent as root, or having the ability to run a Docker daemon parallel to the one
already running on the machine?


As of right now there are no dynamically provisioned agents attached to
ci.jenkins.io, but my plan is to change to having some Swarm-based agents and
some freshly provisioned Azure agents.



Cheers

[Kanstantsin Shautsou]

In travis i have sudo and running docker, i can re-install it and i can run docker in docker. Prepare env in any way i need for integration tests.
So the same.

> --
> 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/439-IDYNSVY/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/20160812140012.GD22427%40blackberry.coupleofllamas.com.

[R. Tyler Croy]

(replies inline)

On Fri, 12 Aug 2016, Kanstantsin Shautsou wrote:

> In travis i have sudo and running docker, i can re-install it and i can run docker in docker. Prepare env in any way i need for integration tests.
> So the same.

Can you link me to your .travis.yml so I can see exactly what your current
integration tests require?

My preference is to avoid giving out super user access to machines without a
review process Infra is involved in (plugin Jenkinsfiles), so I'm curious if
what you're relying on currently can be provided for without writing a black
cheque for Azure VMs.

If we cannot find a way around super user access, I'll have to rethink some of
the host and network security constraints this cluster will be working in.

[Robert Sandell]

What are the specs for the slaves that the plugin builds will be running on? I'm asking because I had to do some tweaking of my surefire parameters to make them fit into the slaves (sorry agents) the community plugins are currently building on. So an increase in available cores for example might make my build take all available memory ;)

/B

--

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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20160812181815.GE22427%40blackberry.coupleofllamas.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[R. Tyler Croy]

(replies inline)

On Wed, 17 Aug 2016, Robert Sandell wrote:

> What are the specs for the slaves that the plugin builds will be running
> on? I'm asking because I had to do some tweaking of my surefire parameters
> to make them fit into the slaves (sorry agents) the community plugins are
> currently building on. So an increase in available cores for example might
> make my build take all available memory ;)

The VM sizes that we have access to, generally, are listed here:
<https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sizes/>

I have also done some cost-analysis and summarized some machine sizes that we
will likely be using in this document:
<https://github.com/jenkins-infra/azure/blob/master/pricing.adoc>

I have priced out running a Docker Swarm cluster for full-time rapid use
builds, and those would be Standard D3 machines.

My /hope/ is that not every single job in ci.jenkins.io attempts to use the
most expensive VM sizes, but I'm interested in what you all think would be the
ideal sizing to meet the plugin build/test use-cases.


Th time-to-bootstrap comparision between Docker Swarm agents and Azure VMs for
testing is about 30s vs. 2-5minutes respectively, so consider that for what
plugin builds would need too.


I would appreciate any thoughts/suggestions :)

Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

[Robert Sandell]

Well, the default setting in the new plugin parent pom is a test-parallelisation of 1C and IIRC the default max heap the the JVM runs on is 512MB. My tests are a bit more hungry for heap than that so I've set the max heap to 1GB per fork (I used to have it on 2GB but our current build slaves couldn't manage that so I needed to tweak my tests a bit) Far from all my tests needs that much but I don't have more fine grained control than that that I know of :)

So a Standard_D3 is well covered for the tests with 4 cores and 14GB of RAM
But you wouldn't be able to run more than three docker containers per VM before there is a slight risk that some of my tests will fail in a perfect storm, since the JVM doesn't care about what resource restrictions you put on the containers, it only reads the host values unfortunately.
But you should be able to have 6 or 7 containers per VM for those plugins that have the default settings. And I could set my fork count to 0.5C but then, I guess, my tests would take over an hour to run :O

And I doubt that I care about the CPU and disk performance at all (within reason), it could be spinning rust and I don't think I would complain :) But I don't see any alternatives for slower CPU without SSD but lots of RAM on the page you provided.

/B

------------------------------------------------------

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20160817194739.GK22427%40blackberry.coupleofllamas.com.

For more options, visit https://groups.google.com/d/optout.

[Stefan Wolf]

Hi Tyler,

I just added a Jenkinsfile to the Jenkins Gradle plugin [1]. Could you add this plugin to https://ci.jenkins.io?

Cheers,

Stefan

[1] https://github.com/jenkinsci/gradle-plugin

[James Dumay]

Hi Tyler, 

I'd love for https://github.com/jenkinsci/display-url-api-plugin to be built on that server. There is a Jenkinsfile already in the repo.

Thanks,

James

[Mark Waite]

Is there a plan to update ci.jenkins.io to the latest workflow plugin so that I can switch to uses "{" and  "}" to identify blocks?  I'd like to remove the warning from the jobs I host on my private machines, but I don't want to break ci.jenkins.io with a Jenkinsfile that it does not yet understand.

Mark Waite

--

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/322f8781-a227-4465-a3c9-c4fac57cec57%40googlegroups.com.

[R. Tyler Croy]

(replies inline)

On Sun, 04 Sep 2016, Mark Waite wrote:

> Is there a plan to update ci.jenkins.io to the latest workflow plugin so
> that I can switch to uses "{" and "}" to identify blocks? I'd like to
> remove the warning from the jobs I host on my private machines, but I don't
> want to break ci.jenkins.io with a Jenkinsfile that it does not yet
> understand.

I'm not sure I understand what you're referring to. To identify *stage* blocks
I presume?

- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

[Mark Waite]

On Tue, Sep 6, 2016 at 2:08 PM R. Tyler Croy <ty...@monkeypox.org> wrote:

(replies inline)

On Sun, 04 Sep 2016, Mark Waite wrote:

> Is there a plan to update ci.jenkins.io to the latest workflow plugin so
> that I can switch to uses "{" and  "}" to identify blocks?  I'd like to
> remove the warning from the jobs I host on my private machines, but I don't
> want to break ci.jenkins.io with a Jenkinsfile that it does not yet
> understand.


I'm not sure I understand what you're referring to. To identify *stage* blocks
I presume?

Yes, to identify "stage" blocks.  Currently, the git client plugin and the git plugin both include a Jenkinsfile on their relevant branches.  Those files use the previous syntax:

node {

  stage 'Checkout'

  checkout scm

  stage 'Build'

  mvn "clean install"

}

I'd like to switch to the new syntax:

node {

  stage('Checkout') {

    checkout scm

  |

  stage('Build') {

    mvn "clean install"

  }

}

If I switch to the new syntax, machines running older versions of the pipeline plugins will fail because they don't understand the new syntax.

Thanks,

Mark Waite

 

- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

--
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/20160906200817.GF18556%40blackberry.coupleofllamas.com.

[hal...@gmail.com]

I assume you are talking about the new plugin created by Andrew Bayer?

 

https://jenkins.io/blog/2016/09/06/jenkins-world-speaker-blog-pipeline-model-definition/

 

https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Model+Definition+Plugin

--
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/439-IDYNSVY/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/CAO49JtGH5V_LDZDd%3DXU9WbLp3b1WrO6SA_v7bgJd6scQHqd-0g%40mail.gmail.com.

[Kanstantsin Shautsou]

So moving back from flexible DSL to declarative configuration?

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20160906200817.GF18556%40blackberry.coupleofllamas.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/439-IDYNSVY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGH5V_LDZDd%3DXU9WbLp3b1WrO6SA_v7bgJd6scQHqd-0g%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/439-IDYNSVY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/57cf29dc.46ec420a.ca6c.09c2%40mx.google.com.

[Daniel Beck]

> On 06.09.2016, at 22:41, hal...@gmail.com wrote:
>
> I assume you are talking about the new plugin created by Andrew Bayer?
>
> https://jenkins.io/blog/2016/09/06/jenkins-world-speaker-blog-pipeline-model-definition/
>
> https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Model+Definition+Plugin

No, the existing pipeline-stage-step has been modified for JENKINS-26107.

[R. Tyler Croy]

(replies inline)

ci.jenkins.io has had all necessary plugin updates installed.

[Alexandru Somai]

Hello,

I'd like to have one of my plugins, the run-selector-plugin, to be built on ci.jenkins.io too. From what I've seen, now it uses the GitHub Org plugin for this, so when I have the Jenkinsifle in the repository, the project should be automatically created in https://ci.jenkins.io/job/Plugins/.

My question is, when does the "Re-scan organization" is set to trigger? or it's just a manual trigger? Does it have an automatic schedule?

Because, I guess that only after the "Re-scan organization" has been run, then my project will be available for building there.

Regards,

Alex

[Jesse Glick]

On Sun, Oct 23, 2016 at 10:52 AM, Alexandru Somai
<somai.a...@gmail.com> wrote:
> it uses the GitHub Org plugin
> for this, so when I have the Jenkinsifle in the repository, the project
> should be automatically created in https://ci.jenkins.io/job/Plugins/.

According to

https://ci.jenkins.io/job/Plugins/computation/console

there is a manual include/exclude list of some kind, so I guess you
would need to file an INFRA ticket.

[R. Tyler Croy]

(replies inline)

This is correct, it is a manually curated list. I added run-selector-plugin to
it though.

>
> --
> 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/CANfRfr1jgPWkBVbRJxMKWkArBq_o73Rn5Q6Tp2KMs8d92ZMMfQ%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

[Gavin Mogan]

Can you add https://github.com/jenkinsci/sauce-ondemand-plugin too? 

I finally got it not eating up a ton of memory

[Fritz Elfert]

Please add https://github.com/jenkinsci/jclouds-plugin

Also: I would like to use maven 3.2.x instead of maven 3.3.x
See: https://groups.google.com/forum/#!topic/jenkinsci-dev/ebczuKKmOPg

Thanks
-Fritz

[R. Tyler Croy]

(replies inline)

On Tue, 14 Feb 2017, Fritz Elfert wrote:

> Please add https://github.com/jenkinsci/jclouds-plugin


You may be interested in using the buildPlugin() method provided by a Shared
Library. Makes things rather simple, and looks like it covers the defaults the
jclouds-plugin's Jenkinsfile already has:
https://github.com/jenkins-infra/pipeline-library#buildplugin

> Also: I would like to use maven 3.2.x instead of maven 3.3.x
> See: https://groups.google.com/forum/#!topic/jenkinsci-dev/ebczuKKmOPg

If this is something important to you, I suggest using the Docker Pipeline
support (allocate a node with the 'docker' label) and pull in the Maven
container desired. Tools Installers are a tremendous pain in the ass to manage
for me, so I'm not willing to start adding more than one basic version for
Maven and JDKs right now.



Cheers

- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

[Fritz Elfert]

(replies inline)

On 15.02.2017 17:40, R. Tyler Croy wrote:
> (replies inline)
>
> On Tue, 14 Feb 2017, Fritz Elfert wrote:
>
>> Please add https://github.com/jenkinsci/jclouds-plugin
>
>
> You may be interested in using the buildPlugin() method provided by a Shared
> Library. Makes things rather simple, and looks like it covers the defaults the
> jclouds-plugin's Jenkinsfile already has:
> https://github.com/jenkins-infra/pipeline-library#buildplugin

Well, to be honest, I simply copied the Jenkinsfile from the
config-file-provider. I'm a complete NOOB regarding pipelines.

>
>
>> Also: I would like to use maven 3.2.x instead of maven 3.3.x
>> See: https://groups.google.com/forum/#!topic/jenkinsci-dev/ebczuKKmOPg
>
> If this is something important to you, I suggest using the Docker Pipeline
> support (allocate a node with the 'docker' label) and pull in the Maven
> container desired. Tools Installers are a tremendous pain in the ass to manage
> for me, so I'm not willing to start adding more than one basic version for
> Maven and JDKs right now.

Being a complete pipeline-NOOB (and on top: Docker-NOOB), I'd really
appreciate some example or perhaps a pointer to some doc which shows how
to "pull" some maven container.

Thanks
-Fritz

[Robert Sandell]

Here is one example using the declarative style that is running on ci.jenkins.io 

https://github.com/stapler/stapler/blob/master/Jenkinsfile

/B

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a822f460-ac74-67e6-95ed-c1ac36f18494%40fritz-elfert.de.

For more options, visit https://groups.google.com/d/optout.

[Fritz Elfert]

Thanks a lot! This worked well :)
-Fritz

On 17.02.2017 13:01, Robert Sandell wrote:
> Here is one example using the declarative style that is running on

> ci.jenkins.io <http://ci.jenkins.io>

> send an email to jenkinsci-de...@googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a822f460-ac74-67e6-95ed-c1ac36f18494%40fritz-elfert.de

> <https://groups.google.com/d/msgid/jenkinsci-dev/a822f460-ac74-67e6-95ed-c1ac36f18494%40fritz-elfert.de>.

> For more options, visit https://groups.google.com/d/optout

> <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-de...@googlegroups.com
> <mailto:jenkinsci-de...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0XiFX3e7H8%3DLUerFanuUF4PQn9dLTCrLRC1bOJD5389A%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0XiFX3e7H8%3DLUerFanuUF4PQn9dLTCrLRC1bOJD5389A%40mail.gmail.com?utm_medium=email&utm_source=footer>.