Re: SSH User Private key in DSL jenkins

[Oleg Nenashev]

Please ask in the user ML

On Wednesday, March 7, 2018 at 8:18:04 PM UTC+1, Ondřej Fuchs wrote:
>
> Hi,
> Could someone advise how to override Binding -> SSH User Private key (see 
> figure) to DSL (classic dsl job) for seed job
>
> thank you for any advice.
>

-- 
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/c31c63bd-f712-4f37-b879-e4e5e96c6073%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GSoC] 2018 Student Introduction

[Ibrahim Abdullah]

Hello,

My name is Ibrahim Abdullah, a final year student at Ashesi University 
College, Ghana. I am studying computer science and very interested in 
software development, distributed systems and Machine learning. Java is the 
main programming language I use for development and have little experience 
with Jenkins as well. 

I have always wanted to contribute to open source projects to improve my 
programming skills but find it difficult to start as a newbie. I believe 
Google Summer of Code will provide the platform and give me a head start to 
join the open source community. Additionally, I found some of the Jenkins 
projects exciting to work on given that I have a strong Java background and 
quite familiar with using Jenkins as a developer. I will like to work on 
any of the following projects: Jenkins Remoting over Message Bus/Queues, 
Code Coverage Plugin and Simple pull request Plugin.

The following are the links GutHub and LinkedIn profile;

GitHub : https://github.com/Ibrahim-Abdullah
LinkedIn : www.linkedin.com/in/ibabdullah
Twitter: https://twitter.com/braimahabdulla

-- 
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/8a514bb3-a4b6-4d81-82b0-319d7097d1e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoc 2018] [Student Introduction] Jenkins Remoting over Message Bus/Queue

[Oleg Nenashev]

Hi all,

Thanks to Pham for the proposal! Will try to review it tomorrow

Since we have several students interested in Remoting, I propose to setup a 
separate session to discuss it.
I have created a poll regarding suitable times here: 
https://doodle.com/poll/a93m25nzzaf29sya

Best regards,
Oleg


On Saturday, March 10, 2018 at 10:57:41 AM UTC+1, Pham Vu Tuan wrote:
>
> Hi,
>
> I put my draft proposal for GSoC here 
> https://docs.google.com/document/d/17vmPvDtMbHT7nTKRlGReFRgOtwVImhgsETLOGPW9Rso/edit?usp=sharing.
>  
> I would like to receive reviews and comments about my draft proposal before 
> the submission deadline.
>
> Thanks,
> Pham Vu Tuan
>
> On Friday, March 9, 2018 at 1:26:37 AM UTC+8, Oleg Nenashev wrote:
>>
>> You still have not exposed "-p" option as proposed above.
>> I kindly recommend to move this prototyping discussion to a separate 
>> thread so it does not pollute the project proposal discussion.
>>
>> Thanks in advance,
>> Oleg
>>
>> On Thu, Mar 8, 2018 at 6:22 PM, Pham Vu Tuan  wrote:
>>
>>> I resolved the JNLP warning message by passing env variable in Docker 
>>> run.
>>> But I still encountered "Connection refused" error although I exposed 
>>> the port 5 in the Dockerized master.
>>>
>>>
>>> 
>>>
>>>
>>> 
>>> My command to start the agent is: "docker run -e 
>>> JNLP_PROTOCOL_OPTS='-Dorg.jenkinsci.remoting.engine.JnlpProtocol3.disabled=false'
>>>  
>>> jenkins/jnlp-slave -url http://localhost:8080 abcd test-node".
>>> Any ideas on this?
>>>
>>> On Friday, March 9, 2018 at 12:13:56 AM UTC+8, Oleg Nenashev wrote:

 Hi Pham,

 In order to connect an agent to the Dockerized master, you need to 
 expose the port for the agent (make the Agent port fixed in security 
 settings + use "-p" option to expose it).
 I am not sure how BlueOcean image is configured, the standard Jenkins 
 Docker image has it documented here: 
 https://github.com/jenkinsci/docker#usage

 Hopefully it helps,
 Oleg

 P.S: I'd guess it's another case of WEBSITE-474 
 , right?



 On Thu, Mar 8, 2018 at 4:59 PM, Pham Vu Tuan  
 wrote:

> Hello,
>
> I am trying to setup the master and agent in my local machine. Server 
> setup is fine, I used https://hub.docker.com/r/jenkinsci/blueocean/. 
> But when I tried to connect an agent to it using 
> https://hub.docker.com/r/jenkins/jnlp-slave/ by this command "docker 
> run jenkins/jnlp-slave -url http://localhost:8080 abcd test-node" , I 
> encountered some problems:
>
> - Warning: JnlpProtocol3 is disabled by default, use 
> JNLP_PROTOCOL_OPTS to alter the behavior => Athough I set the env 
> variable 
> in the docker container for the server, I still encountered this warning 
> message, am I missing to set it somewhere?
> - Not sure if this is related to the above issue, then I cannot 
> connect the agent to server 
>
>> SEVERE: Failed to connect to 
>> http://localhost:8080/tcpSlaveAgentListener/: Connection refused 
>> (Connection refused)
>> java.io.IOException: Failed to connect to 
>> http://localhost:8080/tcpSlaveAgentListener/: Connection refused 
>> (Connection refused)
>> at 
>> org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:199)
>> at hudson.remoting.Engine.innerRun(Engine.java:518)
>> at hudson.remoting.Engine.run(Engine.java:469)
>
> Could someone help me with this setup issue?
>
> Regards,
> Pham Vu Tuan 
>
> On Monday, March 5, 2018 at 12:31:29 AM UTC+8, Oleg Nenashev wrote:
>>
>> Hi all,
>>
>> Since we have several students interested in this project, I propose 
>> to spend some time at office hours on Wednesday in order to discuss it.
>>
>> From what I see, everybody in this thread can attend during the 
>> APAC/Europe timeslot, right? If yes, let's just talk about the project 
>> there.
>>
>> BR, Oleg
>>
>> On Sunday, March 4, 2018 at 7:48:47 AM UTC+1, ajm...@g.rit.edu wrote:
>>>
>>> I am Amit Magar a graduate student pursuing masters in Computer 
>>> Science from Rochester Institute of Technology. I am specializing in 
>>> Computer Networks and Artificial Intelligence. I have 8 years formal 
>>> education in Computer Science.
>>>
>>>  I have 3 years of professional works experience at Accenture. 
>>> Currently, I am working at Genex Services, Pensylvania as Intern in 
>>> 

Re: POTD: Jenkinsfile Runner

[johannes]

>From a user perspective, I like your idea of a 
"pipeline.sharedlibrary.test" step and/or a "run-pipeline" CLI command. 
They would definitely solve configuration issues with plugins, docker, etc.
Now, Jesse mentioned some implementation challenges in his post from Wed, 
07 Mar 2018 13:04:46 
, 
that I can't comment on, because I'm not that deep into Jenkins internals 
(yet?).

In the meantime, Jesse also provided a workaround for loading a "local" 
shared lib . With this I 
implemented my first (very simple) integration test 

 
and run it successfully from the Jenkinsfile of the shared lib 

 


You meant asserts should already work? How would you do those in that 
scenario?

This approach has of course the limitations we talked about, regarding the 
Jenkins configuration .
In addition these tests would only be run on Jenkins and not when running 
the build locally with Maven.

So right now, I think a better approach would be to provide a Java library 
that allows for running Jenkinsfiles.
It could be used to implement e.g. JUnit tests that are run by build tools 
such as maven locally (e.g. with the failsafe plugin) and in the same way 
in the Jenkinsfile.
This library could abstract from the concrete execution with could either be
- Jenkinsfile runner with local plugin folder
- Jenkinsfile runner in Docker
- "pipeline.sharedlibrary.test" step
- a "run-pipeline" CLI command.

The downside would be that such an implementation wouldn't be trivial. And, 
unfortunately, I can't invest to much of my free time right now.

Am Dienstag, 6. März 2018 22:23:26 UTC+1 schrieb 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 
>>