Re: [GSoC 2018] - Preliminary announcement

[Dyuti De]

Hello, 

I am excited to be a mentor for GSoC projects. I hope I am not too late. I 
am checking the list of existing ideas to tag in.

Thanks, 
Dyuti

On Friday, 15 December 2017 20:01:54 UTC+5:30, Oleg Nenashev wrote:
>
> Hi all,
>
> I am preparing to the launch of Google Summer of Code 2018 
>  in the Jenkins project. 
> As in 2016/2017, we will be looking for mentors 
> . It is 
> critical to have a diverse number of proposal so that the Jenkins Project 
> could get accepted this year, so I want to start it early this year.
>
> GSoC is a pretty big deal for mentors (several hours per week), but it is 
> possible to get a full-time student working on your project for almost 4 
> months. Mentorship does not require deep knowledge of Jenkins development 
> itself, because there will be advisors around. So any contributor can 
> participate if he has interest in it and opportunity to dedicate enough 
> time.
>
> Would somebody be interested to be a mentor? If yes, just respond to this 
> thread.
>
> -
>
> Useful links:
>
>- GSoC 2018 timeline 
>
>- GSoC 2017 announcement with details
>
>- GSoC 2016 project idea examples 
>
>- GSoC Mentor Guide 
>
> More documentation will be published this month if there is an interest in 
> the community.
>
> Best regards,
> Oleg
>

-- 
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/d1f7dba6-2f8c-4fec-ba3d-2835601f4957%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Kohsuke Kawaguchi]

On Tue, Mar 6, 2018 at 2:57 AM Bill Dennis  wrote:

> Thanks Kohsuke, I tried to give some answers to your questions inline
> below, if I didn't mess up the reply..
>
> Bill
>
> On Friday, 2 March 2018 17:57:24 UTC, Kohsuke Kawaguchi wrote:
>
>>
>>
>> On Fri, Mar 2, 2018 at 9:26 AM Bill Dennis  wrote:
>>
>>> Hello Kohsuke -
>>>
>>> I am a developer using Jenkins pipeline quite lot where I work.
>>>
>>> We are using Jenkins pipelines in two scenarios:
>>>
>>>- For CI building and testing some of our internal components (what
>>>Jenkins is traditionally used for)
>>>- For running / orchestrating complex automation processes (so
>>>Jenkins is talking to some external systems using SOAP / REST etc) via
>>>tooling and even directly via REST using plugins.
>>>
>>> I have mostly used JenkinsPipelineUnit for testing / validation of the
>>> pipelines and I have been looking into the direct / live approach that Oleg
>>> demonstrated (running Jenkins locally in Docker and getting the pipeline
>>> being developed direct from a host file system volume mount).
>>>
>>> I think Jenkinsfile Runner would be really useful for developers who
>>> don't need or want the overhead of developing tests with
>>> JenkinsPipelineUnit. I have worked with some developers wanting to develop
>>> Jenkinsfiles for their CI process and the main problem is knowing if the
>>> Jenkinsfile will work when they commit it to the repo. They go round this
>>> loop of commit / fix running in the production Jenkins or using the Jenkins
>>> pipeline "replay" feature. It can be a painful process if you are not
>>> familiar with Jenkins pipeline and Groovy syntax!
>>>
>>
>> This kind of context is really helpful. Thank you!
>>
>
> Happy to feedback. Thanks for Jenkins and pipeline as code, it helped me
> deliver some projects with Jenkins in a way that I thought would not be
> possible a few years ago.
>

My pleasure, and really the portion I can take credit for is getting
smaller every day!


>
>
>> I think some things to consider are:
>>>
>>> - How does the Jenkins Runner replicate the agents / slaves identifiers
>>> on the target Jenkins?
>>> - How to deal with tooling on the target Jenkins (custom tools, JDKs,
>>> Gradle, etc)?
>>>
>>
>> Right, I guess your point is that Jenkinsfile Runner should aim to run
>> Jenkinsfile in much more realistic setup, and that doesn't stop at using
>> real Jenkins and real Pipeline plugins, but it also needs to include other
>> configurations of Jenkins. I think Jesse made a similar observation. I have
>> a few thoughts:
>>
>>- Configuration-as-code
>> could
>>play a role here in terms of letting people define the configuration of
>>Jenkins once and use it both in production and in setup like Jenkinsfile
>>Runner
>>- I'm a fan of making Jenkinsfile itself more portable. For example,
>>if people are already in the mode of using docker images to run builds in,
>>then more of the toolings would be packaged in there, and it should allow
>>Jenkinsfile Runner to run your project in much the same way as your
>>production Jenkins. I'm curious how much of this is already reality vs
>>ideal that people are working toward.
>>
>> Yes, all of this. I have often thought that we need something like
> declarative pipeline for the configuration of Jenkins as code instead of
> going into all those web config pages. Jenkins master as Docker container
> seems good. In our environment we are not currently using Docker but I have
> seen that that is the way to go. Getting a larger organisation to adopt the
> right technology and the associated costs of that is the challenge, so we
> remain using traditional Jenkins slaves and tooling methods. Hopefully
> Dockerised soon. We do use Jenkins Enterprise from CloudBees.
>

"something like declarative pipeline for the configuration of Jenkins as
code instead of going into all those web config pages" --- please do check
out the linked configuration-as-code effort. I think you'll love it.

And thanks for the explanation of the state of your current Jenkins master.

I think the perfect Jenkinsfile Runner for me would provide:
>>>
>>> - Somehow capture the plugins, tooling and agents on our production
>>> Jenkins
>>> - Validate the Jenkinsfile pipeline syntax
>>>
>>
>> I think this is already happening as a result of actually running the
>> pipeline -- one of the virtue of actually using the real pipeline plugins
>> to run!
>>
>>
>>> - Validate the Jenkinsfile against the plugins and agents / tooling
>>> (fail if it refers to some tool or agent not configured for example).
>>> - Run the Jenkinfile in some sort of "no-op" mode : what would it do if
>>> I ran it, without actually doing anything
>>>
>>
>> This one is interesting. I assumed JenkinsPipelineUnit does this pretty
>> well, though. Can you tell me more about this? I'm imagining 

Re: POTD: Jenkinsfile Runner

[Kohsuke Kawaguchi]

Oleg gave us the fix, which I merged to the master just now. I think
that'll fix the problem.

On Tue, Mar 6, 2018 at 1:22 AM Michael Neale  wrote:

> Trying this out, looks like I am hitting JEP-200:
>
> https://jenkins.io/redirect/class-filter/
>
> Need to dig in further (I thought I tried the same version of Jenkins as
> you). Anyone else seen this?
>
>
>
> java.lang.UnsupportedOperationException: Refusing to marshal
> io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons;
> see https://jenkins.io/redirect/class-filter/
> at
> hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
> at
> com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
> at
> com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
> at
> hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
> at
> hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
> Caused: java.lang.RuntimeException: Failed to serialize
> hudson.model.Actionable#actions for class
> org.jenkinsci.plugins.workflow.job.WorkflowRun
>
>
> On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
>>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some
>> Jenkins users and I felt something like this might move the needle for them
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be
>> important for you, does it miss any key points for you? If you mentally
>> picture a perfect version of this, what would that do, and how would you
>> use?
>>
>> Let me know!
>>
>> --
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/3836b845-5e9f-44d6-883d-10caf7e78832%40googlegroups.com
> 
> .
> For more options, visit 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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xs-Y3WQ365CXpeORMyo%2BL-uMScPof2FqMCzv%3DxWx7eqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Kohsuke Kawaguchi]

On Sun, Mar 4, 2018 at 8:13 AM  wrote:

> I think Jenkinsfile Runner brings a lot of opportunities for pipeline
> developers. The most obvious ones to me are
>
>1. Pipeline development (Jenkinsfile)
>2. Shared library development
>
> *Pipeline development*
>
> Right now (as described by others in this thread) pipeline development is
> either a loop of committing / fixing pipelines on production Jenkins, using
> pipeline replay on production Jenkins or setting up a local instance
> manually.
>
> With Jenkinsfile Runner we can get faster feedback without polluting our
> commit or Jenkins build history and don't have to set up a local instance
> manually.
>
Right. I think we all get this basic picture. Details are where things get
interesting!

*Shared library development*
>
> Shared library development right now works much in the same as pipeline
> development, except that you have the library code and another (often
> production) Jenkinsfile to maintain, in order to try out (as opposed to
> automatically test) your Jenkinsfile.
> For shared libraries, we thankfully already have JenkinsPipelineUnit, that
> makes it easier to implement some tests. However, (as also mentioned by
> others in this thread) this is unit testing only. It mocks most of our
> environment. Often, green unit tests mean nothing for productive use of our
> share library. I even gave up test-driven development for shared libraries,
> in favor of 90s try-and-error-style programming. Because most of the time
> when trying the library with green unit tests in production, it turns out
> that the real Jenkins environment has some restriction that is beyond the
> scope of JenkinsPieplineUnit (e.g. sandboxing).
>
Worst thing about the current state is that we don't have reliable
> regression tests. A change in shared library with green unit tests is far
> from convincing me that the library will continue to work in production.
>
> With Jenkinsfile Runner we could write small Jenkinsfiles within the
> shared library repo's test folder and run them from the Jenkinsfile of the
> shared lib. Pretty much in the same way as we use Maven Invoker Plugin (as
> mentioned by Jesse) when developing maven plugins.
>

OK, thank you, this is really helpful. I think maven invoker plugin analogy
is a great one for somebody like me. So from this perspective, mocking
isn't really high on the priority.


>
> *A first approach to shared library integration testing with Jenkinsfile
> Runner*
> My naive first approach was to build a Docker Image that contains
> Jenkinsfile Runner and all default plugins.
>
> docker run -v~/src/it/myfunction:/workspace schnatterer/jenkinsfile-runner
> :1.0-SNAPSHOT-2.108 /workspace
>
> runs the ~/foo/Jenkinsfile using Jenkinsfile Runner with all default
> plugins of Jenkins 2.108.
>
> My idea was to eventually do the same in Jenkinsfile of the shared lib
> like so (not tested)
> docker.image('schnatterer/jenkinsfile-runner:1.0-SNAPSHOT-2.108').inside {
>
> sh 'jenkinsfile-runner /app/jenkins /app/plugins src/it/myfunction'
> }
> or
> sh 'docker run --rm -v $(pwd):$(pwd) src/it/myfunction'
>

So if this is the intended use case, then I have another idea. Instead of
running Jenkinsfile in this CLI and try to emulate your Jenkins instance as
closely as possible (in terms of configuration), we could just run
Jenkinsfile in the current Jenkins, in a place that nobody else can see.

For example, packaged as CLI, you'd run it like:

   $ java -jar jenkins-cli.jar -s https://jenkins.example.com/ run-pipeline
./src/it/myfunction

Or from within Jenkinsfile, could be something like:

  pipeline.sharedlibrary.test './src/it/myfunction'

... and this would completely bypass the challenge of trying to replicate
the Jenkins configuration.



> It turned out that there a two major problems:
>
>1. There's no way to add non-default Jenkins plugins.
>My local test for cloudogu/ces-build-lib
> failed because there was
>no GitHub Groovy Libraries plugin.
>Here, my hope is that Configuration-as-code plugin might help automate
>loading plugins.
>
> Yeah, I'm really looking forward for CaC project to fill this gap, and I
know they are working on it.


>
>1. There's still no way to load a "local" shared library from the same
>repo. So, we still would have to find a way to configure the shared library
>in our Jenkinsfile Runner.
>Loading local shared libraries has already been discussed here
>
>and there .
>
> Good point.


> Once those issues are solved, we'll have a very basic way of automating
> integration tests for shared libraries by executing IT Jenkinsfiles from
> the shared libraries pipeline and failing the build if the IT fails.
>

That'd be really cool, isn't 

Re: POTD: Jenkinsfile Runner

[Kohsuke Kawaguchi]

Yeah, there are many possible ways to go about something like this,
including what you described. That's why I'm trying to hear from Bill what
his world looks like. I can use some concrete data points like that.

On Fri, Mar 2, 2018 at 11:08 AM Jesse Glick  wrote:

> On Fri, Mar 2, 2018 at 12:56 PM, Kohsuke Kawaguchi  wrote:
> > well, though. Can you tell me more about this? I'm imagining you'd want
> to
> > be able to selectively mock out some steps (e.g., when Jenkinsfile gets
> to
> > sh "./deploy.sh" don't actually do it and pretend that it succeeded)
>
> One suggestion alluded to in JENKINS-33925 was to have a globally
> recognized “dry-run” flag (akin to `Main.isUnitTest` I suppose) that
> could be checked from various features in core or plugins, so that for
> example the `mail` step would know to just print out the mail it
> _would_ have sent without actually contacting an SMTP server.
>
> This would not help directly with your example above—since Jenkins
> would have no way of knowing whether `deploy.sh` actually had any
> externally visible effects, or was just a build command operating
> locally in the workspace—but perhaps in dry-run mode a special
> environment variable could be set for the whole build which would be
> visible to external processes, so your own script could include
> something like
>
> if [ "$DRY_RUN" -eq true ]
> then
> echo "Would be deploying to ${SERVER}:"
> ls -lR
> exit
> fi
> # else proceed
>
> Not as flexible as the fine-grained mocking available (as I recall) in
> JenkinsPipelineUnit, but perhaps sufficient for many use cases.
>
> > This got me thinking that maybe all I needed was a Jenkins CLI command
> that
> > behind the scene creates a temporary/hidden job on the target Jenkins
> master
> > and run the Pipeline. IOW, keep the same development flow as Jenkinsfile
> > Runner today, but don't run Jenkins locally, just do it on your actual
> > Jenkins.
>
> Already exists (though it uses your real job). See for example
>
> https://jenkins.ci.cloudbees.com/cli/command/replay-pipeline
>
> --
> 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/CANfRfr03Mg5r5i-XxMi8TZH3uUE7ER1mox76VuA2mX-OiKciZA%40mail.gmail.com
> .
> For more options, visit 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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xBAfGRMXX8yiryE%2B3zv5cdKAefa3L53jb6egjRCBZ14w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [EVENT]: Jenkins World 2018 CFP is Open

[Alyssa Tong]

Hi Joseph,

At this moment only the CFP is available for JW EU. The Jenkins World
website  will be updated later
this wk to include JW EU (registration, location).  The home page for JW EU
is currently under development, it's slated to be available end of this
month.

Thnx,
alyssa

On Mon, Mar 5, 2018 at 8:37 PM, Joseph P  wrote:

> Hi Alyssa
>
> Can't find any info on Jenkins World Europe to convince that I should be
> going :)
> The latest CloudBees, Inc. newsletters mention Jenkins World Europe will
> be in Nice, France from October 23 to 25 but the link in the mail is not
> working and Google search is to no avail...
>
> I know it might still be early but any info would be appreciated :)
>
> /Joseph
>
>
> Den fredag den 19. januar 2018 kl. 01.59.41 UTC+1 skrev alytong13:
>>
>> Hi All,
>>
>> Jenkins World 2018 Call for Papers (CFP) launched
>>  yesterday.
>>  We are looking for use case from Jenkins practitioner, contributors,
>>  plugin developers, and users of all backgrounds and levels, from small
>> start-ups to large scaled Jenkins instances.
>>
>> This year's Jenkins World takes place in San Francisco, Sept 16 -19,
>> additionally there will be a Jenkins World Europe taking place sometime in
>> October, location is TBA.
>>
>> CFP  for both locations will be
>> open for only 2 months, deadline is
>> March 18, 2018.
>>
>> Looking forward to seeing many excellent submissions.
>>
>> BR,
>> alyssa
>>
> --
> 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/ms
> gid/jenkinsci-dev/f1b56f91-98c9-4c88-b321-fa5582bf0ca3%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/CAC9wNaxAyL1QxY7T%2Bh9q%2BYWe-nQFPxQgGAMBFqnvv4_eA98W9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valgrind plugin maintainer out of action

[Oleg Nenashev]

Hi Nils,

We do not appoint maintainers, all maintainers are contributors. If 
somebody is interested to take ownership, he just needs to ping the 
original maintainer in public channel and wait for an approval from the 
current maintainer or for a 2-week timeout.

OTOH I see the ongoing activities in the plugin: 
https://github.com/jenkinsci/valgrind-plugin/commits . There was a release 
2 hours ago. Maybe you have already got a response.

BR, Oleg


On Monday, March 5, 2018 at 7:52:44 PM UTC+1, ni...@tern.is wrote:
>
> Hi,
>
> The valgrind plugin maintainer seems to be out of action. There are a 
> number of pending pull requests including pipeline support that are really 
> valuable.
>
> Would it be possible for someone to merge these pull requests? Could a new 
> maintainer be appointed?
>
>
> I already posted this to the users list, it was suggested I repost here. 
> It was also asked whether I could take over, and the answer is no. I'm not 
> a java programmer, mostly do C and C++. If necessary I can fix bugs, but I 
> don't have time to start learning the intricacies of modern java and the 
> jenkins framework.
>
> If I needed to suggest someone it would be Jan Wulkop who implemented the 
> pipeline support (not yet merged).
>
> Cheers,
> Nils
>

-- 
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/7e584e84-9a2a-49e3-b293-719b2f8c575d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Oleg Nenashev]

https://github.com/kohsuke/jenkinsfile-runner/pull/8

On Tue, Mar 6, 2018 at 8:13 PM, Oleg Nenashev 
wrote:

> I will create a pull request, stay tuned
>
> On Tuesday, March 6, 2018 at 7:32:21 PM UTC+1, joha...@schnatterer.info
> wrote:
>>
>> Same exception here: java.lang.UnsupportedOperationException: Refusing
>> to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for
>> security reasons;
>>
>> I created an issue with full stacktrace
>> .
>> Jesse or Oleg, maybe you could elaborate there how we could fix this.
>> Which Jar needs the manifest, which library needs to be whitelisted and
>> how can we achieve this?
>>
>> Cheers,
>> Johannes
>>
>> Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>>>
>>> Jenkinsfile Runner is an experiment to package Jenkins pipeline
>>> execution as a command line tool. The intend use cases include:
>>>
>>>- Use Jenkins in Function-as-a-Service context
>>>- Assist editing Jenkinsfile locally
>>>- Integration test shared libraries
>>>
>>> Over the past year, I've done some deep-dive 1:1 conversations with some
>>> Jenkins users and I felt something like this might move the needle for them
>>> in an important way.
>>>
>>> I'd love to hear any reactions on your side. Could something like this
>>> be important for you, does it miss any key points for you? If you mentally
>>> picture a perfect version of this, what would that do, and how would you
>>> use?
>>>
>>> Let me know!
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>> --
> 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/gjz3CDhi-kk/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/8ad1c473-5292-4a38-ab6b-ab78c4371092%
> 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/CAPfivLBA%2B0k%2BXsPW57nJExWuEpao6dEs_h7oSVJ%3DHG5qQyWSRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Oleg Nenashev]

I will create a pull request, stay tuned

On Tuesday, March 6, 2018 at 7:32:21 PM UTC+1, joha...@schnatterer.info 
wrote:
>
> Same exception here: java.lang.UnsupportedOperationException: Refusing to 
> marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security 
> reasons; 
>
> I created an issue with full stacktrace 
> .
> Jesse or Oleg, maybe you could elaborate there how we could fix this.
> Which Jar needs the manifest, which library needs to be whitelisted and 
> how can we achieve this?
>
> Cheers,
> Johannes
>
> Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution 
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some 
>> Jenkins users and I felt something like this might move the needle for them 
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be 
>> important for you, does it miss any key points for you? If you mentally 
>> picture a perfect version of this, what would that do, and how would you 
>> use?
>>
>> Let me know!
>>
>> -- 
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8ad1c473-5292-4a38-ab6b-ab78c4371092%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[johannes]

Same exception here: java.lang.UnsupportedOperationException: Refusing to 
marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security 
reasons; 

I created an issue with full stacktrace 
.
Jesse or Oleg, maybe you could elaborate there how we could fix this.
Which Jar needs the manifest, which library needs to be whitelisted and how 
can we achieve this?

Cheers,
Johannes

Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>
> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution 
> as a command line tool. The intend use cases include:
>
>- Use Jenkins in Function-as-a-Service context
>- Assist editing Jenkinsfile locally
>- Integration test shared libraries
>
> Over the past year, I've done some deep-dive 1:1 conversations with some 
> Jenkins users and I felt something like this might move the needle for them 
> in an important way.
>
> I'd love to hear any reactions on your side. Could something like this be 
> important for you, does it miss any key points for you? If you mentally 
> picture a perfect version of this, what would that do, and how would you 
> use?
>
> Let me know!
>
> -- 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/aef469a7-5b3f-4fb1-9ccf-12a11a3d1be5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Oleg Nenashev]

Yeah, the entire library needs to me whitelisted (or packaged as Jenkins
module).
It's actually a quick-win to get it fixed as long as it is a development
tool.

BR, Oleg


On Tue, Mar 6, 2018 at 5:00 PM, Bill Dennis  wrote:

> I too am seeing the JEP-200 issue with these exceptions packaging to a
> Docker image and running with that using Docker for Windows:
>
> java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.
> jenkinsfile.runner.FileSystemSCM for security reasons; see https://
> jenkins.io/redirect/class-filter/
> java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.
> jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https:
> //jenkins.io/redirect/class-filter/
>
> I'd like to try out the Jenkinsfile Runner which looks like a great idea
> but I don't have time to figure this out right now (busy writing a
> plugin..).
>
> --Bill
>
>
> On Tuesday, 6 March 2018 09:22:53 UTC, Michael Neale wrote:
>>
>> Trying this out, looks like I am hitting JEP-200:
>>
>> https://jenkins.io/redirect/class-filter/
>>
>> Need to dig in further (I thought I tried the same version of Jenkins as
>> you). Anyone else seen this?
>>
>>
>>
>> java.lang.UnsupportedOperationException: Refusing to marshal
>> io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security
>> reasons; see https://jenkins.io/redirect/class-filter/
>> at hudson.util.XStream2$BlacklistedTypesConverter.marshal(
>> XStream2.java:543)
>> at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.co
>> nvert(AbstractReferenceMarshaller.java:69)
>> at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(
>> TreeMarshaller.java:58)
>> at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(
>> TreeMarshaller.java:43)
>> at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.
>> convertAnother(AbstractReferenceMarshaller.java:88)
>> at com.thoughtworks.xstream.converters.collections.AbstractColl
>> ectionConverter.writeItem(AbstractCollectionConverter.java:64)
>> at com.thoughtworks.xstream.converters.collections.CollectionCo
>> nverter.marshal(CollectionConverter.java:74)
>> at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.co
>> nvert(AbstractReferenceMarshaller.java:69)
>> at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(
>> TreeMarshaller.java:58)
>> at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.
>> convertAnother(AbstractReferenceMarshaller.java:84)
>> at hudson.util.RobustReflectionConverter.marshallField(RobustRe
>> flectionConverter.java:265)
>> at hudson.util.RobustReflectionConverter$2.writeField(RobustRef
>> lectionConverter.java:252)
>> Caused: java.lang.RuntimeException: Failed to serialize
>> hudson.model.Actionable#actions for class org.jenkinsci.plugins.workflow
>> .job.WorkflowRun
>>
>>
>> On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
>>>
>>> Jenkinsfile Runner is an experiment to package Jenkins pipeline
>>> execution as a command line tool. The intend use cases include:
>>>
>>>- Use Jenkins in Function-as-a-Service context
>>>- Assist editing Jenkinsfile locally
>>>- Integration test shared libraries
>>>
>>> Over the past year, I've done some deep-dive 1:1 conversations with some
>>> Jenkins users and I felt something like this might move the needle for them
>>> in an important way.
>>>
>>> I'd love to hear any reactions on your side. Could something like this
>>> be important for you, does it miss any key points for you? If you mentally
>>> picture a perfect version of this, what would that do, and how would you
>>> use?
>>>
>>> Let me know!
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>> --
> 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/gjz3CDhi-kk/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/da0e3018-9206-43a3-b814-4a65a73d5c17%
> 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/CAPfivLC6%3DyuTyakmF_cMryuJNa68bLLQO%3DrrR9VU%3D5gmAmfksg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update Fitnesse plugin to be compatible with Pipeline

[Daniel Beck]

> On 6. Mar 2018, at 16:37, Jeff Wilson  wrote:
> 
> If not, is there a guide for doing such a refactor?

See https://jenkins.io/doc/developer/plugin-development/pipeline-integration/

-- 
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/30C24661-0A13-4D45-9072-C27EA005C7D1%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Bill Dennis]

I too am seeing the JEP-200 issue with these exceptions packaging to a 
Docker image and running with that using Docker for Windows:

java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.
jenkinsfile.runner.FileSystemSCM for security reasons; see https:
//jenkins.io/redirect/class-filter/
java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.
jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https:
//jenkins.io/redirect/class-filter/

I'd like to try out the Jenkinsfile Runner which looks like a great idea 
but I don't have time to figure this out right now (busy writing a 
plugin..).

--Bill


On Tuesday, 6 March 2018 09:22:53 UTC, Michael Neale wrote:
>
> Trying this out, looks like I am hitting JEP-200: 
>
> https://jenkins.io/redirect/class-filter/
>
> Need to dig in further (I thought I tried the same version of Jenkins as 
> you). Anyone else seen this? 
>
>
>
> java.lang.UnsupportedOperationException: Refusing to marshal 
> io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; 
> see https://jenkins.io/redirect/class-filter/
> at 
> hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
> at 
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at 
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at 
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
> at 
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
> at 
> com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
> at 
> com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
> at 
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at 
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at 
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
> at 
> hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
> at 
> hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
> Caused: java.lang.RuntimeException: Failed to serialize 
> hudson.model.Actionable#actions for class 
> org.jenkinsci.plugins.workflow.job.WorkflowRun
>
>
> On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
>>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution 
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some 
>> Jenkins users and I felt something like this might move the needle for them 
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be 
>> important for you, does it miss any key points for you? If you mentally 
>> picture a perfect version of this, what would that do, and how would you 
>> use?
>>
>> Let me know!
>>
>> -- 
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/da0e3018-9206-43a3-b814-4a65a73d5c17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Update Fitnesse plugin to be compatible with Pipeline

[Jeff Wilson]

Is anyone working on updating the Fitnesse plugin 
 to be pipeline compatible?

If not, is there a guide for doing such a refactor?

-- 
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/30f957e8-e54d-404f-bcdc-5e5648012727%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Jesse Glick]

On Tue, Mar 6, 2018 at 4:22 AM, Michael Neale  wrote:
> java.lang.UnsupportedOperationException: Refusing to marshal 
> io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; 
> see https://jenkins.io/redirect/class-filter/

As suggested in that link, the JAR probably just needs a
`Jenkins-ClassFilter-Whitelisted: true` manifest header.

-- 
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/CANfRfr2dw%3DKoXwWyu-tYubOgN8YBg6dCZzNSsCnHFhcuyTkprA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC: Code Coverage API Plugin

[Jeff Knurek]

Hi Sugirjan,

I would recommend taking a look at some of the current existing bugs for 
the Cobertura plugin: 
https://issues.jenkins-ci.org/browse/JENKINS-31353?jql=component%20%3D%20%27cobertura-plugin%27%20and%20status%20%3D%20Open%20
 
and see which ones look easy to fix. From there we can work together to 
help define a Project Proposal on this topic.

There will be office hours on Wednesdays for when this email channel isn't 
helpful enough: https://jenkins.io/projects/gsoc/#office-hours

Thank you,
Jeff K

On Monday, March 5, 2018 at 2:45:49 PM UTC+1, sugir...@cse.mrt.ac.lk wrote:
>
> Hi,
>
> I'm Sugirjan, final year undergraduate student from Computer Science and 
> Engineering Department, University of Moratuwa, Sri Lanka. I wish to 
> contribute to this 'Code Coverage API Plugin' project. Can you give some 
> guidelines for starting to work on this project?
>
> Thank you.
>
> Regards,
> R. Sugirjan
> *CSE,*
> *University Of Moratuwa.*
> *linkedIn: https://www.linkedin.com/in/sugirjan/ 
> *
>
>
>
>

-- 
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/c3a14496-6f6b-4b85-9e27-959c64a2e3d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[Bill Dennis]

Thanks Kohsuke, I tried to give some answers to your questions inline 
below, if I didn't mess up the reply..

Bill

On Friday, 2 March 2018 17:57:24 UTC, Kohsuke Kawaguchi wrote:
>
>
>
> On Fri, Mar 2, 2018 at 9:26 AM Bill Dennis  > wrote:
>
>> Hello Kohsuke -
>>
>> I am a developer using Jenkins pipeline quite lot where I work.
>>
>> We are using Jenkins pipelines in two scenarios:
>>
>>- For CI building and testing some of our internal components (what 
>>Jenkins is traditionally used for)
>>- For running / orchestrating complex automation processes (so 
>>Jenkins is talking to some external systems using SOAP / REST etc) via 
>>tooling and even directly via REST using plugins.
>>
>> I have mostly used JenkinsPipelineUnit for testing / validation of the 
>> pipelines and I have been looking into the direct / live approach that Oleg 
>> demonstrated (running Jenkins locally in Docker and getting the pipeline 
>> being developed direct from a host file system volume mount).
>>
>> I think Jenkinsfile Runner would be really useful for developers who 
>> don't need or want the overhead of developing tests with 
>> JenkinsPipelineUnit. I have worked with some developers wanting to develop 
>> Jenkinsfiles for their CI process and the main problem is knowing if the 
>> Jenkinsfile will work when they commit it to the repo. They go round this 
>> loop of commit / fix running in the production Jenkins or using the Jenkins 
>> pipeline "replay" feature. It can be a painful process if you are not 
>> familiar with Jenkins pipeline and Groovy syntax!
>>
>
> This kind of context is really helpful. Thank you!
>
 
Happy to feedback. Thanks for Jenkins and pipeline as code, it helped me 
deliver some projects with Jenkins in a way that I thought would not be 
possible a few years ago.


> I think some things to consider are:
>>
>> - How does the Jenkins Runner replicate the agents / slaves identifiers 
>> on the target Jenkins?
>> - How to deal with tooling on the target Jenkins (custom tools, JDKs, 
>> Gradle, etc)?
>>
>
> Right, I guess your point is that Jenkinsfile Runner should aim to run 
> Jenkinsfile in much more realistic setup, and that doesn't stop at using 
> real Jenkins and real Pipeline plugins, but it also needs to include other 
> configurations of Jenkins. I think Jesse made a similar observation. I have 
> a few thoughts:
>
>- Configuration-as-code 
> could play 
>a role here in terms of letting people define the configuration of Jenkins 
>once and use it both in production and in setup like Jenkinsfile Runner
>- I'm a fan of making Jenkinsfile itself more portable. For example, 
>if people are already in the mode of using docker images to run builds in, 
>then more of the toolings would be packaged in there, and it should allow 
>Jenkinsfile Runner to run your project in much the same way as your 
>production Jenkins. I'm curious how much of this is already reality vs 
>ideal that people are working toward.
>
> Yes, all of this. I have often thought that we need something like 
declarative pipeline for the configuration of Jenkins as code instead of 
going into all those web config pages. Jenkins master as Docker container 
seems good. In our environment we are not currently using Docker but I have 
seen that that is the way to go. Getting a larger organisation to adopt the 
right technology and the associated costs of that is the challenge, so we 
remain using traditional Jenkins slaves and tooling methods. Hopefully 
Dockerised soon. We do use Jenkins Enterprise from CloudBees.


> I think the perfect Jenkinsfile Runner for me would provide:
>>
>> - Somehow capture the plugins, tooling and agents on our production 
>> Jenkins
>> - Validate the Jenkinsfile pipeline syntax
>>
>
> I think this is already happening as a result of actually running the 
> pipeline -- one of the virtue of actually using the real pipeline plugins 
> to run!
>  
>
>> - Validate the Jenkinsfile against the plugins and agents / tooling (fail 
>> if it refers to some tool or agent not configured for example).
>> - Run the Jenkinfile in some sort of "no-op" mode : what would it do if I 
>> ran it, without actually doing anything
>>
>
> This one is interesting. I assumed JenkinsPipelineUnit does this pretty 
> well, though. Can you tell me more about this? I'm imagining you'd want to 
> be able to selectively mock out some steps (e.g., when Jenkinsfile gets to 
> sh "./deploy.sh" don't actually do it and pretend that it succeeded) but 
> more details would be helpful.
>

Yes, in JenkinsPipelineUnit I pretty much mock out everything like calls to 
tools. Because pipeline is based on Groovy I thought I could do some unit 
tests using Spock and Groovy for pipelines but then I discovered it was 
already done and shared as JenkinsPipelineUnit, so hat tip to Ozan there. 
So the Spock unit tests 

Re: hello & improving Jenkins & Kubernetes CI / CD

[Nigel Magnay]

I'd be interested - we rolled our own twine after briefly experimenting
with terraform, so I build a groovy/DSL based equivalent that's
work-in-progress but more programmable..



On Thu, Mar 1, 2018 at 1:50 PM, James Strachan 
wrote:

> Hello folks!
>
> I’m James Strachan. I’m a long time Jenkins user and OSS developer. (e.g.
> I created Groovy, Apache Camel, dom4j, jaxen etc  Though I’m going to keep
> quiet about Jelly... ;). I’ve worked on a few Jenkins plugins over the
> years but never much on the core of Jenkins.
>
> So I’ve been working with Jenkins on Kubernetes for about 3-4 years now; I
> was one of the folks behind fabric8 at Red Hat & helped bring Jenkins to
> OpenShift.
>
> I’ve recently joined CloudBees and have been thinking & experimenting with
> how to make Jenkins more awesome as a tool for CI / CD platform on
> Kubernetes.
>
> I’ve started working on a JEP to bring those experiments to this list. But
> until its a bit more fleshed out, I wonder if anyone fancies an off list
> heads up on what I’m thinking? I’d love some early feedback to before I try
> to bring my thoughts to this list.
>
> Many thanks in advance & see you soon :)
>
> --
> James
> ---
> Twitter: @jstrachan
> Email: james.strac...@gmail.com
> Blog: https://medium.com/@jstrachan/
>
> --
> 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/CALTd4v-mHefu81g%3D6T3m_7vFPb8%2BTR3-
> vGF-EfOGKpj8cHYs9Q%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/CAPYP83Ru2v7_ABDD7Jcrf97RsS0T752tp9WED65RqShgB%2B%3DcnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.