Jenkins EC2 plugin spot instances and Google Login plugin - Can't access JNLP file

[Michael Barrientos]

We would like to use Jenkins EC2 plugin to create spot instances for our 
tests. We also use the Google Login Plugin, but the login plugin seems to 
get int the way of the mechanism that the Spot plugin uses to register 
itself; it cannot read the /computer/[slave id]/slave-agent.jnlp file 
because the slave gets a 403 Forbidden error when it tries to retrieve the 
file (exception is thrown at hudson.remoting.Launcher.parseJnlpArguments 
with message "403 Forbidden"). We use the Role Strategy Plugin to control 
access, but even adding a Role that Anonymous users have access to with 
Slave Connect privileges does not work.

This was also manifesting itself when we were using the GitHub 
authentication plugin using the GitHub Commiter Authorization Strategy.

All documentation for the EC2 plugin for spot instances seem to assume you 
are using the Jenkins built in authentication, and the closest workaround I 
could find (which is heavily underdocumented) involves making a fake user 
on Github with a token authentication, which somehow bypasses this issue. 
This doesn't seem to be available for the Google Login Plugin.

Note that this is happening even with the "Enable Slave → Master Access 
Control" checkbox in Global Security turned off.

It seems that there may be a case of too many plugins getting in the way, 
but perhaps I've missed some configuration/extra arguments that either 
allows alternate authentication with enough permissions to get the JNLP 
file, or maybe missing some configuration that allows anonymous access to 
the JNLP file.

Any ideas?

-- 
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/62820600-c911-4cd0-9ef3-f2fd8ef488b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Git Plugin and Maven Release Builds

[Mark Waite]

Could do that as well, though the git parameter plugin is technically
correct.  It is showing the branch to be built, and the branch to be built
truly is "origin/master", since there is no local master branch tracking
the remote branch.

Mark Waite

On Wed, Dec 30, 2015 at 11:41 AM Michael Giroux  wrote:

> Mark, I wonder if one of the issues I have is actually a defect in the Git
> Parameter plugin.  Specifically, the values set by the Git Parameter plugin
> include the "origin/" prefix.  When this is used as the value for checkout
> to local branch, AND the build is a maven release, we end up with a new
> branch in Stash "origin/master" (should be simply master) or
> "origin/some_other_branch".  It seems that normal builds run just fine, but
> release builds result in pushes back to Git and here is where the branch
> names get messed up.
>
> Should I be asking the Git Parameter plugin developers to strip the
> leading "origin/" from the branch names that are assigned to the parameter?
>
> Michael
>
>
> On Wednesday, December 30, 2015 at 11:22:33 AM UTC-7, Michael Giroux wrote:
>>
>> Thanks Mark.  Command line build runs fine w/o compile errors.  For your
>> reference, this is a known Eclipse issue bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=369592.
>>
>> On Wednesday, December 30, 2015 at 10:34:59 AM UTC-7, Mark Waite wrote:
>>>
>>> https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/ (and my
>>> internal Jenkins server inside my firewall) confirm that the code on the
>>> master branch compiles correctly from the maven command line.
>>>
>>> I run my debugger from Netbeans (rather than Eclipse) and can confirm
>>> that it compiles and runs from Netbeans as well.  I don't use Eclipse, so
>>> I'm not much help wiht Eclipse specific failures.
>>>
>>> Mark Waite
>>>
>>> On Wed, Dec 30, 2015 at 8:31 AM Michael Giroux 
>>> wrote:
>>>
 BTW, the following patch resolves my compile errors, but not sure if
 the cast to (Item) is the best choice.

 diff --git a/src/test/java/hudson/plugins/git/GitSCMTest.java
 b/src/test/java/hudson/plugins/git/GitSCMTest.java
 index 3a14b10..a39e60c 100644
 --- a/src/test/java/hudson/plugins/git/GitSCMTest.java
 +++ b/src/test/java/hudson/plugins/git/GitSCMTest.java
 @@ -1203,7 +1203,7 @@
  false,
 Collections.emptyList(),
  browser, null, null);
  p.setScm(scm);
 -configRoundtrip(p);
 +configRoundtrip((Item)p);
  assertEqualDataBoundBeans(scm,p.getScm());
  assertEquals("Wrong key", "git " + url, scm.getKey());
  }
 @@ -1215,7 +1215,7 @@
  FreeStyleProject p = createFreeStyleProject();
  GitSCM scm = new GitSCM("https://github.com/jenkinsci/jenkins
 ");
  p.setScm(scm);
 -configRoundtrip(p);
 +configRoundtrip((Item)p);
  assertEqualDataBoundBeans(scm,p.getScm());
  }



 On Wednesday, December 30, 2015 at 10:29:37 AM UTC-7, Michael Giroux
 wrote:
>
> Not making any changes to code, just trying to examine primary project
> source to understand what is being changed in the PRs.
> I cloned the primary git repo from
> https://github.com/jenkinsci/git-plugin.git so I could get some
> context for the PRs which show only the code being changed.  Getting
> compile errors on unmodified project.
>
> Eclipse version 4.5 (Mars), JDK  1.8.0 (also tried JDK 1.7.0)
>
>
> On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, Mark Waite wrote:
>>
>> Don't attempt to evaluate the two pull requests in the same
>> repository.  They are two different ideas that might meet your need.  I
>> suspect that one or the other will eventually be merged, but not both.
>>
>> Mark Waite
>>
>> On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux 
>> wrote:
>>
>>> Mark, I'm taking a look at the two pull requests.  I cloned the repo
>>> so I can view code in Eclipse, but I'm getting compile errors in
>>> GitSCMTest.java:
>>>
>>> Description Resource Path Location Type
>>> The method configRoundtrip(FreeStyleProject) is ambiguous for the
>>> type GitSCMTest GitSCMTest.java
>>> /git/src/test/java/hudson/plugins/git line 1206 Java Problem
>>>
>>> Suggestions?
>>>
>>> Michael
>>>
>>> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:
>>>
 There is a pending pull request to the git plugin which provides a
 new environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that
 proposed environment variable are not quite what you're describing, 
 but you
 might review the pull request to see if it is close enough for your use
 case.  See https://github.com/jenkinsci/git-plugin/pull/347 and
 https://github.com/

Re: Jenkins Git Plugin and Maven Release Builds

[Michael Giroux]

Mark, I wonder if one of the issues I have is actually a defect in the Git 
Parameter plugin.  Specifically, the values set by the Git Parameter plugin 
include the "origin/" prefix.  When this is used as the value for checkout 
to local branch, AND the build is a maven release, we end up with a new 
branch in Stash "origin/master" (should be simply master) or 
"origin/some_other_branch".  It seems that normal builds run just fine, but 
release builds result in pushes back to Git and here is where the branch 
names get messed up.

Should I be asking the Git Parameter plugin developers to strip the leading 
"origin/" from the branch names that are assigned to the parameter?

Michael

On Wednesday, December 30, 2015 at 11:22:33 AM UTC-7, Michael Giroux wrote:
>
> Thanks Mark.  Command line build runs fine w/o compile errors.  For your 
> reference, this is a known Eclipse issue bug 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=369592.
>
> On Wednesday, December 30, 2015 at 10:34:59 AM UTC-7, Mark Waite wrote:
>>
>> https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/ (and my 
>> internal Jenkins server inside my firewall) confirm that the code on the 
>> master branch compiles correctly from the maven command line.
>>
>> I run my debugger from Netbeans (rather than Eclipse) and can confirm 
>> that it compiles and runs from Netbeans as well.  I don't use Eclipse, so 
>> I'm not much help wiht Eclipse specific failures.
>>
>> Mark Waite
>>
>> On Wed, Dec 30, 2015 at 8:31 AM Michael Giroux  wrote:
>>
>>> BTW, the following patch resolves my compile errors, but not sure if the 
>>> cast to (Item) is the best choice.
>>>
>>> diff --git a/src/test/java/hudson/plugins/git/GitSCMTest.java 
>>> b/src/test/java/hudson/plugins/git/GitSCMTest.java
>>> index 3a14b10..a39e60c 100644
>>> --- a/src/test/java/hudson/plugins/git/GitSCMTest.java
>>> +++ b/src/test/java/hudson/plugins/git/GitSCMTest.java
>>> @@ -1203,7 +1203,7 @@
>>>  false, 
>>> Collections.emptyList(),
>>>  browser, null, null);
>>>  p.setScm(scm);
>>> -configRoundtrip(p);
>>> +configRoundtrip((Item)p);
>>>  assertEqualDataBoundBeans(scm,p.getScm());
>>>  assertEquals("Wrong key", "git " + url, scm.getKey());
>>>  }
>>> @@ -1215,7 +1215,7 @@
>>>  FreeStyleProject p = createFreeStyleProject();
>>>  GitSCM scm = new GitSCM("https://github.com/jenkinsci/jenkins
>>> ");
>>>  p.setScm(scm);
>>> -configRoundtrip(p);
>>> +configRoundtrip((Item)p);
>>>  assertEqualDataBoundBeans(scm,p.getScm());
>>>  }
>>>  
>>>
>>>
>>> On Wednesday, December 30, 2015 at 10:29:37 AM UTC-7, Michael Giroux 
>>> wrote:

 Not making any changes to code, just trying to examine primary project 
 source to understand what is being changed in the PRs.
 I cloned the primary git repo from 
 https://github.com/jenkinsci/git-plugin.git so I could get some 
 context for the PRs which show only the code being changed.  Getting 
 compile errors on unmodified project.

 Eclipse version 4.5 (Mars), JDK  1.8.0 (also tried JDK 1.7.0)


 On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, Mark Waite wrote:
>
> Don't attempt to evaluate the two pull requests in the same 
> repository.  They are two different ideas that might meet your need.  I 
> suspect that one or the other will eventually be merged, but not both.
>
> Mark Waite
>
> On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux  
> wrote:
>
>> Mark, I'm taking a look at the two pull requests.  I cloned the repo 
>> so I can view code in Eclipse, but I'm getting compile errors in 
>> GitSCMTest.java:
>>
>> Description Resource Path Location Type
>> The method configRoundtrip(FreeStyleProject) is ambiguous for the 
>> type GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git 
>> line 
>> 1206 Java Problem
>>
>> Suggestions?
>>
>> Michael
>>
>> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:
>>
>>> There is a pending pull request to the git plugin which provides a 
>>> new environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that 
>>> proposed environment variable are not quite what you're describing, but 
>>> you 
>>> might review the pull request to see if it is close enough for your use 
>>> case.  See https://github.com/jenkinsci/git-plugin/pull/347 and 
>>> https://github.com/jenkinsci/git-plugin/pull/304 for two different 
>>> possibilities.
>>>
>>> Mark Waite
>>>
>>> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux  
>>> wrote:
>>>
>> Yes.  

 The issue I'm describing is a result of using the Git Parameter 
 plugin which allows the user to select a branch, + the Git plugin 
 which 
 allows

Why are multiple workspaces being created for a single workflow job execution

[darrell cabral]

I have a workflow that should only need one workspace but consumes 2 
workspaces (1 for those steps that run on the dockerHostNode agent and 1 
for those steps that run on a 'dockerHost' docker container agent).  At one 
time the build only consumed one workspace but at some point (after 
triggering 2 jobs simultaneously, I think) the build started using multiple 
workspaces per a single job execution.  

Jenkins version 1.609.3
workflow version is 1.12

Here is a simplified example of how my workflow looks:

stage name: 'sync workspace', concurrency: 2
   node(dockerHostNode) {
  checkout ...
   }
stage name: 'Build Source', concurrency: 2
   node(dockerHostNode) {
  sh  make ...
   }

stage name: 'Run unittest', concurrency: 2

   parallel( 
   unittest-a : { 
   node('dockerNode'){
   sh ...  // run unittest-a
   }
   },
   unittest-b : { 
   node('dockerNode'){
   sh ...  // run unittest-b
   }
   }
   )

stage name: 'Post Build Task', concurrency: 2
   node(hostNode) {
  sh  make ...  // collect artifacts, scan logs, etc
   }

Does anyone have any idea why my workflow is creating multiple workspaces 
during a single workflow job execution?  For now I am using ws() to force 
all job steps to use the same workspace, but I can still see that a second 
workspace is unnecessarily created during some of the allocate node start 
steps.

-- 
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/454cae30-3d02-403c-8d35-8a61751ea310%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins - changing Stash repo browser URL

[Alex Brodov]

I'm trying to change the Stash repo browser URL for all my jobs (about 200 
jobs), i've managed to change the ssh URL.

I'm doing this using a groovy script, and I'm executing it via the Script 
Console in Jenkins.

Here's a short snippet from script:

def OLD_GIT_URL = "old_url"def NEW_GIT_URL = "new_url"def 
OLD_STASH_REPO_URL_BROWSER = "oldStash/stash"
def allJobs = Jenkins.instance.getItems()

allJobs.each { job ->
def jobScm = job.getScm()
if (jobScm instanceof GitSCM) {
def oldScm  = jobScm//println "${job.getName()} ->  It has git 
in it"
def git_url = jobScm.userRemoteConfigs[0].url
println "${job.getName()} -> ${git_url}"
def new_git_url = git_url.replaceAll(OLD_GIT_URL, NEW_GIT_URL)
println "The replace url is: ${new_git_url}"
// Uncomment
//jobScm.userRemoteConfigs[0].url = new_git_url
// We have a lot of jobs which contains the repo url
if (jobScmBrowser instanceof Stash){
def repo_url = jobScmBrowser.getRepoUrl()
println "${job.getName()} --> ${repo_url}"
new_repo_url = repo_url.replaceAll(OLD_STASH_REPO_URL_BROWSER, 
NEW_GIT_URL)
println "The replace repo url is: ${new_repo_url}"
// TODO: Replace the old url with new one
// I can't change the repo url using this property, it's private!! 
//jobScmBrowser.repoUrl = new_repo_url
}
else {
println "${job.getName()} --> Not a stash browser"
}
}
else {
println "${job.getName()} -> No git in it"
}
}

-- 
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/bb5e7122-32dc-48c7-896d-ed204995394a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Git Plugin and Maven Release Builds

[Michael Giroux]

Thanks Mark.  Command line build runs fine w/o compile errors.  For your 
reference, this is a known Eclipse issue 
bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=369592.

On Wednesday, December 30, 2015 at 10:34:59 AM UTC-7, Mark Waite wrote:
>
> https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/ (and my 
> internal Jenkins server inside my firewall) confirm that the code on the 
> master branch compiles correctly from the maven command line.
>
> I run my debugger from Netbeans (rather than Eclipse) and can confirm that 
> it compiles and runs from Netbeans as well.  I don't use Eclipse, so I'm 
> not much help wiht Eclipse specific failures.
>
> Mark Waite
>
> On Wed, Dec 30, 2015 at 8:31 AM Michael Giroux  > wrote:
>
>> BTW, the following patch resolves my compile errors, but not sure if the 
>> cast to (Item) is the best choice.
>>
>> diff --git a/src/test/java/hudson/plugins/git/GitSCMTest.java 
>> b/src/test/java/hudson/plugins/git/GitSCMTest.java
>> index 3a14b10..a39e60c 100644
>> --- a/src/test/java/hudson/plugins/git/GitSCMTest.java
>> +++ b/src/test/java/hudson/plugins/git/GitSCMTest.java
>> @@ -1203,7 +1203,7 @@
>>  false, 
>> Collections.emptyList(),
>>  browser, null, null);
>>  p.setScm(scm);
>> -configRoundtrip(p);
>> +configRoundtrip((Item)p);
>>  assertEqualDataBoundBeans(scm,p.getScm());
>>  assertEquals("Wrong key", "git " + url, scm.getKey());
>>  }
>> @@ -1215,7 +1215,7 @@
>>  FreeStyleProject p = createFreeStyleProject();
>>  GitSCM scm = new GitSCM("https://github.com/jenkinsci/jenkins";);
>>  p.setScm(scm);
>> -configRoundtrip(p);
>> +configRoundtrip((Item)p);
>>  assertEqualDataBoundBeans(scm,p.getScm());
>>  }
>>  
>>
>>
>> On Wednesday, December 30, 2015 at 10:29:37 AM UTC-7, Michael Giroux 
>> wrote:
>>>
>>> Not making any changes to code, just trying to examine primary project 
>>> source to understand what is being changed in the PRs.
>>> I cloned the primary git repo from 
>>> https://github.com/jenkinsci/git-plugin.git so I could get some context 
>>> for the PRs which show only the code being changed.  Getting compile errors 
>>> on unmodified project.
>>>
>>> Eclipse version 4.5 (Mars), JDK  1.8.0 (also tried JDK 1.7.0)
>>>
>>>
>>> On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, Mark Waite wrote:

 Don't attempt to evaluate the two pull requests in the same 
 repository.  They are two different ideas that might meet your need.  I 
 suspect that one or the other will eventually be merged, but not both.

 Mark Waite

 On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux  
 wrote:

> Mark, I'm taking a look at the two pull requests.  I cloned the repo 
> so I can view code in Eclipse, but I'm getting compile errors in 
> GitSCMTest.java:
>
> Description Resource Path Location Type
> The method configRoundtrip(FreeStyleProject) is ambiguous for the type 
> GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git line 
> 1206 Java Problem
>
> Suggestions?
>
> Michael
>
> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:
>
>> There is a pending pull request to the git plugin which provides a 
>> new environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that 
>> proposed environment variable are not quite what you're describing, but 
>> you 
>> might review the pull request to see if it is close enough for your use 
>> case.  See https://github.com/jenkinsci/git-plugin/pull/347 and 
>> https://github.com/jenkinsci/git-plugin/pull/304 for two different 
>> possibilities.
>>
>> Mark Waite
>>
>> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux  
>> wrote:
>>
> Yes.  
>>>
>>> The issue I'm describing is a result of using the Git Parameter 
>>> plugin which allows the user to select a branch, + the Git plugin which 
>>> allows configuration of the branch to build and the local branch name, 
>>> + 
>>> maven release plugin which relies on local branch name for push to 
>>> remote + 
>>> Stash Webhook to Jenkins with triggers a build of any arbitrary branch.
>>>
>>> I will admit that one solution is to create two jobs in Jenkins to 
>>> allow building of any arbitrary branch as triggered by the Stash web 
>>> hook 
>>> for jenkins, and a second job that is configured to build a branch 
>>> specified by user supplied parameter values.  
>>>
>>> The problem occurs when when attempting to configure a single 
>>> jenkins build that allows for manual specification of branch via the 
>>> Git 
>>> parameter, and builds kicked off by the Stash web hook to jenkins.
>>>
>>> 1. to allow the jenkins web hook to initiate a build, it is 
>>> necessary t

Re: Approaches for sharing workspace in a pipeline

[Martin d'Anjou]

Producer code:
String root = "/opt/martin"
String workspace = "${root}/${env.JOB_NAME}/${env.BUILD_NUMBER}"
node() {
ws(workspace) {
writeFile file: 'file.txt', text: "1234"
}
}

Consumer code:
String root = "/opt/martin"
String folder = env.JOB_NAME.split('/')[0..-2].join('/')
String workspace = "${root}/${folder}/producer/${PRODUCER_BUILD_NUMBER}"
node() {
ws(workspace) {
String text = readFile 'file.txt'
echo text
}
}

The consumer has an input parameter called PRODUCER_BUILD_NUMBER, and that 
is of course annoying for users to type it in. What I want for this 
parameter is to give users the option to choose a producer build number, or 
if they leave it empty, the most recent successful producer build number is 
used. Finding this most recent producer build number programmatically is a 
bit of a challenge currently but in the past with freestyle jobs I have 
done it with curl. With the Workflow I would prefer to use a plugin based 
on a groovy RESTClient or the apache fluent api. If I understood how to 
return an object to the workflow (as opposed to perform a build action) 
perhaps I would be able to write a decent REST API plugin but I don't write 
plugins for a living so it would take me a lot of time to learn to do this. 
I am also aware of Jenkins Workflow - Creating a Class to Wrap Access to a 
Secured HTTP Endpoint 
,
 
but it uses the Global Library which is not a good long term solution yet 
as explained in JENKINS-31155 
.

Concurrent consumer builds: the workspace has to be copied before the build 
jumps into action, unless you are certain that no files will collide on 
write. For me copying the workspace is still cheaper than re-creating it 
from scratch, so I will go for a full copy. Code is TBD but the easiest is 
probably a simple unix copy inside an "sh" build step.

Martin

On Wednesday, December 30, 2015 at 5:24:26 AM UTC-5, Thomas Goeppel wrote:
>
> Hi John,
>
> your approach sounds interesting. Could you please share some Workflow 
> code that shows how you compute the Workspace location, use ws(), and pass 
> workspace locations to subsequent jobs? 
>
> When accessing workspaces in Workflow you're also facing the problem of 
> concurrent runs. How do you deal with that?
>
> Thanks in advance!
>
> Greetings,
> Thomas
>  
>
> On Wednesday, December 30, 2015 at 3:11:46 AM UTC+1, Martin d'Anjou wrote:
>>
>> On Wednesday, December 23, 2015 at 9:45:57 PM UTC-5, John D. Ament wrote:
>>>
>>> Hi,
>>>
>>> I was wondering if anyone had any best practices or tips to share on 
>>> have a common workspace for a pipeline job.
>>>
>>
>> I use Workflow job definitions, and I compute the location of the 
>> workspace in each job of the build chain before the actual build actions 
>> take place, using the ws() built step. Subsequent jobs in the build chain 
>> use the same workspace (the location can be computed). Subsequent jobs need 
>> not to be in the same workflow definition, nor in a formal pipeline (I do 
>> not use triggers nor pipeline plugins). I have enough input parameters for 
>> the subsequent jobs in the chain to locate the workspace of the previous 
>> job. I do not move nor archive data (I have thousands of files and 
>> gigabytes of data over NFS so I don't want to spend time moving it or 
>> archiving/extracting it).
>>
>

-- 
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/df3d3729-603b-4e7b-acd2-228f94e20290%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Git Plugin and Maven Release Builds

[Mark Waite]

https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/ (and my
internal Jenkins server inside my firewall) confirm that the code on the
master branch compiles correctly from the maven command line.

I run my debugger from Netbeans (rather than Eclipse) and can confirm that
it compiles and runs from Netbeans as well.  I don't use Eclipse, so I'm
not much help wiht Eclipse specific failures.

Mark Waite

On Wed, Dec 30, 2015 at 8:31 AM Michael Giroux  wrote:

> BTW, the following patch resolves my compile errors, but not sure if the
> cast to (Item) is the best choice.
>
> diff --git a/src/test/java/hudson/plugins/git/GitSCMTest.java
> b/src/test/java/hudson/plugins/git/GitSCMTest.java
> index 3a14b10..a39e60c 100644
> --- a/src/test/java/hudson/plugins/git/GitSCMTest.java
> +++ b/src/test/java/hudson/plugins/git/GitSCMTest.java
> @@ -1203,7 +1203,7 @@
>  false,
> Collections.emptyList(),
>  browser, null, null);
>  p.setScm(scm);
> -configRoundtrip(p);
> +configRoundtrip((Item)p);
>  assertEqualDataBoundBeans(scm,p.getScm());
>  assertEquals("Wrong key", "git " + url, scm.getKey());
>  }
> @@ -1215,7 +1215,7 @@
>  FreeStyleProject p = createFreeStyleProject();
>  GitSCM scm = new GitSCM("https://github.com/jenkinsci/jenkins";);
>  p.setScm(scm);
> -configRoundtrip(p);
> +configRoundtrip((Item)p);
>  assertEqualDataBoundBeans(scm,p.getScm());
>  }
>
>
>
> On Wednesday, December 30, 2015 at 10:29:37 AM UTC-7, Michael Giroux wrote:
>>
>> Not making any changes to code, just trying to examine primary project
>> source to understand what is being changed in the PRs.
>> I cloned the primary git repo from
>> https://github.com/jenkinsci/git-plugin.git so I could get some context
>> for the PRs which show only the code being changed.  Getting compile errors
>> on unmodified project.
>>
>> Eclipse version 4.5 (Mars), JDK  1.8.0 (also tried JDK 1.7.0)
>>
>>
>> On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, Mark Waite wrote:
>>>
>>> Don't attempt to evaluate the two pull requests in the same repository.
>>> They are two different ideas that might meet your need.  I suspect that one
>>> or the other will eventually be merged, but not both.
>>>
>>> Mark Waite
>>>
>>> On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux 
>>> wrote:
>>>
 Mark, I'm taking a look at the two pull requests.  I cloned the repo so
 I can view code in Eclipse, but I'm getting compile errors in
 GitSCMTest.java:

 Description Resource Path Location Type
 The method configRoundtrip(FreeStyleProject) is ambiguous for the type
 GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git line
 1206 Java Problem

 Suggestions?

 Michael

 On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:

> There is a pending pull request to the git plugin which provides a new
> environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that
> proposed environment variable are not quite what you're describing, but 
> you
> might review the pull request to see if it is close enough for your use
> case.  See https://github.com/jenkinsci/git-plugin/pull/347 and
> https://github.com/jenkinsci/git-plugin/pull/304 for two different
> possibilities.
>
> Mark Waite
>
> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux 
> wrote:
>
 Yes.
>>
>> The issue I'm describing is a result of using the Git Parameter
>> plugin which allows the user to select a branch, + the Git plugin which
>> allows configuration of the branch to build and the local branch name, +
>> maven release plugin which relies on local branch name for push to 
>> remote +
>> Stash Webhook to Jenkins with triggers a build of any arbitrary branch.
>>
>> I will admit that one solution is to create two jobs in Jenkins to
>> allow building of any arbitrary branch as triggered by the Stash web hook
>> for jenkins, and a second job that is configured to build a branch
>> specified by user supplied parameter values.
>>
>> The problem occurs when when attempting to configure a single jenkins
>> build that allows for manual specification of branch via the Git 
>> parameter,
>> and builds kicked off by the Stash web hook to jenkins.
>>
>> 1. to allow the jenkins web hook to initiate a build, it is necessary
>> to configure the build to build any branch (leaving branch to build as
>> blank).
>> 2. to allow a maven release to build, you MUST specify a local branch
>> name.  Otherwise, the push to stash fails the build does not have a local
>> branch name.
>> 3. To meet condittion #1, the default value for the Git parameter
>> must be "**" so that the branch to build is ANY (** or empty)
>>
>> So basically, the 

Re: CIFS plugin debug messages

[Victor Martinez]

I'm not sure now if the wildcards is supported, can you set the class
instead?

I believe if you type jenkins.plugins.publish_over.  It should show the
list of available classes.

Cheer
On 30 Dec 2015 18:25, "Pritesh Saharey"  wrote:

> Hi
> looks like I am doing something wrong here, I created new Log Recorder and
> configured as mentioned here
> https://wiki.jenkins-ci.org/display/JENKINS/Logging, but new log recorder
> is empty, this is what I configured:
>
> Name: Investigating CISF copy issue
> Loggers: jenkins.plugins.publish_over.*
> Log Level: All
>
> do I need to do something more?
>
> Thanks for your help
> Jhoom
>
>
> -Original Message-
> From: Victor Martinez 
> To: Jenkins Users 
> Cc: jhoomsharabi 
> Sent: Wed, Dec 30, 2015 8:46 pm
> Subject: Re: CIFS plugin debug messages
>
> Hi,
>
> You can try to use the below logger setup in order to grab further details:
>
> - https://wiki.jenkins-ci.org/display/JENKINS/Logging
>
> CIFS plugin uses the below dependency:
> https://github.com/jenkinsci/publish-over-cifs-plugin/blob/master/pom.xml#L69-L73
>
> So you can add the below loggers in your logging setup:
>
> - jenkins.plugins.publish_over.*
>
> You can see whether those classes have got any logger setup:
>
>
> https://github.com/jenkinsci/publish-over-plugin/blob/master/src/main/java/jenkins/plugins/publish_over
>
> I hope it helps
>
> Cheers
>
> On Wednesday, 30 December 2015 15:51:52 UTC+1, Pritesh Saharey wrote:
>>
>> Hi All,
>> I am using “Publish over CIFS Plugin” 0.3v, I configured it as per
>> documentation
>> 
>> https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+CIFS+Plugin
>> even Test Configuration gives me success messages , I am suing it under
>> Post build step in job as “Send build artifact to a Windows share” copying
>> is never successful logs just shows:
>>
>> CIFS: Connecting from host [vl-pun-rie-bl47]
>> CIFS: Connecting with configuration [WinRLM-17] ...
>> CIFS: Disconnecting configuration [WinRLM-17] ...
>> CIFS: Transferred 0 file(s)
>>
>> That’s all no debug or error message, this plugin is not even generating
>> proper logs to show what’s going wrong with my inputs. Attaching screen
>> shot of my job configuration page can anyone let me know if there anyway I
>> can debug where things are going wrong, for convenience my entries are like
>> this:
>>
>>  Source Files: ${WORKSPACE}/lib/** [Contains all required jar files]
>> Remove prefix: ${WORKSPACE}
>> Remote directory: lib [Subfolder under shared folder]
>>
>> I even tried with absolute source path of my artifacts, I am ready to
>> send my job config.xml file of this project which only contains CIFS entry
>>
>>
>> Thanks,
>> Jhoom
>>
>

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

Re: Jenkins Git Plugin and Maven Release Builds

[Michael Giroux]

BTW, the following patch resolves my compile errors, but not sure if the 
cast to (Item) is the best choice.

diff --git a/src/test/java/hudson/plugins/git/GitSCMTest.java 
b/src/test/java/hudson/plugins/git/GitSCMTest.java
index 3a14b10..a39e60c 100644
--- a/src/test/java/hudson/plugins/git/GitSCMTest.java
+++ b/src/test/java/hudson/plugins/git/GitSCMTest.java
@@ -1203,7 +1203,7 @@
 false, 
Collections.emptyList(),
 browser, null, null);
 p.setScm(scm);
-configRoundtrip(p);
+configRoundtrip((Item)p);
 assertEqualDataBoundBeans(scm,p.getScm());
 assertEquals("Wrong key", "git " + url, scm.getKey());
 }
@@ -1215,7 +1215,7 @@
 FreeStyleProject p = createFreeStyleProject();
 GitSCM scm = new GitSCM("https://github.com/jenkinsci/jenkins";);
 p.setScm(scm);
-configRoundtrip(p);
+configRoundtrip((Item)p);
 assertEqualDataBoundBeans(scm,p.getScm());
 }
 


On Wednesday, December 30, 2015 at 10:29:37 AM UTC-7, Michael Giroux wrote:
>
> Not making any changes to code, just trying to examine primary project 
> source to understand what is being changed in the PRs.
> I cloned the primary git repo from 
> https://github.com/jenkinsci/git-plugin.git so I could get some context 
> for the PRs which show only the code being changed.  Getting compile errors 
> on unmodified project.
>
> Eclipse version 4.5 (Mars), JDK  1.8.0 (also tried JDK 1.7.0)
>
>
> On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, Mark Waite wrote:
>>
>> Don't attempt to evaluate the two pull requests in the same repository.  
>> They are two different ideas that might meet your need.  I suspect that one 
>> or the other will eventually be merged, but not both.
>>
>> Mark Waite
>>
>> On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux  wrote:
>>
>>> Mark, I'm taking a look at the two pull requests.  I cloned the repo so 
>>> I can view code in Eclipse, but I'm getting compile errors in 
>>> GitSCMTest.java:
>>>
>>> Description Resource Path Location Type
>>> The method configRoundtrip(FreeStyleProject) is ambiguous for the type 
>>> GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git line 
>>> 1206 Java Problem
>>>
>>> Suggestions?
>>>
>>> Michael
>>>
>>> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:
>>>
 There is a pending pull request to the git plugin which provides a new 
 environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that 
 proposed environment variable are not quite what you're describing, but 
 you 
 might review the pull request to see if it is close enough for your use 
 case.  See https://github.com/jenkinsci/git-plugin/pull/347 and 
 https://github.com/jenkinsci/git-plugin/pull/304 for two different 
 possibilities.

 Mark Waite

 On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux  
 wrote:

>>> Yes.  
>
> The issue I'm describing is a result of using the Git Parameter plugin 
> which allows the user to select a branch, + the Git plugin which allows 
> configuration of the branch to build and the local branch name, + maven 
> release plugin which relies on local branch name for push to remote + 
> Stash 
> Webhook to Jenkins with triggers a build of any arbitrary branch.
>
> I will admit that one solution is to create two jobs in Jenkins to 
> allow building of any arbitrary branch as triggered by the Stash web hook 
> for jenkins, and a second job that is configured to build a branch 
> specified by user supplied parameter values.  
>
> The problem occurs when when attempting to configure a single jenkins 
> build that allows for manual specification of branch via the Git 
> parameter, 
> and builds kicked off by the Stash web hook to jenkins.
>
> 1. to allow the jenkins web hook to initiate a build, it is necessary 
> to configure the build to build any branch (leaving branch to build as 
> blank).
> 2. to allow a maven release to build, you MUST specify a local branch 
> name.  Otherwise, the push to stash fails the build does not have a local 
> branch name.
> 3. To meet condittion #1, the default value for the Git parameter must 
> be "**" so that the branch to build is ANY (** or empty)
>
> So basically, the issue is that if a build is configured to build any 
> branch, and also has maven release configured, you need some way to get 
> the 
> code checked out to a local branch (additional behaviors) with the same 
> name as the branch being built, and there is currently no way to do that.
>
> I tried to put "${GIT_BRANCH/*\//}" into the "checkout to local 
> branch" but this did not work.  It seems this field does not resolve 
> environment variable references using full bash variable reference 
> notation.  Perhaps this is the s

Re: Jenkins Git Plugin and Maven Release Builds

[Michael Giroux]

Not making any changes to code, just trying to examine primary project 
source to understand what is being changed in the PRs.
I cloned the primary git repo from 
https://github.com/jenkinsci/git-plugin.git so I could get some context for 
the PRs which show only the code being changed.  Getting compile errors on 
unmodified project.

Eclipse version 4.5 (Mars), JDK  1.8.0 (also tried JDK 1.7.0)


On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, Mark Waite wrote:
>
> Don't attempt to evaluate the two pull requests in the same repository.  
> They are two different ideas that might meet your need.  I suspect that one 
> or the other will eventually be merged, but not both.
>
> Mark Waite
>
> On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux  > wrote:
>
>> Mark, I'm taking a look at the two pull requests.  I cloned the repo so I 
>> can view code in Eclipse, but I'm getting compile errors in GitSCMTest.java:
>>
>> Description Resource Path Location Type
>> The method configRoundtrip(FreeStyleProject) is ambiguous for the type 
>> GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git line 
>> 1206 Java Problem
>>
>> Suggestions?
>>
>> Michael
>>
>> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:
>>
>>> There is a pending pull request to the git plugin which provides a new 
>>> environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that 
>>> proposed environment variable are not quite what you're describing, but you 
>>> might review the pull request to see if it is close enough for your use 
>>> case.  See https://github.com/jenkinsci/git-plugin/pull/347 and 
>>> https://github.com/jenkinsci/git-plugin/pull/304 for two different 
>>> possibilities.
>>>
>>> Mark Waite
>>>
>>> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux  
>>> wrote:
>>>
>> Yes.  

 The issue I'm describing is a result of using the Git Parameter plugin 
 which allows the user to select a branch, + the Git plugin which allows 
 configuration of the branch to build and the local branch name, + maven 
 release plugin which relies on local branch name for push to remote + 
 Stash 
 Webhook to Jenkins with triggers a build of any arbitrary branch.

 I will admit that one solution is to create two jobs in Jenkins to 
 allow building of any arbitrary branch as triggered by the Stash web hook 
 for jenkins, and a second job that is configured to build a branch 
 specified by user supplied parameter values.  

 The problem occurs when when attempting to configure a single jenkins 
 build that allows for manual specification of branch via the Git 
 parameter, 
 and builds kicked off by the Stash web hook to jenkins.

 1. to allow the jenkins web hook to initiate a build, it is necessary 
 to configure the build to build any branch (leaving branch to build as 
 blank).
 2. to allow a maven release to build, you MUST specify a local branch 
 name.  Otherwise, the push to stash fails the build does not have a local 
 branch name.
 3. To meet condittion #1, the default value for the Git parameter must 
 be "**" so that the branch to build is ANY (** or empty)

 So basically, the issue is that if a build is configured to build any 
 branch, and also has maven release configured, you need some way to get 
 the 
 code checked out to a local branch (additional behaviors) with the same 
 name as the branch being built, and there is currently no way to do that.

 I tried to put "${GIT_BRANCH/*\//}" into the "checkout to local branch" 
 but this did not work.  It seems this field does not resolve environment 
 variable references using full bash variable reference notation.  Perhaps 
 this is the solution.  Extend the "checkout to local branch" to provide 
 full bash resolution of the variable name.


 On Tuesday, December 29, 2015 at 10:03:25 AM UTC-7, Michael Giroux 
 wrote:
>
> Using Jenkins 1.609.3, Git plugin 2.4.0.
>
> We have configured most of our jobs to allow jobs to be initiated by 
> the Stash Webhook to Jenkins.  To allow developers to manually initiate a 
> build of any branch, the jobs use the Git Parameter to set a BRANCH 
> variable.
>
> Using this configuration, the Git Parameter is configured to set "**" 
> as the default branch to build.  This allows the Stash Webhook to 
> initiate 
> a build of any branch.  In order to allow the job to perform a maven 
> release, we have configured the Git SCM to checkout to local branch 
> "master".  This all works well as long as we are not doing a maven 
> release, 
> or when we do a maven release on the master branch.  The strategy breaks 
> down if the developer attempts a maven release on another branch when the 
> maven release:prepare goal tries to push pom updates.  Note that the 
> maven 
> release plugin uses the

Re: CIFS plugin debug messages

[Pritesh Saharey]

Hi
looks like I am doing something wrong here, I created new Log Recorder and 
configured as mentioned here 
https://wiki.jenkins-ci.org/display/JENKINS/Logging, but new log recorder is 
empty, this is what I configured:
 
Name: Investigating CISF copy issue
Loggers: jenkins.plugins.publish_over.*
Log Level: All
 
do I need to do something more?
 
Thanks for your help
Jhoom
 
 
-Original Message-
From: Victor Martinez 
To: Jenkins Users 
Cc: jhoomsharabi 
Sent: Wed, Dec 30, 2015 8:46 pm
Subject: Re: CIFS plugin debug messages



Hi,


You can try to use the below logger setup in order to grab further details:


- https://wiki.jenkins-ci.org/display/JENKINS/Logging


CIFS plugin uses the below dependency: 
https://github.com/jenkinsci/publish-over-cifs-plugin/blob/master/pom.xml#L69-L73


So you can add the below loggers in your logging setup:


- jenkins.plugins.publish_over.*


You can see whether those classes have got any logger setup: 


https://github.com/jenkinsci/publish-over-plugin/blob/master/src/main/java/jenkins/plugins/publish_over



I hope it helps


Cheers


On Wednesday, 30 December 2015 15:51:52 UTC+1, Pritesh Saharey  wrote:
Hi All,
I am using “Publish over CIFS Plugin” 0.3v, I configured itas per documentation 
https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+CIFS+Plugineven Test 
Configuration gives me success messages , I am suing it under Postbuild step in 
job as “Send build artifact to a Windows share” copying is never successfullogs 
just shows:
 
CIFS:Connecting from host [vl-pun-rie-bl47]
CIFS:Connecting with configuration [WinRLM-17] ...
CIFS:Disconnecting configuration [WinRLM-17] ...
CIFS:Transferred 0 file(s)
 
That’s all no debug or error message, this plugin is noteven generating proper 
logs to show what’s going wrong with my inputs.Attaching screen shot of my job 
configuration page can anyone let me know ifthere anyway I can debug where 
things are going wrong, for convenience myentries are like this:
 
 Source Files: ${WORKSPACE}/lib/**[Contains all required jar files]
Remove prefix: ${WORKSPACE} 
Remote directory: lib [Subfolder under shared folder]
 
I even tried with absolute source path of my artifacts, I amready to send my 
job config.xml file of this project which only contains CIFSentry 
 
 
Thanks,
Jhoom



-- 
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/151f3ec19c8-3a8a-1003e%40webprd-m73.mail.aol.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Git Plugin and Maven Release Builds

[Mark Waite]

Don't attempt to evaluate the two pull requests in the same repository.
They are two different ideas that might meet your need.  I suspect that one
or the other will eventually be merged, but not both.

Mark Waite

On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux  wrote:

> Mark, I'm taking a look at the two pull requests.  I cloned the repo so I
> can view code in Eclipse, but I'm getting compile errors in GitSCMTest.java:
>
> Description Resource Path Location Type
> The method configRoundtrip(FreeStyleProject) is ambiguous for the type
> GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git line 1206 
> Java
> Problem
>
> Suggestions?
>
> Michael
>
> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:
>
>> There is a pending pull request to the git plugin which provides a new
>> environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that
>> proposed environment variable are not quite what you're describing, but you
>> might review the pull request to see if it is close enough for your use
>> case.  See https://github.com/jenkinsci/git-plugin/pull/347 and
>> https://github.com/jenkinsci/git-plugin/pull/304 for two different
>> possibilities.
>>
>> Mark Waite
>>
>> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux  wrote:
>>
> Yes.
>>>
>>> The issue I'm describing is a result of using the Git Parameter plugin
>>> which allows the user to select a branch, + the Git plugin which allows
>>> configuration of the branch to build and the local branch name, + maven
>>> release plugin which relies on local branch name for push to remote + Stash
>>> Webhook to Jenkins with triggers a build of any arbitrary branch.
>>>
>>> I will admit that one solution is to create two jobs in Jenkins to allow
>>> building of any arbitrary branch as triggered by the Stash web hook for
>>> jenkins, and a second job that is configured to build a branch specified by
>>> user supplied parameter values.
>>>
>>> The problem occurs when when attempting to configure a single jenkins
>>> build that allows for manual specification of branch via the Git parameter,
>>> and builds kicked off by the Stash web hook to jenkins.
>>>
>>> 1. to allow the jenkins web hook to initiate a build, it is necessary to
>>> configure the build to build any branch (leaving branch to build as blank).
>>> 2. to allow a maven release to build, you MUST specify a local branch
>>> name.  Otherwise, the push to stash fails the build does not have a local
>>> branch name.
>>> 3. To meet condittion #1, the default value for the Git parameter must
>>> be "**" so that the branch to build is ANY (** or empty)
>>>
>>> So basically, the issue is that if a build is configured to build any
>>> branch, and also has maven release configured, you need some way to get the
>>> code checked out to a local branch (additional behaviors) with the same
>>> name as the branch being built, and there is currently no way to do that.
>>>
>>> I tried to put "${GIT_BRANCH/*\//}" into the "checkout to local branch"
>>> but this did not work.  It seems this field does not resolve environment
>>> variable references using full bash variable reference notation.  Perhaps
>>> this is the solution.  Extend the "checkout to local branch" to provide
>>> full bash resolution of the variable name.
>>>
>>>
>>> On Tuesday, December 29, 2015 at 10:03:25 AM UTC-7, Michael Giroux wrote:

 Using Jenkins 1.609.3, Git plugin 2.4.0.

 We have configured most of our jobs to allow jobs to be initiated by
 the Stash Webhook to Jenkins.  To allow developers to manually initiate a
 build of any branch, the jobs use the Git Parameter to set a BRANCH
 variable.

 Using this configuration, the Git Parameter is configured to set "**"
 as the default branch to build.  This allows the Stash Webhook to initiate
 a build of any branch.  In order to allow the job to perform a maven
 release, we have configured the Git SCM to checkout to local branch
 "master".  This all works well as long as we are not doing a maven release,
 or when we do a maven release on the master branch.  The strategy breaks
 down if the developer attempts a maven release on another branch when the
 maven release:prepare goal tries to push pom updates.  Note that the maven
 release plugin uses the current local branch in the push as "git push url
 localBranch:localBranch"  As a result, when the build is for "some_branch"
 which has been checked out to local branch "master" we get an error on "git
 push ... master:master" because the remote "master" is not in sync with the
 local.  No surprises here since the local "master" is actually
 "some_branch".

 To resolve this, we have deleted the "checkout to local branch"
 additional action, and added a pre-build step that does the following:'
 # checkout to a local branch using the remote branch name
 LOCAL_GIT_BRANCH=${GIT_BRANCH/*\//}
 git rev-parse --quiet --verif

Re: Jenkins Git Plugin and Maven Release Builds

[Michael Giroux]

Mark, I'm taking a look at the two pull requests.  I cloned the repo so I 
can view code in Eclipse, but I'm getting compile errors in GitSCMTest.java:

Description Resource Path Location Type
The method configRoundtrip(FreeStyleProject) is ambiguous for the type 
GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git line 1206 Java 
Problem

Suggestions?

Michael

On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark Waite wrote:
>
> There is a pending pull request to the git plugin which provides a new 
> environment variable, GIT_SHORT_BRANCH_NAME.  The semantics of that 
> proposed environment variable are not quite what you're describing, but you 
> might review the pull request to see if it is close enough for your use 
> case.  See https://github.com/jenkinsci/git-plugin/pull/347 and 
> https://github.com/jenkinsci/git-plugin/pull/304 for two different 
> possibilities.
>
> Mark Waite
>
> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux  > wrote:
>
>> Yes.  
>>
>> The issue I'm describing is a result of using the Git Parameter plugin 
>> which allows the user to select a branch, + the Git plugin which allows 
>> configuration of the branch to build and the local branch name, + maven 
>> release plugin which relies on local branch name for push to remote + Stash 
>> Webhook to Jenkins with triggers a build of any arbitrary branch.
>>
>> I will admit that one solution is to create two jobs in Jenkins to allow 
>> building of any arbitrary branch as triggered by the Stash web hook for 
>> jenkins, and a second job that is configured to build a branch specified by 
>> user supplied parameter values.  
>>
>> The problem occurs when when attempting to configure a single jenkins 
>> build that allows for manual specification of branch via the Git parameter, 
>> and builds kicked off by the Stash web hook to jenkins.
>>
>> 1. to allow the jenkins web hook to initiate a build, it is necessary to 
>> configure the build to build any branch (leaving branch to build as blank).
>> 2. to allow a maven release to build, you MUST specify a local branch 
>> name.  Otherwise, the push to stash fails the build does not have a local 
>> branch name.
>> 3. To meet condittion #1, the default value for the Git parameter must be 
>> "**" so that the branch to build is ANY (** or empty)
>>
>> So basically, the issue is that if a build is configured to build any 
>> branch, and also has maven release configured, you need some way to get the 
>> code checked out to a local branch (additional behaviors) with the same 
>> name as the branch being built, and there is currently no way to do that.
>>
>> I tried to put "${GIT_BRANCH/*\//}" into the "checkout to local branch" 
>> but this did not work.  It seems this field does not resolve environment 
>> variable references using full bash variable reference notation.  Perhaps 
>> this is the solution.  Extend the "checkout to local branch" to provide 
>> full bash resolution of the variable name.
>>
>>
>> On Tuesday, December 29, 2015 at 10:03:25 AM UTC-7, Michael Giroux wrote:
>>>
>>> Using Jenkins 1.609.3, Git plugin 2.4.0.
>>>
>>> We have configured most of our jobs to allow jobs to be initiated by the 
>>> Stash Webhook to Jenkins.  To allow developers to manually initiate a build 
>>> of any branch, the jobs use the Git Parameter to set a BRANCH variable.
>>>
>>> Using this configuration, the Git Parameter is configured to set "**" as 
>>> the default branch to build.  This allows the Stash Webhook to initiate a 
>>> build of any branch.  In order to allow the job to perform a maven release, 
>>> we have configured the Git SCM to checkout to local branch "master".  This 
>>> all works well as long as we are not doing a maven release, or when we do a 
>>> maven release on the master branch.  The strategy breaks down if the 
>>> developer attempts a maven release on another branch when the maven 
>>> release:prepare goal tries to push pom updates.  Note that the maven 
>>> release plugin uses the current local branch in the push as "git push url 
>>> localBranch:localBranch"  As a result, when the build is for "some_branch" 
>>> which has been checked out to local branch "master" we get an error on "git 
>>> push ... master:master" because the remote "master" is not in sync with the 
>>> local.  No surprises here since the local "master" is actually 
>>> "some_branch".
>>>
>>> To resolve this, we have deleted the "checkout to local branch" 
>>> additional action, and added a pre-build step that does the following:'
>>> # checkout to a local branch using the remote branch name
>>> LOCAL_GIT_BRANCH=${GIT_BRANCH/*\//}
>>> git rev-parse --quiet --verify ${LOCAL_GIT_BRANCH} && git branch -D 
>>> ${LOCAL_GIT_BRANCH}
>>> git checkout -b ${LOCAL_GIT_BRANCH} ${GIT_COMMIT}
>>>
>>> With this in place, the build checks the code out to a local branch with 
>>> the same name as the remote branch allowing the maven release:prepare goal 
>>> to push changes to the branch that is bei

Re: CIFS plugin debug messages

[Victor Martinez]

Hi,

You can try to use the below logger setup in order to grab further details:

- https://wiki.jenkins-ci.org/display/JENKINS/Logging

CIFS plugin uses the below 
dependency: 
https://github.com/jenkinsci/publish-over-cifs-plugin/blob/master/pom.xml#L69-L73

So you can add the below loggers in your logging setup:

- jenkins.plugins.publish_over.*

You can see whether those classes have got any logger setup: 

https://github.com/jenkinsci/publish-over-plugin/blob/master/src/main/java/jenkins/plugins/publish_over

I hope it helps

Cheers

On Wednesday, 30 December 2015 15:51:52 UTC+1, Pritesh Saharey wrote:
>
> Hi All,
> I am using “Publish over CIFS Plugin” 0.3v, I configured it as per 
> documentation 
> https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+CIFS+Plugin even 
> Test Configuration gives me success messages , I am suing it under Post 
> build step in job as “Send build artifact to a Windows share” copying is 
> never successful logs just shows:
>  
> CIFS: Connecting from host [vl-pun-rie-bl47]
> CIFS: Connecting with configuration [WinRLM-17] ...
> CIFS: Disconnecting configuration [WinRLM-17] ...
> CIFS: Transferred 0 file(s)
>  
> That’s all no debug or error message, this plugin is not even generating 
> proper logs to show what’s going wrong with my inputs. Attaching screen 
> shot of my job configuration page can anyone let me know if there anyway I 
> can debug where things are going wrong, for convenience my entries are like 
> this:
>  
>  Source Files: ${WORKSPACE}/lib/** [Contains all required jar files]
> Remove prefix: ${WORKSPACE} 
> Remote directory: lib [Subfolder under shared folder]
>  
> I even tried with absolute source path of my artifacts, I am ready to send 
> my job config.xml file of this project which only contains CIFS entry 
>  
>  
> Thanks,
> Jhoom
>

-- 
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/c5f1c9ea-0698-410c-be48-3172ef19e5b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CIFS plugin debug messages

[Pritesh Saharey]

Hi All,
I am using “Publish over CIFS Plugin” 0.3v, I configured itas per documentation 
https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+CIFS+Plugineven Test 
Configuration gives me success messages , I am suing it under Postbuild step in 
job as “Send build artifact to a Windows share” copying is never successfullogs 
just shows:
 
CIFS:Connecting from host [vl-pun-rie-bl47]
CIFS:Connecting with configuration [WinRLM-17] ...
CIFS:Disconnecting configuration [WinRLM-17] ...
CIFS:Transferred 0 file(s)
 
That’s all no debug or error message, this plugin is noteven generating proper 
logs to show what’s going wrong with my inputs.Attaching screen shot of my job 
configuration page can anyone let me know ifthere anyway I can debug where 
things are going wrong, for convenience myentries are like this:
 
 Source Files: ${WORKSPACE}/lib/**[Contains all required jar files]
Remove prefix: ${WORKSPACE} 
Remote directory: lib [Subfolder under shared folder]
 
I even tried with absolute source path of my artifacts, I amready to send my 
job config.xml file of this project which only contains CIFSentry 
 
 
Thanks,
Jhoom

-- 
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/151f35f78cc-239a-f0fe%40webprd-a04.mail.aol.com.
For more options, visit https://groups.google.com/d/optout.

Re: Approaches for sharing workspace in a pipeline

[Baptiste Mathus]

Would be great if y'all around could share the cool things you've done with
workflow in that examples/tutorial repo:
https://github.com/jenkinsci/workflow-examples

Thanks!

2015-12-30 11:26 GMT+01:00 Thomas Goeppel :

> Oh sorry, wrong addressee
>
> %s/John/Martin/ :-)
>
>
> On Wednesday, December 30, 2015 at 11:24:26 AM UTC+1, Thomas Goeppel wrote:
>>
>> Hi John,
>>
> --
> 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/53be2f41-9a45-4af5-a952-c49f53ef94b1%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

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

jenkins

[Eldon Kuzhyelil]

I am using LXC containers and Kubuntu 14.04.
In first container i am using jenkins and in the second container i am using 
git repository.
I have copied public key of first container to second container so that i can 
ssh to second container from first container.
But when i try to build i am getting this error.

ERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException 
:
 Failed to fetch from ssh:///ubuntu@10.0.3.66:/home/ubuntu/gitdir

Please help as i am new to this

-- 
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/488a4cd3-928a-435f-9038-c29ac58965f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Approaches for sharing workspace in a pipeline

[Thomas Goeppel]

Oh sorry, wrong addressee  

%s/John/Martin/ :-)


On Wednesday, December 30, 2015 at 11:24:26 AM UTC+1, Thomas Goeppel wrote:
>
> Hi John,
>

-- 
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/53be2f41-9a45-4af5-a952-c49f53ef94b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Approaches for sharing workspace in a pipeline

[Thomas Goeppel]

Hi John,

your approach sounds interesting. Could you please share some Workflow code 
that shows how you compute the Workspace location, use ws(), and pass 
workspace locations to subsequent jobs? 

When accessing workspaces in Workflow you're also facing the problem of 
concurrent runs. How do you deal with that?

Thanks in advance!

Greetings,
Thomas
 

On Wednesday, December 30, 2015 at 3:11:46 AM UTC+1, Martin d'Anjou wrote:
>
> On Wednesday, December 23, 2015 at 9:45:57 PM UTC-5, John D. Ament wrote:
>>
>> Hi,
>>
>> I was wondering if anyone had any best practices or tips to share on have 
>> a common workspace for a pipeline job.
>>
>
> I use Workflow job definitions, and I compute the location of the 
> workspace in each job of the build chain before the actual build actions 
> take place, using the ws() built step. Subsequent jobs in the build chain 
> use the same workspace (the location can be computed). Subsequent jobs need 
> not to be in the same workflow definition, nor in a formal pipeline (I do 
> not use triggers nor pipeline plugins). I have enough input parameters for 
> the subsequent jobs in the chain to locate the workspace of the previous 
> job. I do not move nor archive data (I have thousands of files and 
> gigabytes of data over NFS so I don't want to spend time moving it or 
> archiving/extracting it).
>

-- 
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/8724e85d-36e2-4e1d-a920-f9047587aada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.