[GSOC 2018] EDA Plugin : Developing a Jenkins Plugin for one of the EDA tools viz FuseSOC

[Lakhan Shiva]

Hi, 

My name is Lakhan Shiva Kamireddy. I am a second year graduate student at 
University of Colorado Boulder. I am interested in developing a Jenkins 
Plugin for one of the EDA tools viz,
FuseSOC, Yosys, icetools, ArachnePnr, etc. It will help to report FPGA 
resource utilization per build, etc. 

I am a user of Jenkins CI build platform while i was a backend web 
application developer for a multinational consulting corporation (Deloitte 
Consulting).

Last year summer, I was an intern at Google, Sunnyvale office in 
Califronia,as a Hardware Engineering intern and developed a Formal 
Verification library (SystemVerilog and Perl)
which falls under RTL design and Verification domain. I think this would be 
a great project and would like to come up with a proposal for this. I would 
like to get as much details as possible 
for this project and also its potential to get accepted as a GSOC 2018 
project for Jenkins.

I have pursued some graduate level courses like Logic Synthesis and 
Optimization, Computer Aided Verification(Formal Verification) at the 
University of Colorado Boulder in the past years. 

Kindly contact me, to fuel this project as a potential GSOC 2018 candidate.

Thanks and Kind Regards, 
Lakhan Shiva Kamireddy

-- 
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/f3b9abf1-c183-4b06-abd0-cc5e7da7ac2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GSOC] EDA plugin : Jenkins plugin for EDA tool FuseSOC

[Lakhan Shiva]

 Hi,

My name is Lakhan Shiva Kamireddy. I am a second year graduate student at
University of Colorado Boulder. I am interested in developing a Jenkins
Plugin for one of the EDA tools viz,
FuseSOC, Yosys, icetools, ArachnePnr, etc. It will help to report FPGA
resource utilization per build, etc.

I am a user of Jenkins CI build platform while i was a backend web
application developer for a multinational consulting corporation (Deloitte
Consulting).

Last year summer, I was an intern at Google, Sunnyvale office in
Califronia,as a Hardware Engineering intern and developed a Formal
Verification library (SystemVerilog and Perl)
which falls under RTL design and Verification domain. I think this would be
a great project and would like to come up with a proposal for this. I would
like to get as much details as possible
for this project and also its potential to get accepted as a GSOC 2018
project for Jenkins.

I have pursued some graduate level courses like Logic Synthesis and
Optimization, Computer Aided Verification(Formal Verification) at the
University of Colorado Boulder in the past years.

Kindly contact me, to fuel this project as a potential GSOC 2018 candidate.

Thanks and Kind Regards,
Lakhan Shiva Kamireddy

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

[GSOC 2018] EDA Plugin: Create Jenkins plugin for one of the EDA tools viz Yosys

[Lakhan Shiva]

Hi, 

My name is Lakhan Shiva Kamireddy. I am a second year masters student at 
the University of Colorado Boulder. I am interested in getting busy this 
summer doing some
plugin coding help for Jenkins. I am aware of Jenkins CI build system as a 
part of my work as a backend web application developer. Last year summer, i 
was an
intern at the Google, Sunnyale office in California as a Hardware 
Engineering Intern working on the Formal Verification libraries 
(SystemVerilog and Perl), an RTL design and verification project. I am 
interested in developing a Jenkins plugin for one of EDA tools viz, Yosys, 
FuseSOC, 
ArachnePnr or icetools. 

I am trying to get the EDA tools up on my system. I am well looking forward 
to this as I am interested in the EDA domain, done a couple of graduate 
level courses viz, Logic Synthesis and 
Optimization, Computer Aided Verification (Formal Verification). 

Kindly let me know more details about this draft and could this be proposed 
as a project for GSOC 2018. 

Thanks and Kind Regards, 
Lakhan Shiva Kamireddy

-- 
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/555cd5a8-af2a-4dbb-95c6-c9d7489fbb0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[martinda]

Hello Abhishek,

Thanks for your interest in the Jenkins GSoC projects.

> But then for every pull request administrator of the project needs to create 
> a job and then trigger a build. I think this will be cumbersome.

Yes that is a model that I have seen. But there there is another model which is 
to have a job that handles all the pull requests of a git repo to a given 
branch. For example say there is a git repository called jupiter/juno.git 
(jupiter is the name of the github org or of the bitbucket project). Then the 
pull requests destined to the master branch of the juno git repository could 
have a correspondig job called jupiter/juno/master. There could be other models 
too.

> pull request payloads have all of the above things, so we can extract them 
> from the pull request payload itself.

I did not know this. How do the PR coordinates (source and destination branches 
and repositories) get into the variables of a build if they are not input 
parameters? Does this require the installation of plugins in other systems?

I would suggest that you consider preparing an application with your ideas and 
suggestions in a google doc document.

Best Regards,
Martin d'Anjou

-- 
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/ec0a2c5e-aa1b-4fd9-9ef2-8c06a8142267%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2018] UPDATE for CODE Coverage API Plugin

[Ullrich Hafner]

Your approach sounds very reasonable. The same approach is used by the xunit 
plugin (converts different test results to JUnit format) and a similar but 
slightly different approach is used by the warnings plugin (converts different 
warning logs to an object model). I think that both of these approaches make 
sense. With the former one you can reuse the UI completely from the target 
format. The disadvantage is that there might be some information loss when 
converting to another format (there is coverage data *and* source code if I 
remember correctly: everything must be supported by the target). With the 
latter approach you can define the model on your own. However, you need to 
write the UI again (or adapt one of the other ones). So I think the simpler 
solution would be your suggested approach. Here you need to carefully select 
which of the tools (and which Jenkins plugin) should be the target.

> Am 15.03.2018 um 08:41 schrieb Rajgure Abhishek Sanjay Abhishek Sanjay 
> :
> 
>   
>Various plugins  are available  which currently implement code 
> coverage (jacoco,
> EclEmma,clover plugin, cobertura plugin, clover php plugin, etc), Instead of 
> having one plugin for each code coverage
> 
> result it would be best if we could merge them all into one plugin which will 
> handle code coverage.
> 
> 
> my approach
> develope intermediate converters for each code coverage reporting tool which 
> will convert its result into one format
> develope a jenkins plugin which is collection of this converters as well as 
> it has functionality of showing combined result
> 
> In Past week i was able to convert jacoco results into cobertura result,
> and converted jacoco files are recognized by cobertura plugin of jenkins so i 
> was able to see combined result of previous cobertura result in addition to 
> this converted result
> 
> 
> --
> 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/cdf3a75a-3a0a-44b1-aa37-b24c64161350%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/EBC5B89B-1703-4FBB-B5B7-304C64F22731%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: first draft of a new JEP: Jenkins X: Jenkins for Kubernetes CD

[Michael Neale]

Nice description!

Given the disparate timezones of everyone involved, would it make sense to 
have a few office hour type things? (not sure if there is enough interest 
in APAC timezone, if there is, let me know.

On Thursday, March 15, 2018 at 1:32:48 PM UTC+11, Kohsuke Kawaguchi wrote:
>
> Thanks James,
>
> This is an important and exciting JEP for me, because it sets the mission 
> & scope for a new project “Jenkins X.”
> Starting from Jenkins 2, in contributor events and Jenkins Worlds, I’ve 
> always pitched that our Jenkins project needs to take a bigger role and 
> responsibility in serving our users and solving their challenges. 
> Historically, by and large we did it by writing plugins, but we’ve been so 
> successful in doing that, now we need to create solutions that combine 
> those plugins.
>
>
>
>

-- 
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/d5b2101c-6d5d-47e5-8848-115728369ed5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to make jobs inherit folder properties

[Miguelangel Fernandez]

Thanks Jesse,

Great stuff as always. I see your point. I'll try the
EnvironmentContributor.

And thank you for the link to the docs. I somehow missed this.

On 14 Mar 2018 3:59 pm, "Jesse Glick"  wrote:

> Oh and of course read the docs!
>
> https://jenkins.io/doc/developer/plugin-development/pipeline-integration/
>
> --
> 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/fyZzwMbaUc4/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/CANfRfr3iB9ffNocc8LGoVMSP%3D0ykA6y77yEbBU8MTTtbRFdGxw%
> 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/CAK2td27jLZD5Fg5WPY3HKwXmEYNAoVZFLLG%3DNzHUz6rNro2uBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Even:Jenkins World 2018] CFP Update

[Alyssa Tong]

Hello,

A few updates to Jenkins World 2018:

   - Jenkins World SF CFP
    has been extended
   to April 1, 2018
   - Jenkins World EU CFP
    has been extended
   to April 15, 2018
   - Jenkins World EU  will be
   located in Nice, France on October 22-25, 2018

The CFP webpage  will
be updated (soon) with this new information.

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/msgid/jenkinsci-dev/CAC9wNazYpXJa%2BED-1i11vOTMSB3_cj%2B5t3npKktoq97cyGBFTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Using non default locations for builds and workspaces (was: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome)

[James Nord]

Where are logs stored (temporarily for the main log as I assume (wrongly) 
some logstash pump type service)?

Both access logs (these should be configured OOTB but are not as of today), 
and Jenkins logs, and any custom logs (currently $JENKINS_HOME/logs/?

I do not think these should be "lost" if you roll back - as you loose 
information about what happened between the upgrade and the rollback - 
which could be very important as you really want to know why it got rolled 
back...

/James

On Thursday, March 15, 2018 at 2:48:36 PM UTC, Baptiste Mathus wrote:
>
> Hey everyone, 
>
> I thought I'd start a dedicated email here about that part after some 
> feedback I got in https://github.com/batmat/jep/pull/1.
> I know people are very busy so maybe an email is easier for many than 
> looking at the PR.
>
> So the one the ideas I have for Essentials' data snapshotting system is to 
> use the configuration parameters to put builds and workspaces under a 
> single and non default root 
> 
> . 
>
> Concretely, with this setting, (simplified) we'd have under *JENKINS_HOME* 
> (instead of everything under *jobs* as it is usually):
> var/
> └── the_job
> ├── builds
> │   ├── 1
> │   │   ├── build.xml
> │   │   ├── changelog.xml
> │   │   └── log
> └── workspace
> jobs/
> └── the_job
> ├── config.xml
>
> Jesse  and 
> James  are 
> even saying we should move the var directory somewhere else *not* under 
> JENKINS_HOME.
> Also, saying that we should not even (try to) put the builds (and 
> workspace I assume) in the Git repository, since it is not scalable.
>
> I'm in mind to adjust the JEP with that proposal, though it somehow 
> conflicts with that statement in the JEP-301 that "all mutable state and 
> data will be written and stored in JENKINS_HOME 
> ".
>
> Any opinion about this?
>
> Any good or bad experience using those parameters to move build records 
> and/or workspaces somewhere else on the disk?
>
> Thanks!
>
> 2018-03-14 18:55 GMT+01:00 R. Tyler Croy  >:
>
>> (replies inline)
>>
>> On Wed, 14 Mar 2018, Baptiste Mathus wrote:
>>
>> > Hello everyone,
>> >
>> > For Jenkins Essentials
>> > , one critical
>> > requirement is to be able to upgrade, and hence rollback in an automated
>> > manner.
>> > So, as we are committed to an open design
>> >  process, I 
>> have
>> > written a first draft of the associated Jenkins Enhancement Proposal.
>> >
>> > It is up for review at https://github.com/batmat/jep/pull/1
>> >
>> > I am very eager for any kind of feedback there.
>> > I am especially interested in catching & clarifying (more or less) 
>> glaring
>> > holes in that design.
>>
>>
>> Thanks for taking the time to send this out Ba(p)tiste! Now that I've had 
>> a
>> chance to take a look, I think the one thing that's missing from this 
>> document
>> is a bit more explanation of the problem which requires this solution.
>>
>> My take on this problem space is that core and plugin upgrades can result 
>> in
>> modification of config.xml and other object-serialized-files on disk when 
>> an
>> upgrade occurs. As these files are serialized from objects in memory, 
>> when an
>> internal API changes within a plugin/core, it will necessarily result in
>> changes to files on disk. These changes may not be safe to "rollback" 
>> from,
>> i.e. Plugin A v0 cannot load a file generated by Plugin A v1.
>>
>> This means an upgrade of Jenkins Essentials has a very real potential to 
>> cause
>> irreversible modifications to files on disk which prevent a safe rollback.
>>
>>
>> So that type background/context is (IMHO) missing a bit from the JEP 
>> document.
>>
>> I think the Motivation section should also explain a bit more explicitly 
>> that
>> "bricking" a Jenkins Essentials instance is a severe failure for the 
>> project,
>> and thus we need to prevent against irreversible modifications to files 
>> causing
>> runtime failures for the Jenkins Essentials installation.
>>
>>
>> Overall, I think this looks quite reasonable. I look forward to seeing the
>> implementation and tests we get to write to support it :)
>>
>>
>> Cheers
>> - R. Tyler Croy
>>
>> --
>>  Code: 
>>   Chatter: 
>>  xmpp: rty...@jabber.org 
>>
>>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
>> --
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> 

Re: [Essentials] Using non default locations for builds and workspaces (was: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome)

[R. Tyler Croy]

(replies inline)

On Thu, 15 Mar 2018, Baptiste Mathus wrote:

> I thought I'd start a dedicated email here about that part after some
> feedback I got in https://github.com/batmat/jep/pull/1.
> I know people are very busy so maybe an email is easier for many than
> looking at the PR.


Thank you for bringing this discussion back to the jenkinsci-dev@ mailing list,
I think this will give more people to an opportunity to weigh in and
consolidate our discussions into threads for easy linking in the JEP
"References" section.

More below..

> So the one the ideas I have for Essentials' data snapshotting system is to
> use the configuration parameters to put builds and workspaces under a
> single and non default root
> 
> .
> 
> Concretely, with this setting, (simplified) we'd have under *JENKINS_HOME*
> (instead of everything under *jobs* as it is usually):
> var/
> ? the_job
> ? builds
> ???   ? 1
> ???   ???   ? build.xml
> ???   ???   ? changelog.xml
> ???   ???   ? log
> ? workspace
> jobs/
> ? the_job
> ? config.xml
> 
> Jesse  and James
>  are even
> saying we should move the var directory somewhere else *not* under
> JENKINS_HOME.


I cannot say I have ever intentionally moved /jobs/ around in this manner, I
assume that it "just works" and there's no quality concerns we should have from
a non-standard placement of data on disk?

Otherwise I have no problems with this.


> Also, saying that we should not even (try to) put the builds (and workspace
> I assume) in the Git repository, since it is not scalable.


>From my understanding of the potential failure scenarios with a plugin or core
upgrade is that unreadable build.xmls won't present a problem, or be mutated by
a new plugin update, correct?

If that's the case then I don't see a problem with leaving them out of the
snapshotting system. Generally speaking, I believe we should be mostly tracking
data which will be mutated on upgrade, or other potentially high importance
data.


> I'm in mind to adjust the JEP with that proposal, though it somehow
> conflicts with that statement in the JEP-301 that "all mutable state and
> data will be written and stored in JENKINS_HOME
> ".


When I wrote `JENKINS_HOME` I was actually just using that as a short-hand for
what is commonly understood as `/var/lib/jenkins` to most people. Basically,
mutable state should not be scattered around inside the container's temporary
filesystem, but rather contained in the single mounted volume, e.g.:

docker run -v /srv/jenkins:/var/jenkins_home jenkins/evergreen


So long as we're mounting everything through a single volume mount for the
container, my concerns/requirements for JEP-301 are met. Does that make sense
to you Ba(p)tiste?


Cheers
- R. Tyler Croy

--
 Code: 
  Chatter: 
 xmpp: rty...@jabber.org

  % 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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/20180315162720.ce7bbd67l2lu6yaz%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[Oleg Nenashev]

Hi all,

Just heads-up before the incoming call.
I have created a new filter, which captures more Remoting-related 
newbie-friendly issues in JIRA different components: 
https://issues.jenkins-ci.org/issues/?filter=18242

Best regards,
Oleg

On Tuesday, March 13, 2018 at 12:05:57 PM UTC+1, Oleg Nenashev wrote:
>
> Hi all,
>
> I have scheduled the meeting to Thursday, 4PM-5PM UTC.
> If you are a member of 
> https://groups.google.com/forum/#!forum/jenkinsci-gsoc-all-public , you 
> should have received an invitation. If no, please join this mailing list 
> and ping me.
>
> BR, Oleg
>
>
>
> On Mon, Mar 12, 2018 at 12:28 AM, Oleg Nenashev  
> wrote:
>
>> 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 

Re: Valgrind plugin maintainer out of action

[nils]

Hi Oleg,

Thank you for the procedural information. Yes, things started shaping up 
now, thank you Johannes if you are reading this.

Cheers,
Nils

On Tuesday, 6 March 2018 20:09:29 UTC, Oleg Nenashev wrote:
>
> 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/098f7c8d-d3c7-46ac-967c-973dbb745425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Essentials] Using non default locations for builds and workspaces (was: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome)

[Baptiste Mathus]

Hey everyone,

I thought I'd start a dedicated email here about that part after some
feedback I got in https://github.com/batmat/jep/pull/1.
I know people are very busy so maybe an email is easier for many than
looking at the PR.

So the one the ideas I have for Essentials' data snapshotting system is to
use the configuration parameters to put builds and workspaces under a
single and non default root

.

Concretely, with this setting, (simplified) we'd have under *JENKINS_HOME*
(instead of everything under *jobs* as it is usually):
var/
└── the_job
├── builds
│   ├── 1
│   │   ├── build.xml
│   │   ├── changelog.xml
│   │   └── log
└── workspace
jobs/
└── the_job
├── config.xml

Jesse  and James
 are even
saying we should move the var directory somewhere else *not* under
JENKINS_HOME.
Also, saying that we should not even (try to) put the builds (and workspace
I assume) in the Git repository, since it is not scalable.

I'm in mind to adjust the JEP with that proposal, though it somehow
conflicts with that statement in the JEP-301 that "all mutable state and
data will be written and stored in JENKINS_HOME
".

Any opinion about this?

Any good or bad experience using those parameters to move build records
and/or workspaces somewhere else on the disk?

Thanks!

2018-03-14 18:55 GMT+01:00 R. Tyler Croy :

> (replies inline)
>
> On Wed, 14 Mar 2018, Baptiste Mathus wrote:
>
> > Hello everyone,
> >
> > For Jenkins Essentials
> > , one critical
> > requirement is to be able to upgrade, and hence rollback in an automated
> > manner.
> > So, as we are committed to an open design
> >  process, I have
> > written a first draft of the associated Jenkins Enhancement Proposal.
> >
> > It is up for review at https://github.com/batmat/jep/pull/1
> >
> > I am very eager for any kind of feedback there.
> > I am especially interested in catching & clarifying (more or less)
> glaring
> > holes in that design.
>
>
> Thanks for taking the time to send this out Ba(p)tiste! Now that I've had a
> chance to take a look, I think the one thing that's missing from this
> document
> is a bit more explanation of the problem which requires this solution.
>
> My take on this problem space is that core and plugin upgrades can result
> in
> modification of config.xml and other object-serialized-files on disk when
> an
> upgrade occurs. As these files are serialized from objects in memory, when
> an
> internal API changes within a plugin/core, it will necessarily result in
> changes to files on disk. These changes may not be safe to "rollback" from,
> i.e. Plugin A v0 cannot load a file generated by Plugin A v1.
>
> This means an upgrade of Jenkins Essentials has a very real potential to
> cause
> irreversible modifications to files on disk which prevent a safe rollback.
>
>
> So that type background/context is (IMHO) missing a bit from the JEP
> document.
>
> I think the Motivation section should also explain a bit more explicitly
> that
> "bricking" a Jenkins Essentials instance is a severe failure for the
> project,
> and thus we need to prevent against irreversible modifications to files
> causing
> runtime failures for the Jenkins Essentials installation.
>
>
> Overall, I think this looks quite reasonable. I look forward to seeing the
> implementation and tests we get to write to support it :)
>
>
> Cheers
> - R. Tyler Croy
>
> --
>  Code: 
>   Chatter: 
>  xmpp: rty...@jabber.org
>
>   % 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/20180314175527.yeofyld6a2d2p4ro%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 

[GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[Abhishek Gautam]

Hello Everyone,


I am a 3rd-year Computer Science student from India. I found GSOC project 
Simple Pull-Request Job Plugin very interesting and want to work on it. 


But I have some concerns.


1. In project description, it's been stated as following


"Specifically, this plugin does not create jobs and does not detect 
branches automatically. The users are responsible for creating the jobs 
they need. This type of jobs have to be triggered via the existing methods 
(e.g. an http post to the Jenkins REST API, or via the UI)."


But then for every pull request administrator of the project needs to 
create a job and then trigger a build. I think this will be cumbersome.


Please let me know if I am wrong.


2. In project description, it's been stated that the pull-request job types 
have these input parameters:


   - 
   
   PR Number
   - 
   
   From Repository URL
   - 
   
   From Branch
   - 
   
   Target Repository URL
   - 
   
   Target Branch
   

But I think this should not be the case. I have done some research on 
payload GitHub sends through webhooks, and I found that pull request 
payloads have all of the above things, so we can extract them from the pull 
request payload itself.


I have gone through the code of below two plugins and I think they are 
pretty simple.


https://github.com/jenkinsci/bitbucket-plugin/tree/master/src/main/java/com/cloudbees/jenkins/plugins

and

https://github.com/jenkinsci/generic-webhook-trigger-plugin


We just need to get input from YAML file and do things according to that.

There is a java lib available to parse YAML file: 
https://github.com/FasterXML/jackson-dataformats-text/tree/master/yaml

Tutorial for above lib: 
https://dzone.com/articles/read-yaml-in-java-with-jackson


Please let me know 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/59ad2795-397e-4aaa-847f-8204c4daa289%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2018] UPDATE for CODE Coverage API Plugin

[Rajgure Abhishek Sanjay Abhishek Sanjay]

i am waiting to show demo of my work ,such that i will get yours feedback 
and work according to that,
also i will be working  on  my proposal 

-- 
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/0c3fef5f-cd7e-4232-abbe-dd7103f59c41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2018] UPDATE for CODE Coverage API Plugin

[Rajgure Abhishek Sanjay Abhishek Sanjay]

 Various plugins  are available  which currently implement code 
coverage (jacoco,EclEmma,clover plugin, cobertura plugin, clover php 
plugin, etc), Instead of having one plugin for each code coverage result it 
would be best if we could merge them all into one plugin which will handle 
code coverage.
my approach

   1. develope intermediate converters for each code coverage reporting 
   tool which will convert its result into one format
   2. develope a jenkins plugin which is collection of this converters as 
   well as it has functionality of showing combined result
   
   In Past week i was able to convert jacoco results into cobertura result,
   and converted jacoco files are recognized by cobertura plugin of jenkins 
   so i was able to see combined result of previous cobertura result in 
   addition to this converted result

-- 
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/cdf3a75a-3a0a-44b1-aa37-b24c64161350%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: first draft of a new JEP: Jenkins X: Jenkins for Kubernetes CD

[James Strachan]

Thanks for those kind words Kohsuke. More inline...

On Thursday, March 15, 2018 at 2:32:48 AM UTC, Kohsuke Kawaguchi wrote:
>
> Thanks James,
>
> This is an important and exciting JEP for me, because it sets the mission 
> & scope for a new project “Jenkins X.”
> Starting from Jenkins 2, in contributor events and Jenkins Worlds, I’ve 
> always pitched that our Jenkins project needs to take a bigger role and 
> responsibility in serving our users and solving their challenges. 
> Historically, by and large we did it by writing plugins, but we’ve been so 
> successful in doing that, now we need to create solutions that combine 
> those plugins.
>
>
> I said “starting from Jenkins 2” because the default recommended set of 
> plugins, initial setup wizard to start Jenkins more securely, and so on was 
> the first step toward us doing more than writing plugins.
>
> Blue Ocean followed, in which we focused on important parts of Jenkins and 
> provided great UX for that. It decidedly blended together feature areas 
> that are internally provided by a whole bunch of different plugins, but 
> users see much less seam between them now.
>
> Jenkins Essentials, which Tyler posted in recent weeks, is one more step 
> forward. That project is aiming to take an even bigger responsibility in 
> keeping people’s Jenkins instances up and running, and further de-emphasize 
> individuality of plugins and emphasize the combined solution.
>
> I see Jenkins X very much on this same path. Jenkins X brings a different 
> aspect to building a solution — it focuses on a specific vertical area, a 
> Kubernetes application development, and really drastically simplify the 
> software development by bringing together Jenkins, a whole bunch of 
> plugins, the opinionated best practice of how you should use Kubernetes.
>
> Especially early in the days of Jenkins, this kind of integration was done 
> by heroic Jenkins admins and provided for the organizations they were 
> working in, but they were never really shared upstream in the community. So 
> we all had to re-invent that.
>
> Jenkins X is a significant step because it is trying to bring those 
> hard-earned integration work back into the community. It makes Jenkins 
> approachable and valuable to a whole new set of users who are not currently 
> using Jenkins.
>
> From that perspective, I hope more projects like this will follow, in 
> different domains of software development. This is a little bit like how 
> Eclipse has evolved from just a Java IDE to an umbrella of projects.
>
>
> On top of all that, the icing on the cake, or the main cake, depending on 
> who you are, is that Kubernetes application development is a very exciting 
> area of technology where there’s a lot of interest. I’m sure many of you 
> are already doing that or thinking about doing that, and so this project 
> should be useful to many folks.
>


For me, one of the most rewarding things about Open Source is being able to 
learn from others in the community whether via code, docs, demos, email, 
issues or chat. A lot of things have changed in our industry in the last 
few years around containers, Kubernetes, cloud, DevOps & CI/CD best 
practices. So I'm hoping that even if you are not yet ready to use 
Kubernetes in your day job or are not yet interested in automating your 
Continuous Delivery; that you'll at least consider taking a look at Jenkins 
X - if for no other reason than to help you learn more about all these new 
ideas, technologies and approaches. 

We'd love any feedback you might have. Pull Requests are always welcome too 
;)

 

> I know James has a lot of ideas of what he can do on Jenkins X, and I also 
> fundamentally believe that a lot of good ideas also come from outside. So 
> please help James and his team build a better software by participating in 
> the effort. If you don't feel like you don't have any specific point to 
> make, even just providing them an encouragement would help them feel good 
> to press forward in the current direction. That's an useful feedback on its 
> own.
>
> I hope we’ll see a very lively discussion.
>

Agreed. I'll try get a blog post together soon introducing Jenkins X to try 
answer the question of why I think folks might be interested in taking it 
for a spin...

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e0e744a1-b035-4a63-bee3-60ac9299a572%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch event listener for Github PR labels

[Steven F]

On Thursday, March 15, 2018 at 1:07:31 AM UTC, Michael Neale wrote:
>
> Hi Steven. 
>
> This seems to be a reasonably often asked for feature (I wasn't able to 
> find a ticket though, for multibranch/github multibranch specifically, 
> surely there is one?). 
>
> Are you thinking that ideally in your case the branches/PRs would not 
> appear at all until the label is applied? Would an alternative that makes 
> it show up as not built or similar do? (may be easier to do that...)
>

I didn't see a ticket either, but I think a PR label filter is mentioned as 
an example use case in one of the API implementation docs. Unlabeled PR 
jobs not appearing in Jenkins is the goal for me, and I actually have a 
filter written that works with polling/indexing. I could stop now and 
enable polling on the multibranch project but it'd be nice to keep polling 
to a minimum of course. Hopefully I'm just missing something simple to get 
the new event subscriber up and running.


On Wednesday, March 14, 2018 at 3:02:16 PM UTC, Jesse Glick wrote:
>
> On Wed, Mar 14, 2018 at 10:50 AM, Steven F  wrote: 
> > I'm not even sure how a successful result would play out, does it 
> trigger a repository indexing with the given Event? or do the new heads 
> just appear in the project? 
>
> Event subscribers should be able to add new heads immediately. The 
> whole point of having this complicated API is to be able to bypass a 
> full branch indexing run, which can be expensive. 
>
> As to the rest of your question, I am not sure. You read the docs right? 


I had overlooked the docs in scm-api and those helped me understand some of 
the concepts and narrow things down, thanks. I think the bit I'm not 
following now is more in the github branch source implementation. My 
SCMHeadEvent returns the PR and its branch (which is probably discarded by 
the set of filters), but I was unable to return a PullRequestSCMRevision 
for the PR head because its constructor is package private. Then, I 
couldn't tell if that was important because I couldn't trace where these 
returned heads are used in github branch source. I don't know if the 
resulting source fetch is scoped to these heads.

Sorry if this is all basic, my Java isn't that strong :)

-- 
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/37a82504-4092-4778-85c7-d95392d79791%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.