Re: Pipeline with CVS

[Kevin Burnett]

Use the pipeline syntax generator that you can find in the left nav of your 
jenkins UI in any pipeline job. It's sweet. I will not take any cheap shots 
at CVS while I'm here.





On Tuesday, May 2, 2017 at 4:54:42 AM UTC-4, xto...@gmail.com wrote:
>
> Hi,
>
>
> I try to write pipeline to check out code from CVS. While there are many 
> example with git, I cannot find any example with CVS. I would very 
> appreciate if anyone can post some groovy examples here.
>
>
> Regards,
>
> David
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/4c4d5f60-6a61-42bb-841a-064d9a29d7cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multi branch source - PR versus branch build

[Kevin Burnett]

i'm actually totally with you on this.

i've been wanting to only build branches (and never build PRs) for a while 
now. in fact, we've gone so far as to "kill" PR builds manually in our 
shared library in order to not chew up resources needlessly:

if (env.BRANCH_NAME && env.BRANCH_NAME.contains('PR-')) {
  error("IntentionallyFailingPullRequestBuild")
}

our workaround is annoying since our pull requests obviously always show up 
as broken in bitbucket server. :|

i think https://issues.jenkins-ci.org/browse/JENKINS-43426 is related, and 
lots of new use-cases will be supported when this new UI is eventually 
rolled out (i hope our "ignore PRs completely" use case is supported, but 
i'm not 100% sure what's in scope).

On Monday, May 1, 2017 at 2:17:23 PM UTC-4, Dan Tran wrote:
>
>
> So I misunderstood the mechanism of PR build where the target branch is 
> not merged into the destination branch before build
>
> what is the benefit of auto build both merge and pr for every new commit? 
>  I can understand the benefit before issuing the PR, but from my experience 
> ppl usually issue PR very early to solicit feed back and there for we have 
> double builds
>
> Thanks
>
> -Dan
>
> On Monday, May 1, 2017 at 10:44:33 AM UTC-7, Kevin Burnett wrote:
>>
>> dan,
>>
>> i understand that you're using the bitbucket branch source plugin, you 
>> introduce a syntax error into the mainline branch (let's call it master), 
>> and you submit a pull request for a different branch (let's call it 
>> feature/new-hotness) that wasn't based off this bad master branch. your 
>> master build fails and your pull request build succeeds.
>>
>> that is what i'd expect, because it doesn't automatically merge the 
>> feature branch into master or master into the feature branch. where have i 
>> misunderstood?
>>
>>
>> On Sunday, April 30, 2017 at 5:26:44 PM UTC-4, Dan Tran wrote:
>>>
>>> Hi
>>>
>>> I am experimenting BitBucket multi branch source plugin I think PR build 
>>> is just same as branch build.
>>>
>>> Basically, i force a syntax failure  the main source, and create a pull 
>>> request from another branch.  
>>> I am expecting the PR build also fails as in main. But  it is  not.
>>>
>>> Am I missing something?
>>>
>>> Thanks
>>>
>>> 0Dan
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/728454ea-fca1-40d9-90b7-1a04e7415fe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: For Every build it showing below warning

[Stephen Connolly]

Somebody has configured a queue item authenticator and defined the default
to be "run as anonymous"

Probably intentional, so find out why they did it before turning it off
On Tue 2 May 2017 at 08:00, Sandeep Grandham 
wrote:

> Hi..
>
> While i am trying to build a project, for every build i am getting this
> warning message. loke
>
> Warning: this build has no associated authentication, so build permissions
> may be lacking, and downstream projects which cannot even be seen by an
> anonymous user will be silently skipped
> Finished: SUCCESS
>
> what is this meaning?
>
> Please help me to resolve this?
>
> Thanks,
> Sandeep
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/9cc7ce8d-ac44-4ad7-bb33-4d414fe80ac1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwHjLhHsUEWVMEUp9Ugr%2BHW8sF-oTPW8ukyo6DRcpg3nQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Load properties from a properties file and make it available anywhere in the pipeline

[ishan jain]

Hi all,

My requirement is simple, i just want to externalize some 'values' to make 
my Jenkinsfile more re usable and for this i need to* load the properties 
from a file which is going to be right next to Jenkinsfile, and make sure 
that these properties are available anywhere in the code*. I am still new 
to groovy and Jenkins code but never thought such a simple thing would be 
so difficult. I enabled some methods in script security plugin but the 
following code always pose error or print null. I have tried multiple 
combinations and the below code is just one of them

properties = null

@NonCPS
def loadProperties() {
checkout scm
File propertiesFile = new File('${workspace}/pipeline.properties')
propertiesFile.withInputStream {
properties.load(propertiesFile)
}
}

pipeline {
agent none
stages {

stage ('prepare') {
agent any
steps {
script {
loadProperties()
echo "${properties['repo']}"
}
}
}
stage('Build') {

agent any
steps {
sh 'echo ${properties.repo}'
}
}
}
}



-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/62422d08-9bad-4e97-8a9d-30c0879b8503%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Merge to Master not kicking Open PRs to also build

[Jeffrey]

@2.0.5 GHBS --- everything is patched to latest as of today. Still exhibits 
the incorrect behavior. Thanks for taking the time to read. 

On Tuesday, May 2, 2017 at 10:03:45 AM UTC-4, Stephen Connolly wrote:
>
> I think this is 
> https://github.com/jenkinsci/github-branch-source-plugin/pull/131 unless 
> you have upgraded to ghbs 2.0.5
>
> On 2 May 2017 at 11:57, Jeffrey > wrote:
>
>> Hey, Thanks for reading. 
>>
>> All PRs build -- and post back a status message to GIT delivering build 
>> success or failure right? 
>>
>> 2 PRs like before -- both build successfully and show "Clear to ship"
>>
>> PR1 Gets merged to Master (Which changes code that may or may not work on 
>> PR2 )
>>
>> Unless someone goes back and forces PR 2 to build again -- there is no 
>> test of the newly introduced code in master (from PR1) -- you can ship 
>> untested / breaking code. 
>>
>> Any time a merge occurs -- all PRs referencing that head should be forced 
>> to rebuild to ensure the merged version works right? 
>>
>> On Monday, May 1, 2017 at 5:59:06 PM UTC-4, Baptiste Mathus wrote:
>>>
>>> Must be missing something but failing to see why merging a PR should 
>>> retrigger the builds of others.
>>>
>>> Care to clarify?
>>>
>>> Thanks
>>>
>>> Le 1 mai 2017 10:43 PM, "Jeffrey"  a écrit :
>>>
 So -- Ive reverted Jenkins to 2.46.2 latest patches and the behavior is 
 the same.

 What I expect: 

1. Two open PRs
2. Merge one PR to master
3. Master auto builds
4. Repo is scanned and the other PR builds. This is still not 
happening. Any help much appreciated.


 On Friday, April 28, 2017 at 2:24:21 PM UTC-4, Jeffrey wrote:
>
> Good Afternoon Jenkins-Land
>
>  Running into a weird issue in version Jenkins 2.53 and 2.57 
> (Latest plugins). 
>
> Old Version: (I believe 2.45) (Git / SCM plugins previous to version 
> 2.0)
> Jenkins Multibranch Pipeline, Freestyle --> Jenkinsfile from ORG folder
> 1.   We have 5 open PRs. 
> 2.   We merge one of the PRs to master
> 3.   Master auto builds (webook)
> 4.   The remaining 4 PRs also build (merge with new master and build) 
>
> Weird issue: (Versions 2.53, and 2.57) (Git and SCM plugins now post 
> 2.0)
> 1.   We have 5 open PRs. 
> 2.   We merge one of the PRs to master
> 3.   Master auto builds (Webhook)
> 4.   Nothing happens to open PRs
> 5.   Re-scan of the ORG or the repository in Jenkins causes the PRs to 
> build. 
>
>
> Our configurations are stored on a central NFS mount and Jenkins 
> Master run in Docker. 
>
> Any help on where to look for the possible causes? 
>
 -- 
 You received this message because you are subscribed to the Google 
 Groups "Jenkins Users" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to jenkinsci-use...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-users/d6db8731-d016-4821-b806-ceb637049cac%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 Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/25570dc9-af90-47e7-8f1b-d263b418d294%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/75e243ca-0dff-4b7b-8747-1ea35385eb33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

null pointer exception

[Alex Dunwell nee Grässer]

After upgrading to Jenkins 2.46.2  I'm getting this
error.
Compiling on Java 8 112
Any idea on how to resolve this?


ERROR: Processing failed due to a bug in the code. Please report this
to jenkinsci-us...@googlegroups.comjava.lang.NullPointerException
:
Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)

at java.util.zip.Inflater.inflate(Inflater.java:257)

at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)

at java.io.FilterInputStream.read(FilterInputStream.java:107)

at java.util.Properties$LineReader.readLine(Properties.java:435)

at java.util.Properties.load0(Properties.java:353)

at java.util.Properties.load(Properties.java:341)

at 
hudson.maven.MavenEmbedderUtils.getMavenVersion(MavenEmbedderUtils.java:217)

at hudson.maven.MavenVersionCallable.call(MavenVersionCallable.java:69)

at hudson.maven.MavenVersionCallable.call(MavenVersionCallable.java:41)

at hudson.FilePath.act(FilePath.java:1083)

at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:642)

at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)

at hudson.model.Run.execute(Run.java:1728)

at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)

at hudson.model.ResourceController.execute(ResourceController.java:98)

at hudson.model.Executor.run(Executor.java:405)


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CANHX8XyK3ihd_d65F%2BPH%3Dp3YrY5iTta3pG%2BMFjXBcRgYadggCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Merge to Master not kicking Open PRs to also build

[Stephen Connolly]

I think this is
https://github.com/jenkinsci/github-branch-source-plugin/pull/131 unless
you have upgraded to ghbs 2.0.5

On 2 May 2017 at 11:57, Jeffrey  wrote:

> Hey, Thanks for reading.
>
> All PRs build -- and post back a status message to GIT delivering build
> success or failure right?
>
> 2 PRs like before -- both build successfully and show "Clear to ship"
>
> PR1 Gets merged to Master (Which changes code that may or may not work on
> PR2 )
>
> Unless someone goes back and forces PR 2 to build again -- there is no
> test of the newly introduced code in master (from PR1) -- you can ship
> untested / breaking code.
>
> Any time a merge occurs -- all PRs referencing that head should be forced
> to rebuild to ensure the merged version works right?
>
> On Monday, May 1, 2017 at 5:59:06 PM UTC-4, Baptiste Mathus wrote:
>>
>> Must be missing something but failing to see why merging a PR should
>> retrigger the builds of others.
>>
>> Care to clarify?
>>
>> Thanks
>>
>> Le 1 mai 2017 10:43 PM, "Jeffrey"  a écrit :
>>
>>> So -- Ive reverted Jenkins to 2.46.2 latest patches and the behavior is
>>> the same.
>>>
>>> What I expect:
>>>
>>>1. Two open PRs
>>>2. Merge one PR to master
>>>3. Master auto builds
>>>4. Repo is scanned and the other PR builds. This is still not
>>>happening. Any help much appreciated.
>>>
>>>
>>> On Friday, April 28, 2017 at 2:24:21 PM UTC-4, Jeffrey wrote:

 Good Afternoon Jenkins-Land

  Running into a weird issue in version Jenkins 2.53 and 2.57
 (Latest plugins).

 Old Version: (I believe 2.45) (Git / SCM plugins previous to version
 2.0)
 Jenkins Multibranch Pipeline, Freestyle --> Jenkinsfile from ORG folder
 1.   We have 5 open PRs.
 2.   We merge one of the PRs to master
 3.   Master auto builds (webook)
 4.   The remaining 4 PRs also build (merge with new master and build)

 Weird issue: (Versions 2.53, and 2.57) (Git and SCM plugins now post
 2.0)
 1.   We have 5 open PRs.
 2.   We merge one of the PRs to master
 3.   Master auto builds (Webhook)
 4.   Nothing happens to open PRs
 5.   Re-scan of the ORG or the repository in Jenkins causes the PRs to
 build.


 Our configurations are stored on a central NFS mount and Jenkins Master
 run in Docker.

 Any help on where to look for the possible causes?

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jenkinsci-users/d6db8731-d016-4821-b806-ceb637049cac%
>>> 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 Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/25570dc9-af90-47e7-8f1b-d263b418d294%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwf1BY3YefV0JROtOdVmaoqX9VZ9Wi%3DkrSCw9%3DvuzP4WQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fwd: null pointer exception

[Alex Dunwell nee Grässer]

After upgrading to Jenkins 2.46.2  I'm receiving
this error.
Any ideas on how to resolve this?


ERROR: Processing failed due to a bug in the code. Please report this
to jenkinsci-us...@googlegroups.comjava.lang.NullPointerException
:
Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)

at java.util.zip.Inflater.inflate(Inflater.java:257)

at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)

at java.io.FilterInputStream.read(FilterInputStream.java:107)

at java.util.Properties$LineReader.readLine(Properties.java:435)

at java.util.Properties.load0(Properties.java:353)

at java.util.Properties.load(Properties.java:341)

at 
hudson.maven.MavenEmbedderUtils.getMavenVersion(MavenEmbedderUtils.java:217)

at hudson.maven.MavenVersionCallable.call(MavenVersionCallable.java:69)

at hudson.maven.MavenVersionCallable.call(MavenVersionCallable.java:41)

at hudson.FilePath.act(FilePath.java:1083)

at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:642)

at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)

at hudson.model.Run.execute(Run.java:1728)

at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)

at hudson.model.ResourceController.execute(ResourceController.java:98)

at hudson.model.Executor.run(Executor.java:405)

project=hudson.maven.MavenModuleSet@384fde66[jmds-common]
project.getModules()=[hudson.maven.MavenModule@101dc635[jmds-common/za.co.mededi.jmds:jmds-common][jmds-common/za.co.mededi.jmds:jmds-common][relativePath:]]
project.getRootModule()=hudson.maven.MavenModule@101dc635[jmds-common/za.co.mededi.jmds:jmds-common][jmds-common/za.co.mededi.jmds:jmds-common][relativePath:]
FATAL: Inflater has been closedjava.lang.NullPointerException
:
Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)

at java.util.zip.Inflater.inflate(Inflater.java:257)

at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)

at java.io.FilterInputStream.read(FilterInputStream.java:107)

at java.util.Properties$LineReader.readLine(Properties.java:435)

at java.util.Properties.load0(Properties.java:353)

at java.util.Properties.load(Properties.java:341)

at 
hudson.maven.MavenEmbed

Re: svn error 'ISVNAuthentication provider did not provide credentials'

['Maciej Jaros' via Jenkins Users]

There is bug in Subversion Plugin. It seem that new versions of this 
plugin cannot handle svn:externals well.


See:
https://issues.jenkins-ci.org/browse/JENKINS-32167

David Aldrich (2017-04-11 14:52):


Hi

Since upgrading:

SCM API plugin from 1.3 to 2.1.1

Subversion Plugin 2.7.1 to 2.7.1

we are seeing the following exception occurring occasionally:

svn: E200015: ISVNAuthentication provider did not provide credentials; 
HTTP authorization cancelled.
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:195)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:46)
at 
org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
at 
org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at 
org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
at 
org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
at 
hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194)
Caused: hudson.util.IOException2: revision check failed on 
/GlobalRegs.tcl 

at 
hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208)
at 
hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138)

at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:496)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1280)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)

at hudson.model.Run.execute(Run.java:1733)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)

at hudson.model.Executor.run(Executor.java:405)

The credentials for the job are correct – they worked fine before the 
upgrade.


The exception occurs following a svn commit.  If I then run the job 
manually it succeeds.


Any advice please?

Best regards

David

--
You received this message because you are subscribed to the Google 
Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/9838a10cbeff41b982300a1aac1daf90%40EUX13SRV1.EU.NEC.COM 
.

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





--
You received this message because you are subscribed to the Google Groups "Jenkins 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/dffbc5dd-b58c-db9b-c8eb-1ca7a16bef7d%40mol.com.pl.
For more options, visit https://group

Delete Job, created by Multibranch-Pipeline with jobDsl, when Branch is deleted

[roberte88]

Hello Jenkins users,

 

I have a Multibrach-Pipeline on my Jenkins which creates a job per branch.

branch1,branch2,branch3

 

These jobs create jobs again via the jobdsl-plugin in Jenkinsfile:

def createJob(jobFile) {

def job = readFile (jobFile)

jobDsl scriptText: job 

}

 

with jobFile is something like:

 

pipelineJob("branch1-job1") {

    environmentVariables {

    [...]

    }

    throttleConcurrentBuilds {

    [...]

    }  

triggers {

    [...]

    }

    definition {

    cps {

script(readFileFromWorkspace('jenkins/jobPipelineDef.groovy'))

    sandbox()

    }

    }

}

 

Now my question: Is there a way to delete the pipelineJob(branch1-job1) if the job for branch1 is deleted by the Multibranch-Pipeline? Or do I have to manually determine the jobs and delete them via the jobDsl-plugin?

Platform: Jenkins ver. 2.46.2 with all plugins are up to date.

I have already asked the users at Stackoverflow, but unfortunately no answer received: http://stackoverflow.com/questions/43679852/jenkins-delete-job-created-by-multibranch-pipeline-with-jobdsl-when-branch- Is
 

Perhaps one of you can help me.

Thanks!

Robert

 





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/trinity-4bfb5bd5-deb8-4132-82b8-04b51ac1dc51-1493731441607%403capp-webde-bs10.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins slave node running debian 7 will not launch

[Mark Waite]

I think you've detected a bug (or likely multiple bugs).  I think they may
be due to the recent updates to the trilead ssh library in the weekly
build.  Thanks for detecting them!

Passing Test Configuration

I have a Docker configuration that running Jenkins 2.46.2 with "Manually
provided Key Verification Strategy".  That master uses ssh agents connected
to various physical machines for platform testing, including Debian 7,
Debian 8, Ubuntu 14, Ubuntu 16, CentOS 6, CentOS 7, Windows 7, and Windows
10.  Each of the Linux agents in that configuration includes the host key
in the agent configuration and connects successfully no matter where I run
that docker instance inside my network.

Failing Test Configuration

If I take that same configuration and replace Jenkins 2.46.2 with Jenkins
2.58, I see multiple failures.

   - None of the ssh agents connect at startup with Jenkins 2.58.  The log
   reports "WARNING: The SSH key for this host does not match the key required
   in the connection configuration" and reports "java.io.IOException: Key
   exchange was not finished, connection is closed" and reports "The server
   hostkey was not accepted by the verifier callback"
   - If I reconfigure each agent to switch from "Manually provided Key
   Verification Strategy" to "Non verifying Verification Strategy", then the
   Debian 8, Ubuntu 14, Ubuntu 16, CentOS 6, and CentOS 7 ssh based agents are
   able to connect.  The Debian 7 ssh based agent is not able to connect.  It
   reports "IOException: There was a problem while connecting to
   wheezy64b.markwaite.net:22" and "IOException: Key exchange was not
   finished, connection is closed" and "IOException: Cannot read full block,
   EOF reached".  Note, the "Cannot read full block" is a different failure
   message than the other platforms

I suspect the ssh implementation on Debian 7 is too old for the changes
that were made to the trilead ssh implementation recently.  That would
explain the failure you (and I) are seeing with Debian 7.  If that is
correct, then there may be nothing to be done about the issue, since Debian
7 is rapidly approaching its end of life.  The Debian project will likely
stop supporting Debian 7 as soon as they release Debian 9.  Your likely
best solution (for now) is to stay with Jenkins 2.46.2 long term support
release.

I can't explain why the "Manually provided Key Verification Strategy" no
longer works.

There was a surprising stack trace in the startup of my docker instance
using 2.58 which isn't there with 2.46.2.  It says:

May 02, 2017 6:26:03 AM
hudson.init.impl.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler
uncaughtException

SEVERE: A thread (Thread-30/307) died unexpectedly due to an uncaught
exception, this may leave your Jenkins in a bad way and is usually
indicative of a bug in the code.
java.lang.NullPointerException
at
com.trilead.ssh2.transport.KexManager.handleMessage(KexManager.java:447)
at
com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:790)
at
com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:502)
at java.lang.Thread.run(Thread.java:745)

That may have something to do with at least one of the failures.

Could you log a bug so that this can be tracked?  We want some time to
review the behavior before the base Jenkins version is chosen for the next
long term support release.

Mark Waite

On Tue, May 2, 2017 at 5:48 AM Richard Ginga 
wrote:

> depending on how you are starting the slave, there are ways to designate
> which version of Java to use different from any default java. for ssh
> connections, see the advanced button. for webstart, see the slave.xml file.
> (or something like that)
>
> On Tue, May 2, 2017 at 2:12 AM, Jaap de Jong  wrote:
>
>> Hi All!
>>
>> Since a recent update my slave jenkins node will not launch.
>> It is running debian 7 with oracle jre 1.8.0_131.
>> The master runs debian 8 with the same jvm.
>> Launching the slave fails on the first ssh connection the master tries to
>> make.
>> In the /var/log/jenkins/jenkins.log on the master:
>>
>> [05/01/17 08:09:14] SSH Launch of OpenEmbedded Buildserver on mySlave
>> failed in 4,899 ms
>> May 01, 2017 8:09:14 AM
>> hudson.remoting.SynchronousCommandTransport$ReaderThread run
>> SEVERE: I/O error in channel OpenEmbedded Buildserver
>> java.io.IOException: Unexpected termination of the channel
>> at
>> hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:73)
>> Caused by: java.io.EOFException
>> at
>> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2335)
>> at
>> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2804)
>> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:802)
>> at java.io.ObjectInputStream.(ObjectInputStream.java:299)
>> at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48)
>> at
>> hudson.remoting.Abstra

Re: jenkins slave node running debian 7 will not launch

[Richard Ginga]

depending on how you are starting the slave, there are ways to designate
which version of Java to use different from any default java. for ssh
connections, see the advanced button. for webstart, see the slave.xml file.
(or something like that)

On Tue, May 2, 2017 at 2:12 AM, Jaap de Jong  wrote:

> Hi All!
>
> Since a recent update my slave jenkins node will not launch.
> It is running debian 7 with oracle jre 1.8.0_131.
> The master runs debian 8 with the same jvm.
> Launching the slave fails on the first ssh connection the master tries to
> make.
> In the /var/log/jenkins/jenkins.log on the master:
>
> [05/01/17 08:09:14] SSH Launch of OpenEmbedded Buildserver on mySlave
> failed in 4,899 ms
> May 01, 2017 8:09:14 AM 
> hudson.remoting.SynchronousCommandTransport$ReaderThread
> run
> SEVERE: I/O error in channel OpenEmbedded Buildserver
> java.io.IOException: Unexpected termination of the channel
> at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(
> SynchronousCommandTransport.java:73)
> Caused by: java.io.EOFException
> at java.io.ObjectInputStream$PeekInputStream.readFully(
> ObjectInputStream.java:2335)
> at java.io.ObjectInputStream$BlockDataInputStream.
> readShort(ObjectInputStream.java:2804)
> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:802)
> at java.io.ObjectInputStream.(ObjectInputStream.java:299)
> at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48)
> at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(
> AbstractSynchronousByteArrayCommandTransport.java:34)
> at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(
> SynchronousCommandTransport.java:59)
>
> On the slave in /var/log/auth.log:
>
> May  1 14:03:27 nvs0559 sshd[31795]: fatal: dh_gen_key: group too small:
> 1024 (2*need 1024) [preauth]
>
> Upgrading the slave to debian 8 fixes it, but I really need debian 7 for
> the project to be able to build it.
> What are my options?
>
> Thanks!
> Jaap de Jong
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/fec29bdf-e118-47ef-9f97-4f4552db0d63%40googlegroups.
> com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Dick Ginga
Build Engineer
rgi...@disruptorbeam.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAL3PpaXMYkUoqTL2%2Bd6-6GTWgdD9dASOnus-0yk-U9Tb4jsQkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Help | ReInstall Jenkins pointing to OLD JENKINS_HOME path

[LnT]

Hi ,
my legacy environment of jenkins(1.7) master is with and user called 
RobertoGa in Windows 7
And jenkins home is pointed to c:\Users\RobertoGa

Now the Jenkins master, 18 slaves and 200+ jobs ==> everything is @ jenkins 
home is pointed to c:\Users\RobertoGa

Since the jenkins application is not installed as windows service , it is 
coupled with the user RobertoGa.

We have created a service user account now - called 'adm_jenkins'. This 
will be always as a logged in user
Wish to start/stop/restart jenkins using 'adm_jenkins'

- Started Jenkins  using adm_jenkins user

> java -DJENKINS_HOME=c:\Users\RobertoGa -jar 
 During initialization, the command line execution throws error:  
-  not recognized
 e.g. WIN_DCA02 not recognized

It seems Slave information is stored somewhere & not loaded when launching 
the tool using a different user
Could you please help in this regards

Cheers,
LnT

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/3e73e1a6-069f-4dfd-b4d5-d776e714cd29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Merge to Master not kicking Open PRs to also build

[Jeffrey]

Hey, Thanks for reading. 

All PRs build -- and post back a status message to GIT delivering build 
success or failure right? 

2 PRs like before -- both build successfully and show "Clear to ship"

PR1 Gets merged to Master (Which changes code that may or may not work on 
PR2 )

Unless someone goes back and forces PR 2 to build again -- there is no test 
of the newly introduced code in master (from PR1) -- you can ship untested 
/ breaking code. 

Any time a merge occurs -- all PRs referencing that head should be forced 
to rebuild to ensure the merged version works right? 

On Monday, May 1, 2017 at 5:59:06 PM UTC-4, Baptiste Mathus wrote:
>
> Must be missing something but failing to see why merging a PR should 
> retrigger the builds of others.
>
> Care to clarify?
>
> Thanks
>
> Le 1 mai 2017 10:43 PM, "Jeffrey" > a 
> écrit :
>
>> So -- Ive reverted Jenkins to 2.46.2 latest patches and the behavior is 
>> the same.
>>
>> What I expect: 
>>
>>1. Two open PRs
>>2. Merge one PR to master
>>3. Master auto builds
>>4. Repo is scanned and the other PR builds. This is still not 
>>happening. Any help much appreciated.
>>
>>
>> On Friday, April 28, 2017 at 2:24:21 PM UTC-4, Jeffrey wrote:
>>>
>>> Good Afternoon Jenkins-Land
>>>
>>>  Running into a weird issue in version Jenkins 2.53 and 2.57 (Latest 
>>> plugins). 
>>>
>>> Old Version: (I believe 2.45) (Git / SCM plugins previous to version 2.0)
>>> Jenkins Multibranch Pipeline, Freestyle --> Jenkinsfile from ORG folder
>>> 1.   We have 5 open PRs. 
>>> 2.   We merge one of the PRs to master
>>> 3.   Master auto builds (webook)
>>> 4.   The remaining 4 PRs also build (merge with new master and build) 
>>>
>>> Weird issue: (Versions 2.53, and 2.57) (Git and SCM plugins now post 2.0)
>>> 1.   We have 5 open PRs. 
>>> 2.   We merge one of the PRs to master
>>> 3.   Master auto builds (Webhook)
>>> 4.   Nothing happens to open PRs
>>> 5.   Re-scan of the ORG or the repository in Jenkins causes the PRs to 
>>> build. 
>>>
>>>
>>> Our configurations are stored on a central NFS mount and Jenkins Master 
>>> run in Docker. 
>>>
>>> Any help on where to look for the possible causes? 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/d6db8731-d016-4821-b806-ceb637049cac%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/25570dc9-af90-47e7-8f1b-d263b418d294%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Add external folder zip at deployement time

[Simon Franquet]

Hello,

we use Jenkins with build Parameters plugin and Publish over ssh plugin.

I need to zip a folder from the network and add it to the final  deployed 
zip at deployment stage.

The transfert Panel option seems to be the good place where to do that, in 
the source files combo it is possible to specify a command to exec. But i 
can't figure how the zipped folder should be included in the sources to 
deploy... After experiment, it not seems to good way ...

Any hints ?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/0bc04ff8-47ca-4f00-85d3-74639075306f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] LDAP plugin 1.15 has validation button

[Stephen Connolly]

We have added a "Test LDAP settings" button to the LDAP plugin in version
1.15

I strongly recommend that you use this button to validate your existing
configuration.

I have seen cases where the LDAP settings contained incorrect configuration
for either user lookup or group resolution. These issues can be subtle -
typically only seen by users during API token access over the REST API or
when using the Jenkins CLI with SSH Key based authentication... and often
dismissed by the users.

The wise Jenkins administrators will be testing the LDAP plugin update in a
test Jenkins prior to upgrading (you can still leverage the test button to
check your configuration this way as long as you replicate the LDAP config
from your production Jenkins into the test Jenkins)

See JENKINS-43388  for
more details on this new feature

-Stephen

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwpLULid0v73nvcctU-N1XbEd23CG49DpRx_9fM2zXWeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What's Italian for "New-poster moderation for Google Groups has been enabled?"

[Aldrin Leal]

[Slightly offtopic]

Thanks for doing this. I once thought Germano Mosconi (google him) was
profane enough.

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Mon, May 1, 2017 at 3:14 PM, R. Tyler Croy  wrote:

>
> In response to our on-going battle against spam, we have grown the Google
> Group
> moderations teams for jenkinsci-dev@ and jenkinsci-users@. With more
> moderators, this means that we can enable "New poster" moderation.
>
> What this means is that, until further notice, first-time posters to these
> mailing lists will have their messages filtered to a special moderation
> queue,
> and must then be approved before being sent out.
>
>
>
> 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/20170501201446.nsd5v5m7xf6nwcfa%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALpo8NuOfceDGRkzTDpHu4yPNFtSrtxU61JhVCk08pefXcV_MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline with CVS

[xtonic]

 

Hi,


I try to write pipeline to check out code from CVS. While there are many 
example with git, I cannot find any example with CVS. I would very 
appreciate if anyone can post some groovy examples here.


Regards,

David

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/2f7ad96b-e5c4-49bc-8b86-05ac1d8bf14f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gradle - JaCoCo via Jenkins build failure(java.lang.ClassNotFoundException: org.jacoco.report.IReportGroupVisitor)

[Makarand Jadhav]

Hello,

Can someone please assist or point me in the right direction on gradle 
error seen during the build using JaCoCo plugin executing via Jenkins? 
Thanks in advance!
See details below on my setup and steps performed.

I am running Jenkins Job that has uses Gradle plugin(V1.26 from 
*https://wiki.jenkins-ci.org/display/JENKINS/Gradle+Plugin* 
) & JaCoCo 
plugin(V2.2.0 from 
*https://wiki.jenkins-ci.org/display/JENKINS/JaCoCo+Plugin* 
).
Here is how the Configuration in Jenkins Job is for Gradle & JaCoCo:
*Gradle Plugin*(uses build.gradle):
1. Uses Gradle Version 2.9 installed on Jenkins server
2. Calls gradle tasks "clean testjar -Dtest.single=AllTestsSuite test 
-DENVIRONMENT=dev2". Note that -DENVIRONMENT is property used for 
distinguishing our test environments
*JaCoCo Plugin*:
Configured for recording of JacoCo coverage report

The build.gradle changes for executing jacocoTestReport has been done using 
instructions at *https://docs.gradle.org/2.9/userguide/jacoco_plugin.html* 
 and the 
build.gradle for is as below:

apply plugin: 'jacoco'

ext.buildWS = System.getenv('WORKSPACE')

test {
println 'INFO: JUnit Test Properties'
jvmArgs 
"-javaagent:${configurations.testJMockitAgent.asPath}","-javaagent:${configurations.testSpringInstrumentAgent.asPath}"
// Override the DB type for this set of tests
systemProperties = System.getProperties();
systemProperties['user.dir'] = workingDir
//systemProperty 'ENVIRONMENT', 'dev2'
testLogging {
// Show that tests are run in the command-line output
events 'started', 'passed'
}
finalizedBy jacocoTestReport
}

jacoco {
toolVersion = "0.7.1.201405082137"
}
jacocoTestReport {
group = "Reporting"
description = "Generate Jacoco coverage reports after running tests."
reports {
html.enabled true
xml.enabled true
csv.enabled false
html.destination "${buildWS}/jacocoHtml"
}
}

But the following is failing in Jenkins with the below mentioned error 
after the "test" task is executed. In the build workspace, I can see that 
test.exec is getting generated in the //build/jacoco/ :

--Many Lines Deleted-
14:53:15 :jacocoTestReport FAILED
14:53:15 
14:53:15 FAILURE: Build failed with an exception.
14:53:15 
14:53:15 * What went wrong:
14:53:15 Execution failed for task ':jacocoTestReport'.
14:53:15 > org.jacoco.report.IReportGroupVisitor
14:53:15 
14:53:15 * Try:
14:53:15 Run with --info or --debug option to get more log output.
14:53:15 
14:53:15 * Exception is:
14:53:15 org.gradle.api.tasks.TaskExecutionException: Execution failed for 
task ':jacocoTestReport'.
14:53:15 at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
14:53:15 at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
14:53:15 at 
org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
14:53:15 at 
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
14:53:15 at 
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
14:53:15 at 
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52)
14:53:15 at 
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
14:53:15 at 
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
14:53:15 at 
org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
14:53:15 at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203)
14:53:15 at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:185)
14:53:15 at 
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:66)
14:53:15 at 
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:50)
14:53:15 at 
org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:25)
14:53:15 at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:110)
14:53:15 at 
org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
14:53:15 at 
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
14:53:15 at 
org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
14:53:15 at 
org.gradle.execution.DefaultBuildExecuter$1.proceed(Defaul

jenkins slave node running debian 7 will not launch

[Jaap de Jong]

Hi All!

Since a recent update my slave jenkins node will not launch.
It is running debian 7 with oracle jre 1.8.0_131.
The master runs debian 8 with the same jvm.
Launching the slave fails on the first ssh connection the master tries to 
make.
In the /var/log/jenkins/jenkins.log on the master:

[05/01/17 08:09:14] SSH Launch of OpenEmbedded Buildserver on mySlave 
failed in 4,899 ms
May 01, 2017 8:09:14 AM 
hudson.remoting.SynchronousCommandTransport$ReaderThread run
SEVERE: I/O error in channel OpenEmbedded Buildserver
java.io.IOException: Unexpected termination of the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:73)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2335)
at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2804)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:802)
at java.io.ObjectInputStream.(ObjectInputStream.java:299)
at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48)
at 
hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:59)

On the slave in /var/log/auth.log:

May  1 14:03:27 nvs0559 sshd[31795]: fatal: dh_gen_key: group too small: 
1024 (2*need 1024) [preauth]

Upgrading the slave to debian 8 fixes it, but I really need debian 7 for 
the project to be able to build it.
What are my options?

Thanks!
Jaap de Jong 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/fec29bdf-e118-47ef-9f97-4f4552db0d63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

For Every build it showing below warning

[Sandeep Grandham]

Hi..

While i am trying to build a project, for every build i am getting this 
warning message. loke

Warning: this build has no associated authentication, so build permissions 
may be lacking, and downstream projects which cannot even be seen by an 
anonymous user will be silently skipped
Finished: SUCCESS

what is this meaning?

Please help me to resolve this?

Thanks,
Sandeep

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/9cc7ce8d-ac44-4ad7-bb33-4d414fe80ac1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.