from:"Michael Giroux"

New Git Plugin Feature - configure alias host names

2017-03-07 Thread Michael Giroux

For several years, we have been using Stash to manage our Git repos. The
host name for our server was 'stash.xxx.com'.

Recently we upgraded to the latest version of Bitbucket Server. At the
same time, we upgraded the server hardware, and to avoid confusion that
might occur when users connected to 'stash.xxx.com' and landed in
'Bitbucket Server', we set the host name as 'bitbucket.xxx.com'.

We also configured Bitbucket Server to use a base URL of
'http://bitbucket.xxx.com'.

This had the adverse effect of breaking the Stash Webhook to Jenkins in
that the URL used in the notifyCommit no longer matches any of the jobs in
Jenkins.

ex.
http://jenkins.host.com/git/notifyCommit?url=http://bitbucket.xxx.com/
no longer matches any of the jobs that are configured to fetch from
http://stash.xxx.com/... and we no longer have builds kicked off when code
is pushed to Bitbucket Server.

Maybe it was a mistake to change the base url for Bitbucket Server, but
'bitbucket' seemed more appropriate than 'stash' for access to the UI.

Suggestion:
To deal with this situation, it would be handy if the Git plugin provided a
means to configure host name aliases so that the notifyCommit message would
trigger polling for 'stash.xxx.com' or 'bitbucket.xxx.com'.

Would this be of general interest?

Michael Giroux

--
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/7a78e256-8945-412d-84d3-0f37cea6c6be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is "slave Java"

2016-11-19 Thread Michael Giroux

Thanks for taking the time to answer each of the questions.

We are running Jenkins in JDK 1.8.  The poorly worded error message thought 
makes a lot of sense.  Reading the error message again, I am concluding 
that the build was retried using the default JDK (the one running Jenkins). 
 As such, we ended up building a JDK 1.6 project with JDK 1.8.  The build 
runs because JDK 1.8 can produce byte code for older versions.

Is this the correct group to suggest an improvement to the error message? 
 The message should make it clear that the build is being run by the 
default JRE.

This has been very helpful.  Thank you very much.

Michael

On Saturday, November 19, 2016 at 8:38:05 AM UTC-7, Daniel Beck wrote:
>
>
> > On 18.11.2016, at 18:46, Michael Giroux <mlgi...@gmail.com > 
> wrote: 
> > 
> > Thanks Daniel.  But I'm still not clear on what is going on under the 
> covers.  The job is NOT configured to run on a slave, but the message 
> indicates that the build was retried on a slave.  Is there a default slave 
> that runs on the Jenkins host to support this retry? 
>
> No. Probably just a badly worded message and the assumption based on best 
> practices that builds should run on slaves. 
>
> Same behavior change though -- the configured JDK cannot build the 
> project, so Jenkins will try to use the JRE/JDK that runs Jenkins itself. 
>
> > 1. If the builds will work without being updated, what was the point of 
> upgrading projects to use toolchains? 
>
> You're building using a newer JRE. Builds may fail even though they should 
> succeed in your desired configuration, and vice-versa. 
>
> > 2. has Jenkins taken steps to solve the issue by running these jobs in a 
> slave? 
>
> No, see above. 
>
> > 3. If jenkins has addressed the issue, what is the point of the error 
> message?  It seems to be unnecessary. 
>
> To inform you that possibly undesired magic is happening. 
>
> > 4. Is there a performance issue, or other reason that would justify us 
> continuing the effort to update the remaining (1000+) projects to build w/ 
> JDK 1.8 using toolchains to configure the JDK needed to compile/test the 
> project? 
>
> See above. The project isn't actually built using the JDK you want 
> building the project. 
>
>

-- 
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/fcfc3ae4-9c26-4f82-aa5b-b9d6eeb2173a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is "slave Java"

2016-11-18 Thread Michael Giroux

> Does that help?
Just barely.

Yes it is a Maven project.  It is clear from the execution that the build 
ultimately succeeds.  We are aware of the JDK compatibility issue.  We 
spent a couple of months updating maven projects to configure toolchains in 
the poms.  After investing significant effort to build projects in JDK 1.8 
using toolchains to configure the JDK needed to compile/test, we were 
surprised that jobs that had not been updated still run successfully.  This 
raises a few questions:
1. If the builds will work without being updated, what was the point of 
upgrading projects to use toolchains?
2. has Jenkins taken steps to solve the issue by running these jobs in a 
slave?
3. If jenkins has addressed the issue, what is the point of the error 
message?  It seems to be unnecessary.
4. Is there a performance issue, or other reason that would justify us 
continuing the effort to update the remaining (1000+) projects to build w/ 
JDK 1.8 using toolchains to configure the JDK needed to compile/test the 
project?

If Jenkins is handling the issue, it seems the error message is unnecessary.

On Friday, November 18, 2016 at 12:48:56 PM UTC-7, Mark Bidewell wrote:
>
> In short, Jenkins after a certain point Uses Java 1.7+.  It appears you 
> are using the Maven project type.  This project type injects Jenkins 
> behaviors into the Maven build.  These behaviors must run with Java 1.7+. 
>  The error you are getting is to to Jenkins attempting to use its behaviors 
> with Java 1.6.  In this case the behavior is to run Maven using the JDK on 
> which Jenkins itself is running then set Maven properties for Java to point 
> @ JDK 1.6.
>
> Does that help?
>
> On Friday, November 18, 2016 at 12:46:48 PM UTC-5, Michael Giroux wrote:
>>
>> Thanks Daniel.  But I'm still not clear on what is going on under the 
>> covers.  The job is NOT configured to run on a slave, but the message 
>> indicates that the build was retried on a slave.  Is there a default slave 
>> that runs on the Jenkins host to support this retry?
>>
>> On Friday, November 18, 2016 at 8:46:22 AM UTC-7, Daniel Beck wrote:
>>>
>>>
>>> > On 18.11.2016, at 15:46, Michael Giroux <mlgi...@gmail.com> wrote: 
>>> > 
>>> > Could someone either explain, or point me to documentation that 
>>> explains what is really happening here?  Specifically what does 
>>> > "Retrying with slave Java ..." mean since we do not have a slave named 
>>> "Java". 
>>>
>>> This refers to the Java runtime used to run the slave (now called build 
>>> agent) process. 
>>>
>>>

-- 
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/1c6b2ac5-3643-493e-ac13-fddac2909ee9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is "slave Java"

2016-11-18 Thread Michael Giroux

Thanks Daniel.  But I'm still not clear on what is going on under the 
covers.  The job is NOT configured to run on a slave, but the message 
indicates that the build was retried on a slave.  Is there a default slave 
that runs on the Jenkins host to support this retry?

On Friday, November 18, 2016 at 8:46:22 AM UTC-7, Daniel Beck wrote:
>
>
> > On 18.11.2016, at 15:46, Michael Giroux <mlgi...@gmail.com > 
> wrote: 
> > 
> > Could someone either explain, or point me to documentation that explains 
> what is really happening here?  Specifically what does 
> > "Retrying with slave Java ..." mean since we do not have a slave named 
> "Java". 
>
> This refers to the Java runtime used to run the slave (now called build 
> agent) process. 
>
>

-- 
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/01e4ef8f-38f6-4ad1-9415-0ed0ef68d65c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

What is "slave Java"

2016-11-18 Thread Michael Giroux

We are running Jenkins 2.19.2 with JDK 1.8.
We have maven projects configured to run in older JDKs, and we get the
following message:

ERROR:
ERROR
: Invalid project setup:
hudson/maven/AbstractMavenProcessFactory$ConfigureOriginalJDK : Unsupported
major.minor version 51.0ERROR
:
[JENKINS-18403][JENKINS-28294] JDK 'JDK 1.6' not supported to run Maven
projects.ERROR : Maven
projects have to be launched with a Java version greater or equal to the
minimum version required by the master.ERROR
: Use the Maven JDK
Toolchains (plugin) to build your maven project with an older JDK.ERROR
: Retrying with slave Java
and setting compile/test properties to point to /opt/ci/java/x64/jdk1.6.ERROR
:

The build runs successfully.

We do NOT have a slave named "Java" configured. I am unable to find any
documentation that describes what is really going on here.

Could someone either explain, or point me to documentation that explains what
is really happening here? Specifically what does

"Retrying with slave Java ..." mean since we do not have a slave named "Java".

Michael

--
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/7c5550ae-1642-4077-b2f0-3eefad8990de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to remove plugins that do not appear in plugin management "Installed" tab

2016-11-14 Thread Michael Giroux

We no longer use Cloudbees.  We do not want to re-install them.  We want to 
get ride of them.  Since they do not appear on the installed tab, it seems 
the only option is to manually delete the plugins.  Just confirming this is 
the best approach.

On Friday, November 11, 2016 at 8:54:03 AM UTC-7, Michael Giroux wrote:
>
> Sorry for the previous post.  Subject line was incomplete.
>
> We upgraded from Jenkins 1.609.3 to Jenkins 2.19.2 LTS.  Upgrade went very 
> well, but we are seeing some plugin warnings on the "Manage Plugins" page 
> (see below).  The errors are all related to CloudBees plugins.  There is a 
> link to "correct" the problem, but that takes us to the plugin updates 
> page, and none of these plugins appear.  Nor do they appear in the 
> "installed" tab.
>
> We had CloudBees installed a few years ago, but reverted to Jenkins LTS. 
>  We were not seeing these errors in the 1.609.3 Manage Plugins page, so it 
> has probably been an issue since we uninstalled CloudBees.
>
> QUESTION: How do we eliminate these errors?  Is it safe to delete the 
> plugins from the $JENKINS_HOME/plugins directory?  My thought is:
>
> cd $JENKINS_HOME/plugins
> rm -rf skip-plugin skip-plugin.jpi
>
> and repeat for each plugin.
>
> Is there a better approach?
>
> There are dependency errors loading some plugins:
>
>- CloudBees Skip Next Build Plugin v3.4
>   - Jenkins Enterprise License Entitlement Check v3.1 failed to load. 
>   Fix this plugin first.
>- CloudBees VMWare Autoscaling Plugin v3.10
>   - Jenkins Enterprise License Entitlement Check v3.1.3 failed to 
>   load. Fix this plugin first.
>- CloudBees WikiText Security Plugin v3.2
>   - cloudbees-license v3.1 is missing. To fix, install v3.1 or later.
>   - Jenkins Enterprise License Entitlement Check v3.1 failed to load. 
>   Fix this plugin first.
>- CloudBees Role-Based Access Control Plugin v4.5.1
>   - Jenkins Enterprise License Entitlement Check v5.1 failed to load. 
>   Fix this plugin first.
>- CloudBees Git Validated Merge Plugin v3.12
>   - Jenkins Enterprise License Entitlement Check v4.0 failed to load. 
>   Fix this plugin first.
>- Jenkins Enterprise License Entitlement Check v5.2
>   - cloudbees-license v5.2 is missing. To fix, install v5.2 or later.
>- CloudBees Back-up Plugin v3.5
>   - Jenkins Enterprise License Entitlement Check v3.1.2 failed to 
>   load. Fix this plugin first.
>   - 
>
>

-- 
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/9bf86279-969f-4624-b9cf-76c77222912e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to remove plugins that do not appear in plugin management "Installed" tab

2016-11-11 Thread Michael Giroux

Sorry for the previous post. Subject line was incomplete.

We upgraded from Jenkins 1.609.3 to Jenkins 2.19.2 LTS. Upgrade went very
well, but we are seeing some plugin warnings on the "Manage Plugins" page
(see below). The errors are all related to CloudBees plugins. There is a
link to "correct" the problem, but that takes us to the plugin updates
page, and none of these plugins appear. Nor do they appear in the
"installed" tab.

We had CloudBees installed a few years ago, but reverted to Jenkins LTS.
We were not seeing these errors in the 1.609.3 Manage Plugins page, so it
has probably been an issue since we uninstalled CloudBees.

QUESTION: How do we eliminate these errors? Is it safe to delete the
plugins from the $JENKINS_HOME/plugins directory? My thought is:

cd $JENKINS_HOME/plugins
rm -rf skip-plugin skip-plugin.jpi

and repeat for each plugin.

Is there a better approach?

There are dependency errors loading some plugins:

- CloudBees Skip Next Build Plugin v3.4
- Jenkins Enterprise License Entitlement Check v3.1 failed to load.
Fix this plugin first.
- CloudBees VMWare Autoscaling Plugin v3.10
- Jenkins Enterprise License Entitlement Check v3.1.3 failed to load.
Fix this plugin first.
- CloudBees WikiText Security Plugin v3.2
- cloudbees-license v3.1 is missing. To fix, install v3.1 or later.
- Jenkins Enterprise License Entitlement Check v3.1 failed to load.
Fix this plugin first.
- CloudBees Role-Based Access Control Plugin v4.5.1
- Jenkins Enterprise License Entitlement Check v5.1 failed to load.
Fix this plugin first.
- CloudBees Git Validated Merge Plugin v3.12
- Jenkins Enterprise License Entitlement Check v4.0 failed to load.
Fix this plugin first.
- Jenkins Enterprise License Entitlement Check v5.2
- cloudbees-license v5.2 is missing. To fix, install v5.2 or later.
- CloudBees Back-up Plugin v3.5
- Jenkins Enterprise License Entitlement Check v3.1.2 failed to load.
Fix this plugin first.
-

--
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/544018cd-9883-4e47-aae9-210d80f317fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to solve

2016-11-11 Thread Michael Giroux

QUESTION: How do we eliminate these errors? Is it safe to delete the
plugins from the $JENKINS_HOME/plugins directory? My thought is:

cd $JENKINS_HOME/plugins
rm -rf skip-plugin skip-plugin.jpi

and repeat for each plugin.

Is there a better approach?

There are dependency errors loading some plugins:

--
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/e3ee73d7-1ba9-438d-81de-0aa1463d34f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Global "disable triggers" options

2016-11-07 Thread Michael Giroux

We have a large jenkins configuration with 1700 jobs. We have two use
cases in which the configuration is copied. We make a copy of the
configuration prior to any upgrade:

1. for purposes of testing new version and plugins prior to an upgrade
2. to have a running instance of the previous version to allow "emergency
builds" for projects that will not build in new version after an upgrade.

In both of these use cases, we have two copies of Jenkins running at the
same time (on different ports of course), the old version, and the new
version. In either case, we want to disable the build triggers for one of
the instances. We do not want two copies of jenkins building the same
project based on polling, or due to upstream builds and/or snapshot changes.

We can use "prepare to shutdown" to suspend one instance. But if we cancel
shutdown to allow a specific build to be run, the flood gates open.

It would be helpful if there was an option to allow manual builds even
when "prepare to shutdown" is in effect. Or, as the subject line suggests,
an option to disable triggers. Such an option should have an initial state
set by a system property allowing us to launch Jenkins with the option
initially on or off.

Similar requests have been made previously:
http://jenkins-ci.361315.n4.nabble.com/Suspend-Plugin-td1599530.html
http://stackoverflow.com/questions/1299180/can-i-disable-hudsons-automatic-scheduled-builds-all-at-once

I would be interested in hearing how other users handle this case,
especially case #2 in which we wish to have the old instance of Jenkins
available to run builds that might not execute in the new version.

Michael

--
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/ee104f05-9679-4111-8c5b-33e4a3a6a986%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Collapsing Console Sections not parsing console in Jenkins 2.7.4

2016-09-14 Thread Michael Giroux

I've installed the Collapsing Console Sections plugin in Jenkins 2.7.4.

I configured a couple of sections to identify SCM checkout and the start of 
a maven build.

After running a job, the console output does not contain any sections.  I 
see no options on job configuration to activate the plugin for a specific 
job, so I'm assuming it is a global configuration, but I'm not seeing the 
sections on any job.

What am I doing wrong?

Michael

-- 
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/8fa53cfe-9906-415c-a91b-f1050156b560%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-users@googlegroups.com

2016-09-14 Thread Michael Giroux



Job is a simple maven project.  Project builds successfully from command line.


Let me know what additional info you might want to look at this.


ERROR: Processing failed due to a bug in the code. Please report this to 
jenkinsci-us...@googlegroups.comjava.lang.NullPointerException 
  
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:305)
 

at hudson.maven.ProcessCache.get(ProcessCache.java:236) 

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

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

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

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

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

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

project=hudson.maven.MavenModuleSet@9b0e792[Devops Test]
project.getModules()=[hudson.maven.MavenModule@56511348[Devops 
Test/choicehotels.devops:test][Devops 
Test/choicehotels.devops:test][relativePath:]]

-- 
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/fcb85232-1e88-4fc9-96d1-577c79488a43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sonarqube plugin with maven project

2016-09-13 Thread Michael Giroux

Our site has a single sonarqube server.  Our builds have been configured as 
maven projects, and run the sonarqube plugin as a post build publisher.

Not sure of the rationale for this approach.  I have added the sonar:sonar goal 
to a maven build and get the same result aa jobs that use sonarqube plugin as a 
separate step.

is there a compelling reason that I would want to use the sonarqube plugin 
instead of running sonar in the primary build?

Michael

-- 
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/60d2ee44-7019-4372-aa85-2421b32059e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Build failure with Exception in thread "main" java.lang.ClassNotFoundException: hudson.remoting.Launcher

2016-08-30 Thread Michael Giroux

Disconnecting the slave, and then reconnecting solved the problem for us. 
 This causes jenkins to refresh the runtime jars on the slave.

On Wednesday, June 17, 2015 at 12:55:57 PM UTC-7, 1eyed...@gmail.com wrote:
>
> We ultimately got our server administrator to restart Jenkins, and now the 
> builds are working.  If anybody out there has this same issue - try that 
> first!
>
> On Wednesday, June 17, 2015 at 9:31:10 AM UTC-6, 1eyed...@gmail.com wrote:
>>
>> Hello,
>>
>> I have been searching for an answer to this problem, and what I've found 
>> so far refers to slaves and other terminology I don't know.  I am not an 
>> administrator, just someone who uses Jenkins to run builds for our Java 
>> projects.  We have one project that uses Maven, and we have just recently 
>> started getting errors that show:
>>
>>
>> [EnvInject] - Variables injected successfully.
>> Parsing POMs
>> Discovered a new module com.bc.woodCustomer:WoodCustomerBuild Wood Customer 
>> Build Project (Maven Build)
>> Discovered a new module com.bc.woodCustomer:WoodCustomerEar Wood Customer Ear
>> Discovered a new module com.bc.woodCustomer:WoodCustomerWeb Wood Customer Web
>> Modules changed, recalculating dependency graph
>> [WoodCustomerBuild] $ /opt/java//bin/java -cp 
>> /opt/jenkins/plugins/maven-plugin/WEB-INF/lib/maven31-agent-1.4.jar:/opt/maven/boot/plexus-classworlds-2.5.1.jar:/opt/maven/conf/logging
>>  jenkins.maven3.agent.Maven31Main /opt/maven 
>> /tmp/jetty-0.0.0.0-8090-jenkins.war--any-/webapp/WEB-INF/lib/remoting-2.32.jar
>>  /opt/jenkins/plugins/maven-plugin/WEB-INF/lib/maven31-interceptor-1.4.jar 
>> /opt/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.4.jar
>>  42886
>> Exception in thread "main" java.lang.ClassNotFoundException: 
>> hudson.remoting.Launcher
>>  at 
>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
>>  at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
>>  at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
>>  at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
>>  at jenkins.maven3.agent.Maven31Main.main(Maven31Main.java:138)
>>  at jenkins.maven3.agent.Maven31Main.main(Maven31Main.java:67)
>> ERROR: Failed to parse POMsjava.net.SocketException 
>> : 
>> Connection reset
>>  at java.net.SocketInputStream.read(SocketInputStream.java:189) 
>> 
>>  at java.net.SocketInputStream.read(SocketInputStream.java:121) 
>> 
>>  at java.io.FilterInputStream.read(FilterInputStream.java:133) 
>> 
>>  at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) 
>> 
>>  at java.io.BufferedInputStream.read(BufferedInputStream.java:254) 
>> 
>>  at 
>> hudson.remoting.ClassicCommandTransport.create(ClassicCommandTransport.java:133)
>>  
>> 
>>  at hudson.remoting.Channel.(Channel.java:406) 
>> 
>>  at hudson.remoting.Channel.(Channel.java:402) 
>> 
>>  at hudson.remoting.Channel.(Channel.java:363) 
>> 
>>  at hudson.remoting.Channel.(Channel.java:359) 
>> 
>>  at hudson.remoting.Channel.(Channel.java:355) 
>> 
>>  at hudson.slaves.Channels$1.(Channels.java:71) 
>> 
>>  at hudson.slaves.Channels.forProcess(Channels.java:71) 
>> 
>>  at 
>> hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:252)
>>  
>> 
>>  at hudson.maven.ProcessCache.get(ProcessCache.java:235) 
>> 
>>  at 
>>

Git plugin notifyCommit url = localhost does not match jobs

2016-07-22 Thread Michael Giroux

I have configured Jenkins job to use git url: 
http://stash.server/scm/prj/repo.git

Our repositories reside in Stash, and using the Stash Webhook to Jenkins. 
 The default url for the notifyCommit is http://localhost/scm/prj/repo.git. 
 

Then curl 
http://jenkins.server/git/notifyCommit?url=http://localhost/scm/prj/repo.git
== no jobs found

curl 
http://jenkins.server/git/notifytCommit?url=http://stash.server/scm/prj/repo.git
== triggers the job

For some reason, I have the impression that the git plugin would ignore the 
host name and port when processing notifyCommit messages.  Is this correct?


Michael

-- 
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/cb78bb2b-1209-49b7-832a-e95f470a62fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to prevent Git plugin from setting GIT_BRANCH to origin/pull-requests/*

2016-07-14 Thread Michael Giroux

Problem solved more-or-less.

The Git plugin was configured with  
+refs/pull-requests/*/from:refs/remotes/origin/pull-requests/*/from.

I removed this configuration and no longer have the extra branches. 

I'm unable to find any documentation that describes this refspec.  It 
appears to be something specific to Stash, but I'm not able to find any 
documentation.  Would appreciate any links.

Michael

On Wednesday, July 13, 2016 at 8:58:52 AM UTC-7, Michael Giroux wrote:
>
> This question involves Git plugin, Stash, and SonarQube integration, so 
> there are multiple bits that we need to coordinate.
>
>
>1. We are using Stash with the Jenkins Web Hook to trigger builds when 
>developers push code to a branch.
>2. The build checks the code out to a local branch using the remote 
>branch name.
>3. The build runs sonar analysis and sets the sonar.branch property to 
>the local branch name.
>4. The team creates a pull request for the branch.
>5. When the pull request is merged, the branch in Stash is deleted, 
>and the SonarQube project for the branch is deleted.
>
> In some cases, what we see is a bit different.  By the time the jenkins 
> job is executed for a commit, the pull request has already been created. 
>  In this case, when the Git plugin pulls the code and does the checkout on 
> the commit, there are two branches, the one the developer pushed, and the 
> one Stash created for the PR.  Git plugin is setting the GIT_BRANCH 
> property to origin/pull-requests/23/from  instead of 
> origin/feature/branchname.
>
> In this case, when the build runs, the sonar.branch ends up being set to 
> feature-branchname and we end up with a SonarQube project named 
> "groupId:artifactid:pull-requests-23-from"  instead of 
> "groupId:artifactId:feature-branchname".  
>
> Now, when the team merges the pull request in Stash, the options to delete 
> the branch and cleanup the SonarQube project are selected.  The Stash 
> branch "feature/branchname" is deleted, but the SonarQube project is not 
> deleted because the SonarQube project name (...:pull-requests-23-from) does 
> not match the Stash branch name being deleted.
>
> The problem seems to be caused by the fact that the commit has two 
> branches associated with it.  From our perspective, the easiest solution is 
> to force Git to use the branch name that was pushed by the developer, and 
> to ignore pull-request type branches.
> "Checking out Revision c3db27a8df3b68e927af8c5e01791bc270e7a90b 
> (origin/pull-requests/6737/from, 
> origin/DE0-TA0-switchCaseLines+addPrivateConstructor)"
>
> "GIT_BRANCH=origin/pull-requests/6737/from"
>
>
> How can we prevent Git plugin from using the pull-requests branch name?
>
> Michael
>
>

-- 
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/871c678f-027f-4c51-9598-cab449deafde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Job config updated by Git Parameter plugin

2016-06-04 Thread Michael Giroux

Has anyone else seen this behavior?  My job configuration history contains 
entries for the Git Parameter Plugin when we do not make changes to this 
plugin.  We see a new value for the UUID element of the plugin, but that is 
not something we have control of.  This clutters the configuration history 
with entries unrelated to physical users.

If this is not a defect, then perhaps there should be an option to exclude, 
or at least filter, the config history to only entries resulting from 
actual user changes.  It is easy enough to ignore entries by user SYSTEM, 
but when we get multiple changes resulting from a user making changes, we 
want to exclude config history that is injected by plugins unrelated to the 
actual change.

On Wednesday, June 1, 2016 at 11:34:52 AM UTC-7, Michael Giroux wrote:
>
> Jenkins version: 1.609.3
> Git Parameter plugin: 0.4
>
> I'm trying to review job configuration history, but I'm seeing several 
> configuration changes where the only change is the  entry in the 
> GitParameterDefinition node.
>
> I know that nobody has changed the  entry manually because it does 
> not appear in the configure UI, so it appears to be updated by the plugin 
> itself.
>
> It seems strange to me that this data is persisted to the configuration 
> since it is not configurable.  It also seems strange to me that the data 
> would be persisted when the user is not making changes to the Git Parameter 
> plugin details.
>
> From the perspective of one trying to see configuration changes introduced 
> by humans, this really seems like a defect.
>
> Is there a way to prevent changes in UUID from causing configuration 
> updates?
>
> Michael Giroux
>

-- 
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/3f9856bf-df78-4e0d-b45f-f17ebac0a757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Git Parameter 0.5.2-SNAPSHOT build errors

2016-06-01 Thread Michael Giroux

Just pulled latest source for Git Parameter plugin from github, and have 4 
java errors due to undefined java.nio.file package references.

java.nio.file is a new package in JDK 1.7.

The effective pom for Git Parameter 0.5.2-SNAPSHOT is resolving source and 
target for the maven-compiler-plugin to 1.6.


-- 
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/c64b2445-500e-4b4d-92db-eeae0114e332%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Job config updated by Git Parameter plugin

2016-06-01 Thread Michael Giroux

Jenkins version: 1.609.3
Git Parameter plugin: 0.4

I'm trying to review job configuration history, but I'm seeing several 
configuration changes where the only change is the  entry in the 
GitParameterDefinition node.

I know that nobody has changed the  entry manually because it does 
not appear in the configure UI, so it appears to be updated by the plugin 
itself.

It seems strange to me that this data is persisted to the configuration 
since it is not configurable.  It also seems strange to me that the data 
would be persisted when the user is not making changes to the Git Parameter 
plugin details.

>From the perspective of one trying to see configuration changes introduced 
by humans, this really seems like a defect.

Is there a way to prevent changes in UUID from causing configuration 
updates?

Michael Giroux

-- 
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/5cf12bc3-46e5-4480-bd95-6decc795e7e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git Polling initiated by notifyCommit failing on remote since version 2.4.4

2016-03-31 Thread Michael Giroux

The git client 1.19.6 has been running since 3/22/2016 on the master 
without errors, so it seems the feature to detect the jdk works as desired, 
at least when run on the master.  The class version issue only shows up 
when we configure the job to run on a slave,  It is also interesting that 
the problem only shows up on the first execution on the slave.  I got the 
error two ways:
1. deleted all jar files in .jenkins/cache/jars, then disabled and 
relaunched the slave.  then kicked off a build.  The first build got the 
class version error.
2. modified an existing job to build on a different slave, one it had not 
built on before.  Again, the first build got the class version error.

For both cases, once the build had been attempted once, subsequent builds 
get the NoClassDefFoundError.

Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
org.eclipse.jgit.util.FS
at 
org.eclipse.jgit.lib.BaseRepositoryBuilder.setupWorkTree(BaseRepositoryBuilder.java:620)
at 
org.eclipse.jgit.lib.BaseRepositoryBuilder.setup(BaseRepositoryBuilder.java:556)
at org.eclipse.jgit.sto


This leads me to think that for the first build, something is running on master 
that does not run for subsequent builds once the workspace has been created on 
the slave.  Just throwing that out since I have no other explanation for the 
class version errors.


On Thursday, March 31, 2016 at 12:43:07 PM UTC-7, Mark Waite wrote:
>
> You're correct that git client plugin 1.19.6 includes a jar file that is 
> compiled with JDK 7.  The JGit support for symlinks requires it.  However, 
> that jar file should not be loaded if it is running on a Java 6 
> environment.  The JGit implementation is designed to allow the Java 7 
> module to only be loaded if it detects it is running on JDK 7 or newer.
>
> I definitely do not see class version errors in a JDK 1.6 environment.  I 
> configured a Docker instance yesterday with Java 6 master, Java 7 slaves, 
> and confirmed that I could clone to both the master and the slaves using 
> Git plugin 2.4.4 and Git client plugin 1.19.6.
>
> See [
> https://github.com/jenkinsci/git-client-plugin/commit/cce0f8b30373ebce707aaf8457640cea7fe4489d]
>  
> for the details
>
> On Thu, Mar 31, 2016 at 1:32 PM Michael <mlgi...@gmail.com > 
> wrote:
>
>> That is a shame.  I wont be able to move up to Git plugin 2.4.4. until 
>> the git client issue is resolve.  I realize you cannot reproduce, and I’m 
>> about to leave for two weeks of well deserved vacation, so I won’t be able 
>> to pick this up again for a while, but if someone else starts reporting 
>> issues, keep my results in mind.
>>
>> Also, the git client seems to have one or more modules compiled with jdk 
>> 1.7.  Perhaps one or more of the dependencies. Version 1.19.6 is throwing 
>> class version errors in a JDK 1.6 jenkins.  I did not see any mention of 
>> this in docs, so I think this is an issue.
>>
>> Michael
>>
>>
>> On Mar 31, 2016, at 12:24 PM, Mark Waite <mark.ea...@gmail.com 
>> > wrote:
>>
>> Git plugin 2.4.0 requires at least git client plugin 1.18.0.
>>
>> Git plugin 2.4.4 requires at least git client plugin 1.19.6.
>>
>> Mark Waite
>>
>> On Thu, Mar 31, 2016 at 1:22 PM Michael Giroux <mlgi...@gmail.com 
>> > wrote:
>>
>>> Reverted Git Client to 1.18.0 and problem is resolved.   The 
>>> notifyCommit no longer faults, and the job is running on the slave.
>>>
>>> Current config: Git plugin 2.4.0,  Git client 1.18.0.
>>>
>>> Michael
>>>
>>> On Thursday, March 31, 2016 at 11:18:54 AM UTC-7, Mark Waite wrote:
>>>
>>>> I don't know how to duplicate either your issue or JENKINS-33907.  I 
>>>> installed a Jenkins 1.609.3 last night with Java 6, then used a slave with 
>>>> Java 7, and confirmed that I was able to checkout on the master and the 
>>>> slave using the command line git implementation with git plugin 2.4.4 and 
>>>> git client plugin 1.19.6.
>>>>
>>>> I confirmed that the referenced class is included in one of the jar 
>>>> files packaged with git client plugin 1.19.6.
>>>>
>>>> Have you been able to duplicate the problem on a fresh installation?
>>>>
>>>> Mark Waite
>>>>
>>>> On Thu, Mar 31, 2016 at 10:33 AM Michael Giroux <mlgi...@gmail.com> 
>>>> wrote:
>>>>
>>> Seems another user has similar issue.  
>>>>> https://issues.jenkins-ci.org/browse/JENKINS-33907
>>>>>
>>>>> That is not exactly the same, but I've s

Re: Git Polling initiated by notifyCommit failing on remote since version 2.4.4

2016-03-31 Thread Michael Giroux

Reverted Git Client to 1.18.0 and problem is resolved.   The notifyCommit 
no longer faults, and the job is running on the slave.

Current config: Git plugin 2.4.0,  Git client 1.18.0.

Michael

On Thursday, March 31, 2016 at 11:18:54 AM UTC-7, Mark Waite wrote:
>
> I don't know how to duplicate either your issue or JENKINS-33907.  I 
> installed a Jenkins 1.609.3 last night with Java 6, then used a slave with 
> Java 7, and confirmed that I was able to checkout on the master and the 
> slave using the command line git implementation with git plugin 2.4.4 and 
> git client plugin 1.19.6.
>
> I confirmed that the referenced class is included in one of the jar files 
> packaged with git client plugin 1.19.6.
>
> Have you been able to duplicate the problem on a fresh installation?
>
> Mark Waite
>
> On Thu, Mar 31, 2016 at 10:33 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Seems another user has similar issue.  
>> https://issues.jenkins-ci.org/browse/JENKINS-33907
>>
>> That is not exactly the same, but I've seen the same issue, and it could 
>> be related to my issue.
>>
>>
>> On Tuesday, March 29, 2016 at 11:44:15 AM UTC-7, Michael Giroux wrote:
>>>
>>> Since updating to Git plugin version 2.4.4, our jobs that execute on a 
>>> remote slave are failing.  The full stack trace from the polling log is 
>>> below.
>>>
>>>
>>> Do we need to install additional software on the slaves to accommodate the 
>>> update?
>>>
>>>
>>> Michael Giroux
>>>
>>>
>>> Polling for changes in
>>> ERROR: Failed to record SCM polling for 
>>> hudson.model.FreeStyleProject@22b7f935[CHCOM WEB Replatform - Pull 
>>> Requests]hudson.remoting.RemotingSystemException 
>>> <http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RemotingSystemException>:
>>>  java.io.IOException: Remote call on aws-slave-002-v2 failed
>>> at 
>>> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:266)
>>>  
>>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.RemoteInvocationHandler.invoke=method>
>>> at com.sun.proxy.$Proxy79.getRemoteBranches(Unknown Source)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl.getRemoteBranches(RemoteGitImpl.java:485)
>>> at 
>>> hudson.plugins.git.util.GitUtils.getAllBranchRevisions(GitUtils.java:47)
>>> at 
>>> hudson.plugins.git.util.DefaultBuildChooser.getAdvancedCandidateRevisions(DefaultBuildChooser.java:204)
>>> at 
>>> hudson.plugins.git.util.DefaultBuildChooser.getCandidateRevisions(DefaultBuildChooser.java:53)
>>> at 
>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:706)
>>> at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:571)
>>> at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:380)
>>> at hudson.scm.SCM.poll(SCM.java:397)
>>> at 
>>> hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1471)
>>> at hudson.model.AbstractProject._poll(AbstractProject.java:1442)
>>> at hudson.model.AbstractProject.poll(AbstractProject.java:1353)
>>> at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510)
>>> at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539)
>>> at 
>>> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>>> at 
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
>>> at java.lang.Thread.run(Thread.java:682)
>>> Caused by: java.io.IOException: Remote call on aws-slave-002-v2 failed
>>> at hudson.remoting.Channel.call(Channel.java:786)
>>> at 
>>> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250)
>>> ... 21 more
>>> Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
>>> org.eclipse.jgit.util.FS
>>> at 
>>> org.eclipse.jgit.lib.BaseRepositoryBuilder.setupWorkTree(BaseRepositoryBuilder.java:620)
>>> at 
>>> org.ecl

Re: Git Polling initiated by notifyCommit failing on remote since version 2.4.4

2016-03-31 Thread Michael Giroux

In the interest of determining if the issue is related to the git client 
plugin,  I would like to roll back to the previous version.  We currently 
have 1.19.6 installed.  Our previous version was 1.18.0.

Should this combination work?  Git Plugin 2.4.0 (or 2.4.4) with Git Client 
1.18.0.

Michael

On Thursday, March 31, 2016 at 11:18:54 AM UTC-7, Mark Waite wrote:
>
> I don't know how to duplicate either your issue or JENKINS-33907.  I 
> installed a Jenkins 1.609.3 last night with Java 6, then used a slave with 
> Java 7, and confirmed that I was able to checkout on the master and the 
> slave using the command line git implementation with git plugin 2.4.4 and 
> git client plugin 1.19.6.
>
> I confirmed that the referenced class is included in one of the jar files 
> packaged with git client plugin 1.19.6.
>
> Have you been able to duplicate the problem on a fresh installation?
>
> Mark Waite
>
> On Thu, Mar 31, 2016 at 10:33 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Seems another user has similar issue.  
>> https://issues.jenkins-ci.org/browse/JENKINS-33907
>>
>> That is not exactly the same, but I've seen the same issue, and it could 
>> be related to my issue.
>>
>>
>> On Tuesday, March 29, 2016 at 11:44:15 AM UTC-7, Michael Giroux wrote:
>>>
>>> Since updating to Git plugin version 2.4.4, our jobs that execute on a 
>>> remote slave are failing.  The full stack trace from the polling log is 
>>> below.
>>>
>>>
>>> Do we need to install additional software on the slaves to accommodate the 
>>> update?
>>>
>>>
>>> Michael Giroux
>>>
>>>
>>> Polling for changes in
>>> ERROR: Failed to record SCM polling for 
>>> hudson.model.FreeStyleProject@22b7f935[CHCOM WEB Replatform - Pull 
>>> Requests]hudson.remoting.RemotingSystemException 
>>> <http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RemotingSystemException>:
>>>  java.io.IOException: Remote call on aws-slave-002-v2 failed
>>> at 
>>> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:266)
>>>  
>>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.RemoteInvocationHandler.invoke=method>
>>> at com.sun.proxy.$Proxy79.getRemoteBranches(Unknown Source)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl.getRemoteBranches(RemoteGitImpl.java:485)
>>> at 
>>> hudson.plugins.git.util.GitUtils.getAllBranchRevisions(GitUtils.java:47)
>>> at 
>>> hudson.plugins.git.util.DefaultBuildChooser.getAdvancedCandidateRevisions(DefaultBuildChooser.java:204)
>>> at 
>>> hudson.plugins.git.util.DefaultBuildChooser.getCandidateRevisions(DefaultBuildChooser.java:53)
>>> at 
>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:706)
>>> at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:571)
>>> at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:380)
>>> at hudson.scm.SCM.poll(SCM.java:397)
>>> at 
>>> hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1471)
>>> at hudson.model.AbstractProject._poll(AbstractProject.java:1442)
>>> at hudson.model.AbstractProject.poll(AbstractProject.java:1353)
>>> at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510)
>>> at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539)
>>> at 
>>> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>>> at 
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
>>> at java.lang.Thread.run(Thread.java:682)
>>> Caused by: java.io.IOException: Remote call on aws-slave-002-v2 failed
>>> at hudson.remoting.Channel.call(Channel.java:786)
>>> at 
>>> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250)
>>> ... 21 more
>>> Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
>>> org.eclipse.jgit.util.FS
>>> at 
>>> org.eclipse.jgit.lib.BaseRepositoryBuilder.setupWorkTree(B

Re: Git Polling initiated by notifyCommit failing on remote since version 2.4.4

2016-03-31 Thread Michael Giroux

gin 2.4.4 and 
> git client plugin 1.19.6.
>
> I confirmed that the referenced class is included in one of the jar files 
> packaged with git client plugin 1.19.6.
>
> Have you been able to duplicate the problem on a fresh installation?
>
> Mark Waite
>
> On Thu, Mar 31, 2016 at 10:33 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Seems another user has similar issue.  
>> https://issues.jenkins-ci.org/browse/JENKINS-33907
>>
>> That is not exactly the same, but I've seen the same issue, and it could 
>> be related to my issue.
>>
>>
>> On Tuesday, March 29, 2016 at 11:44:15 AM UTC-7, Michael Giroux wrote:
>>>
>>> Since updating to Git plugin version 2.4.4, our jobs that execute on a 
>>> remote slave are failing.  The full stack trace from the polling log is 
>>> below.
>>>
>>>
>>> Do we need to install additional software on the slaves to accommodate the 
>>> update?
>>>
>>>
>>> Michael Giroux
>>>
>>>
>>> Polling for changes in
>>> ERROR: Failed to record SCM polling for 
>>> hudson.model.FreeStyleProject@22b7f935[CHCOM WEB Replatform - Pull 
>>> Requests]hudson.remoting.RemotingSystemException 
>>> <http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RemotingSystemException>:
>>>  java.io.IOException: Remote call on aws-slave-002-v2 failed
>>> at 
>>> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:266)
>>>  
>>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.RemoteInvocationHandler.invoke=method>
>>> at com.sun.proxy.$Proxy79.getRemoteBranches(Unknown Source)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl.getRemoteBranches(RemoteGitImpl.java:485)
>>> at 
>>> hudson.plugins.git.util.GitUtils.getAllBranchRevisions(GitUtils.java:47)
>>> at 
>>> hudson.plugins.git.util.DefaultBuildChooser.getAdvancedCandidateRevisions(DefaultBuildChooser.java:204)
>>> at 
>>> hudson.plugins.git.util.DefaultBuildChooser.getCandidateRevisions(DefaultBuildChooser.java:53)
>>> at 
>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:706)
>>> at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:571)
>>> at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:380)
>>> at hudson.scm.SCM.poll(SCM.java:397)
>>> at 
>>> hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1471)
>>> at hudson.model.AbstractProject._poll(AbstractProject.java:1442)
>>> at hudson.model.AbstractProject.poll(AbstractProject.java:1353)
>>> at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510)
>>> at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539)
>>> at 
>>> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>>> at 
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
>>> at java.lang.Thread.run(Thread.java:682)
>>> Caused by: java.io.IOException: Remote call on aws-slave-002-v2 failed
>>> at hudson.remoting.Channel.call(Channel.java:786)
>>> at 
>>> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250)
>>> ... 21 more
>>> Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
>>> org.eclipse.jgit.util.FS
>>> at 
>>> org.eclipse.jgit.lib.BaseRepositoryBuilder.setupWorkTree(BaseRepositoryBuilder.java:620)
>>> at 
>>> org.eclipse.jgit.lib.BaseRepositoryBuilder.setup(BaseRepositoryBuilder.java:556)
>>> at 
>>> org.eclipse.jgit.storage.file.FileRepositoryBuilder.build(FileRepositoryBuilder.java:92)
>>> at 
>>> org.eclipse.jgit.storage.file.FileRepositoryBuilder.create(FileRepositoryBuilder.java:110)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRepository(CliGitAPIImpl.java:2312)
>>> at hudson.plugins.git.GitAPI.getRepository(GitAPI.java:269)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteB

Re: Git Polling initiated by notifyCommit failing on remote since version 2.4.4

2016-03-31 Thread Michael Giroux

Seems another user has similar issue. 
 https://issues.jenkins-ci.org/browse/JENKINS-33907

That is not exactly the same, but I've seen the same issue, and it could be 
related to my issue.

On Tuesday, March 29, 2016 at 11:44:15 AM UTC-7, Michael Giroux wrote:
>
> Since updating to Git plugin version 2.4.4, our jobs that execute on a remote 
> slave are failing.  The full stack trace from the polling log is below.
>
>
> Do we need to install additional software on the slaves to accommodate the 
> update?
>
>
> Michael Giroux
>
>
> Polling for changes in
> ERROR: Failed to record SCM polling for 
> hudson.model.FreeStyleProject@22b7f935[CHCOM WEB Replatform - Pull 
> Requests]hudson.remoting.RemotingSystemException 
> <http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RemotingSystemException>:
>  java.io.IOException: Remote call on aws-slave-002-v2 failed
>   at 
> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:266)
>  
> <http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.RemoteInvocationHandler.invoke=method>
>   at com.sun.proxy.$Proxy79.getRemoteBranches(Unknown Source)
>   at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl.getRemoteBranches(RemoteGitImpl.java:485)
>   at 
> hudson.plugins.git.util.GitUtils.getAllBranchRevisions(GitUtils.java:47)
>   at 
> hudson.plugins.git.util.DefaultBuildChooser.getAdvancedCandidateRevisions(DefaultBuildChooser.java:204)
>   at 
> hudson.plugins.git.util.DefaultBuildChooser.getCandidateRevisions(DefaultBuildChooser.java:53)
>   at 
> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:706)
>   at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:571)
>   at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:380)
>   at hudson.scm.SCM.poll(SCM.java:397)
>   at 
> hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1471)
>   at hudson.model.AbstractProject._poll(AbstractProject.java:1442)
>   at hudson.model.AbstractProject.poll(AbstractProject.java:1353)
>   at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510)
>   at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539)
>   at 
> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
>   at java.lang.Thread.run(Thread.java:682)
> Caused by: java.io.IOException: Remote call on aws-slave-002-v2 failed
>   at hudson.remoting.Channel.call(Channel.java:786)
>   at 
> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250)
>   ... 21 more
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
> org.eclipse.jgit.util.FS
>   at 
> org.eclipse.jgit.lib.BaseRepositoryBuilder.setupWorkTree(BaseRepositoryBuilder.java:620)
>   at 
> org.eclipse.jgit.lib.BaseRepositoryBuilder.setup(BaseRepositoryBuilder.java:556)
>   at 
> org.eclipse.jgit.storage.file.FileRepositoryBuilder.build(FileRepositoryBuilder.java:92)
>   at 
> org.eclipse.jgit.storage.file.FileRepositoryBuilder.create(FileRepositoryBuilder.java:110)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRepository(CliGitAPIImpl.java:2312)
>   at hudson.plugins.git.GitAPI.getRepository(GitAPI.java:269)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteBranches(CliGitAPIImpl.java:1858)
>   at hudson.plugins.git.GitAPI.getRemoteBranches(GitAPI.java:212)
>   at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
>   at 
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
>   at 
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:121)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:49)
>   at hudson.remoting.Request$2.run(Request.java:326)
>   at 
> hudson.remoting.InterceptingExecutorService$1.call(Intercepting

Git Polling initiated by notifyCommit failing on remote since version 2.4.4

2016-03-29 Thread Michael Giroux



Since updating to Git plugin version 2.4.4, our jobs that execute on a remote 
slave are failing.  The full stack trace from the polling log is below.


Do we need to install additional software on the slaves to accommodate the 
update?


Michael Giroux


Polling for changes in
ERROR: Failed to record SCM polling for 
hudson.model.FreeStyleProject@22b7f935[CHCOM WEB Replatform - Pull 
Requests]hudson.remoting.RemotingSystemException 
<http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RemotingSystemException>:
 java.io.IOException: Remote call on aws-slave-002-v2 failed
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:266)
 
<http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.RemoteInvocationHandler.invoke=method>
at com.sun.proxy.$Proxy79.getRemoteBranches(Unknown Source)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl.getRemoteBranches(RemoteGitImpl.java:485)
at 
hudson.plugins.git.util.GitUtils.getAllBranchRevisions(GitUtils.java:47)
at 
hudson.plugins.git.util.DefaultBuildChooser.getAdvancedCandidateRevisions(DefaultBuildChooser.java:204)
at 
hudson.plugins.git.util.DefaultBuildChooser.getCandidateRevisions(DefaultBuildChooser.java:53)
at 
hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:706)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:571)
at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:380)
at hudson.scm.SCM.poll(SCM.java:397)
at 
hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1471)
at hudson.model.AbstractProject._poll(AbstractProject.java:1442)
at hudson.model.AbstractProject.poll(AbstractProject.java:1353)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539)
at 
hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:682)
Caused by: java.io.IOException: Remote call on aws-slave-002-v2 failed
at hudson.remoting.Channel.call(Channel.java:786)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250)
... 21 more
Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
org.eclipse.jgit.util.FS
at 
org.eclipse.jgit.lib.BaseRepositoryBuilder.setupWorkTree(BaseRepositoryBuilder.java:620)
at 
org.eclipse.jgit.lib.BaseRepositoryBuilder.setup(BaseRepositoryBuilder.java:556)
at 
org.eclipse.jgit.storage.file.FileRepositoryBuilder.build(FileRepositoryBuilder.java:92)
at 
org.eclipse.jgit.storage.file.FileRepositoryBuilder.create(FileRepositoryBuilder.java:110)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRepository(CliGitAPIImpl.java:2312)
at hudson.plugins.git.GitAPI.getRepository(GitAPI.java:269)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteBranches(CliGitAPIImpl.java:1858)
at hudson.plugins.git.GitAPI.getRemoteBranches(GitAPI.java:212)
at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to aws-slave-002-v2(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1413)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:778)
... 22 m

Re: One CI job for 4 branches

2016-03-25 Thread Michael Giroux

If you have created a post-update hook on the remote repository to notify 
Jenkins when a push occurs, you might consider configuration as:
Branch to build: **

Checkout to specific local branch: **  (requires Git plugin 2.4.4)

Build Triggers: Poll SCM but leave the schedule blank.  The job will only 
be scheduled if the post-update hook sends a push notification as described 
here: 
https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository

This configuration will schedule a build whenever a push to the remote 
takes place.

Pro:  single jenkins job builds any branch when it is pushed to the remote

Con: build history has mixed branches.  See earlier comment from Mark 
Waite.  

On Thursday, March 24, 2016 at 8:58:52 AM UTC-7, builderj wrote:
>
> Hello experts
>
> I'm just wondering if there is a way to set up ONE CI build job in Jenkins 
> for 4 different branches. 
>
> Here is the scenario. Dev team will be working on 4 different feature 
> branches and check in changes regularly. So the parent CI job should looks 
> for changes in all the 4 branches and trigger the build for the branches 
> where changes were checked in.
>
> Appreciate any help.
>
> Thanks in advance.
>

-- 
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/6dbdb120-b9b6-4883-943e-f9d2dbc6ba74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Git Plugin GIT_LOCAL_BRANCH environment variable implemented

2016-03-25 Thread Michael Giroux

There have been a couple of requests for an environment variable that
publishes the local branch name. The current version of the Git Plugin has
a new feature that targets Maven release builds, but can be leveraged by
other builds.

The maven release plugin pushes a commit to git using the local branch name
as:
git push origin local-branch:local-branch

The maven-release-plugin relies on the local branch name being the same as
the remote branch name. To facilitate this, the Git plugin version 2.4.4
has a new feature. You can configure the "checkout to specific local
branch" behaviour as null (empty string) or ** (star star) to indicate that
you want the code checked out to a local branch using the remote branch
name.
origin/master checked out to local branch master
origin/my-new-feature checked out to local branch my-new-feature.

In addition, when the "checkout to specific local branch" behaviour is
configured, a new environment variable GIT_LOCAL_BRANCH is published. If
the behaviour is configured as null or **, the property will contain the
resulting local branch name sans the remote name.

This new functionality has not been described in the Git Plugin
documentation yet, perhaps waiting for some positive feedback. I'm using
it quite successfully.

Michael

--
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/046e261b-f110-48bb-8af7-161e64c0bfa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Enhancing LocalBranch to support maven release builds

2016-03-12 Thread Michael Giroux

I posted this topic to the Jenkins Developers group 
(https://groups.google.com/forum/?utm_medium=email_source=footer#!searchin/jenkinsci-dev/enhance/jenkinsci-dev/xuweZbwn9zE/6TqSO3r5EQAJ).

There are a few questions in this group, and on Stack Overflow about the 
fact that local branch names may include the remote name (origin for 
example) and the need for an environment variable that exposes the local 
branch name.

Please take a look at my post to Jenkins Developers, and at the JIRA (
https://issues.jenkins-ci.org/browse/JENKINS-33202 
).
 
 The coding is complete and a pull request outstanding, so if you think 
this feature will help you, please go vote for the JIRA issue.

-- 
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/1fb5aaa0-df13-4b69-b1c1-d140e1b09ef7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Same Build number series for multiple projects

2016-03-01 Thread Michael Giroux

If you want to share a single build number over all branch builds, you will 
want to configure your job to accept a branch name to be built.  Then run 
as a parameterized build and specify the branch to build.  This will give 
you build numbers like this:

master: 1
master: 2
branch-a: 3
branch-b: 4
master: 5
branch-b: 6
...

Is this what you want?

On Tuesday, March 1, 2016 at 12:25:22 AM UTC-7, Amit Bhardwaj wrote:
>
> Hi, 
> Thanks for the reply. I went through those links. I believe my requirement 
> is a bit different from those. 
>
> I would need a universal sequence/build number which can be used by 
> multiple projects in Jenkins. 
>
> Regards
> AB 
>
> On Friday, February 26, 2016 at 8:34:14 PM UTC+5:30, Victor Martinez wrote:
>>
>> Hi,
>>
>>  You don't need to use Capital Cases at all, lower cases are in good 
>> shape and easy to read.
>>
>>  Coming back to your questions:
>>
>>  - https://wiki.jenkins-ci.org/display/JENKINS/Build+Name+Setter+Plugin 
>> might help you to set those numbers based on token/attributes
>>  - https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin 
>> is another way with more granularity
>>
>> I hope it helps
>>
>> On Friday, 26 February 2016 13:27:10 UTC, Amit Bhardwaj wrote:
>>>
>>> Hi Group!
>>>
>>> I have a requirement where I have 2-3 branches from a common master (say 
>>> A-dev, B-dev2.0, C-Qa) and I want to run Jenkins for each branch and check 
>>> stability of my code and binaries. 
>>>
>>> Currently I run Jenkins Project for 'master' branch only and with each 
>>> build I get a iterative next number as my build number (which is default 
>>> behavior). But now that I have multiple branches to build, I have to use 
>>> Jenkins for all branches. 
>>>
>>> I think I will need to create Jenkins Project for all branches but don't 
>>> know 'HOW CAN I KEEP BUILD NUMBER SEQUENCE" as same.
>>>
>>> Please let me know how can I achieve this. 
>>>
>>> Regards
>>> AB
>>>
>>
>>  
>>
>

-- 
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/7f75c016-ddee-40af-a801-68eb4550996a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running a Jenkins job from a shell script

2016-03-01 Thread Michael Giroux

If you are referring to the authtoken from build triggers, you could 
retrieve it using the jenkins cli to retrieve the config.xml for the job 
and extract the authToken element.

 (System)

  xxxyyy

  

  false


On Tuesday, March 1, 2016 at 7:13:38 PM UTC-7, Alan Evangelista wrote:
>
> I do not need help in how to call the HTTP API. Triggering a Jenkins job 
> requires the Jenkins API token;
> my question is to how to have this Jenkins API token without hardcoding it 
> in the script. The script
> is in a public git repo and I dont want the Jenkins API token available to 
> everyone.
>
> As Jenkins user and user API token are not available via Jenkins env 
> variables, the solution I found is
> to put this data in a file (always in same path) in each Jenkins slave and 
> the script opens the file
> to get the data.
>
>
> Regards,
> Alan Evangelista
>

-- 
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/249588e8-172c-4900-8acb-d0ef62a13627%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Git Plugin and Maven Release Builds

2016-02-24 Thread Michael Giroux

Coding is complete.  I'm running it locally with desired results.  See 
PR https://github.com/jenkinsci/git-plugin/pull/381

The implementation recognizes either an empty value or "**" which is used 
throughout the plugin for similar purposes.  "**" is not a valid local 
branch name, so it will not collide with any existing use cases.

Hope you have time to take a look.

Michael

On Tuesday, January 5, 2016 at 12:59:55 PM UTC-7, Mark Waite wrote:
>
> That is am interesting idea.  Giving a semantic meaning to am empty field 
> should not alert behavior for non-empty fields.  Will you be coding it? 
>
> Mark Waite
>
> On Tue, Jan 5, 2016, 11:47 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Mark,
>>
>> I think there may be a simple solution that can be implemented in the Git 
>> plugin.  If the job is configured with additional behavior "checkout to 
>> local branch" AND the local branch name is left blank, then the Git plugin 
>> could do a checkout of the configured remote branch sans "origin/".  I 
>> think this allows for current behavior while also allowing maven release 
>> builds to run.
>>
>> Michael
>>
>>
>> On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote:
>>
>>> I think your logic is very reasonable.  The git plugin seems like the 
>>> right place to do that.  Since the need is to reference a substring of the 
>>> current GIT_BRANCH value within the context of a Jenkins job, it seems like 
>>> an addition to the token macro keywords allowed on GIT_BRANCH might meet 
>>> your need.
>>>
>>> You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for 
>>> a discussion of the fullName=false parameter to GIT_BRANCH, in case that 
>>> will already handle your case.
>>>
>>> Mark Waite
>>>
>>> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <mlgi...@gmail.com> 
>>> wrote:
>>>
>> Accepting that the Git Parameter plugin is technically correct, lets get 
>>>> back to the maven release build issue.
>>>> 1. to do a maven release, we MUST configure the "checkout to local 
>>>> branch" option, or define a pre build step to do a git checkout into a 
>>>> local branch.
>>>> 2. the local branch name MUST be the effective name on the remote (sans 
>>>> origin/) to allow the maven release:prepare to push the pom changes to the 
>>>> correct branch.
>>>> 3. we currently can not use the value from the Git Parameter plugin 
>>>> because that includes the "origin/" prefix resulting in a new branch 
>>>> created on the remote git repo.
>>>>
>>>> I'm not really sure where the option belongs, but to support doing a 
>>>> maven release on a branch specified by the Git Parameter plugin we need a 
>>>> clean way to get the code checked out into the correct local branch.
>>>>
>>>> The Git plugin could provide an option to derive local branch name, or 
>>>> the Git Parameter plugin could define an additional parameter containing 
>>>> the effective branch name.  I'm not sure which is best approach.  I 
>>>> suspect 
>>>> that the Git plugin should be able to operate whether the Git Parameter 
>>>> plugin has been configured or not, so I lean toward an option in Git 
>>>> plugin 
>>>> to "checkout to local branch" that ends up with the required local branch 
>>>> name, but there may be a more appropriate approach.
>>>>
>>>> What is the next step?  
>>>>
>>>>
>>>>
>>>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote:
>>>>
>>>>> 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 <mlgi...@gmail.com> 
>>>>> 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 fo

git-plugin test cases running 5+ minutes

2016-01-21 Thread Michael Giroux

I'm attempting to build git-plugin and find that the test cases are taking 
a very long time.  Several of the tests are running 270+ seconds.

Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 270.683 
sec - in hudson.plugins.git.CliGitSCMTriggerRemotePollTest

Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 272.201 
sec - in hudson.plugins.git.CliGitSCMTriggerLocalPollTest

Tests run: 55, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 264.263 
sec - in hudson.plugins.git.GitSCMTest

Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 244.154 
sec - in hudson.plugins.git.JGitSCMTriggerLocalPollTest

Tests run: 20, Failures: 9, Errors: 0, Skipped: 0, Time elapsed: 224.619 
sec <<< FAILURE! - in hudson.plugins.git.JGitSCMTriggerRemotePollTest


Should I be configuring something on my local system to allow the tests to 
run faster?

-- 
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/3fb841fb-f48b-4345-8a90-ef195632d905%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-06 Thread Michael Giroux

I've solved the build issue.  Actually, I managed to work around it. 
 Ultimately, I deleted my local maven repo (~/.m2/repository/*) and reran 
the build.  The subsequent build ran, suggesting that one or more of the 
existing artifacts in my local maven repo was causing the problem, or 
perhaps when maven built the class path, it managed to get an older copy of 
maven-core ahead of the required version 3.1.0 (just guessing here).

I set up a jenkins job to build git-plugin and set the option to use a 
private repository to prevent my other projects from introducing this 
problem in the future.

   

On Wednesday, January 6, 2016 at 1:29:13 PM UTC-7, Michael Giroux wrote:
>
> Really appreciate the suggestions.
>
> To eliminate eclipse, I cloned https://github.com/jenkinsci/git-plugin.git 
> to a new directory and built with maven.  Same issue.  Wonder if this is 
> caused by my version of OS X (10.11.2) El Capitan.I'm going to check 
> the maven groups.
>
> On Wednesday, January 6, 2016 at 12:25:48 PM UTC-7, Vincent Latombe wrote:
>>
>> If you use Eclipse, make sure you do a clean build in maven. Not doing so 
>> will result in odd failures with all things related to annotation 
>> processing, such as the error message you are getting.
>>
>> Vincent
>>
>> 2016-01-06 17:22 GMT+01:00 Mark Waite <mark.ea...@gmail.com>:
>>
>>> I had a friend at the office compile the master branch of the git plugin 
>>> on his MacOS machine with maven 3.3.1 and Java 1.8.0_60.  No test failures 
>>> for him either.  I truly don't know what's different about your environment 
>>> that causes the tests to fail.
>>>
>>> Mark Waite
>>>
>>> On Tue, Jan 5, 2016 at 9:01 PM Mark Waite <mark.ea...@gmail.com> wrote:
>>>
>>>> It may be that you're seeing a slightly different variation on MacOS of 
>>>> what I'm seeing on FreeBSD.  On FreeBSD, it appears the tests fail due to 
>>>> the Jenkins version on which the git plugin is based.
>>>>
>>>> I maintain a working branch (for compatibility testing) on 
>>>> https://github.com/MarkEWaite/git-plugin/tree/ongoing/latest-jenkins-lts . 
>>>>  
>>>> That branch compiles and passes all tests on FreeBSD 10.1 with OpenJDK 8.  
>>>> It is the same content as the git plugin master branch, plus an update to 
>>>> the pom.xml to depend on the latest Jenkins long term support release.  I 
>>>> believe it also includes one other relatively minor change required in the 
>>>> newer Jenkins version.
>>>>
>>>> You might try that same branch for yourself.
>>>>
>>>> Mark Waite
>>>>
>>>> On Tue, Jan 5, 2016 at 8:22 PM Mark Waite <mark.ea...@gmail.com> wrote:
>>>>
>>>>> I use various versions of maven, including Maven 3.2.5, and the latest 
>>>>> versions of Oracle Java 7 and Oracle Java 8 on the platforms where I 
>>>>> compile and run.  I also use OpenJDK 7 and OpenJDK 8 on at least a few of 
>>>>> the platforms.
>>>>>
>>>>> I also built and tested on FreeBSD 10.1 using OpenJDK 7.  That's the 
>>>>> closest I can approximate to a MacOS machine.  It fails with a hundred or 
>>>>> more test failures, but not with the message you're seeing.
>>>>>
>>>>> I built and tested on FreeBSD 10.1 using OpenJDK 8.  It also fails 
>>>>> with a hundred or more test failures, but not the message you're seeing.
>>>>>
>>>>> I am able to run slave agents on FreeBSD, and the git plugin and git 
>>>>> client plugin are able to clone repositories, but I can't compile and 
>>>>> test 
>>>>> successfully on FreeBSD with either OpenJDK 7 or OpenJDK 8.
>>>>>
>>>>> I think the problem you're seeing is either platform specific (like my 
>>>>> FreeBSD problem), or environment and configuration specific.  
>>>>> Unfortunately, I don't have any way to do further diagnosis.
>>>>>
>>>>> You might check with Craig Rodrigues on this mailing list.  I believe 
>>>>> he's a FreeBSD developer.  I don't think I've ever seen a Darwin 
>>>>> developer 
>>>>> on the list.
>>>>>
>>>>> Mark Waite
>>>>>
>>>>> On Tue, Jan 5, 2016 at 7:02 PM Michael Giroux <mlgi...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> Mac OS should not matter.  Maven is Java, and Java is platform

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-06 Thread Michael Giroux

Really appreciate the suggestions.

To eliminate eclipse, I cloned https://github.com/jenkinsci/git-plugin.git 
to a new directory and built with maven.  Same issue.  Wonder if this is 
caused by my version of OS X (10.11.2) El Capitan.I'm going to check 
the maven groups.

On Wednesday, January 6, 2016 at 12:25:48 PM UTC-7, Vincent Latombe wrote:
>
> If you use Eclipse, make sure you do a clean build in maven. Not doing so 
> will result in odd failures with all things related to annotation 
> processing, such as the error message you are getting.
>
> Vincent
>
> 2016-01-06 17:22 GMT+01:00 Mark Waite <mark.ea...@gmail.com >
> :
>
>> I had a friend at the office compile the master branch of the git plugin 
>> on his MacOS machine with maven 3.3.1 and Java 1.8.0_60.  No test failures 
>> for him either.  I truly don't know what's different about your environment 
>> that causes the tests to fail.
>>
>> Mark Waite
>>
>> On Tue, Jan 5, 2016 at 9:01 PM Mark Waite <mark.ea...@gmail.com 
>> > wrote:
>>
>>> It may be that you're seeing a slightly different variation on MacOS of 
>>> what I'm seeing on FreeBSD.  On FreeBSD, it appears the tests fail due to 
>>> the Jenkins version on which the git plugin is based.
>>>
>>> I maintain a working branch (for compatibility testing) on 
>>> https://github.com/MarkEWaite/git-plugin/tree/ongoing/latest-jenkins-lts .  
>>> That branch compiles and passes all tests on FreeBSD 10.1 with OpenJDK 8.  
>>> It is the same content as the git plugin master branch, plus an update to 
>>> the pom.xml to depend on the latest Jenkins long term support release.  I 
>>> believe it also includes one other relatively minor change required in the 
>>> newer Jenkins version.
>>>
>>> You might try that same branch for yourself.
>>>
>>> Mark Waite
>>>
>>> On Tue, Jan 5, 2016 at 8:22 PM Mark Waite <mark.ea...@gmail.com 
>>> > wrote:
>>>
>>>> I use various versions of maven, including Maven 3.2.5, and the latest 
>>>> versions of Oracle Java 7 and Oracle Java 8 on the platforms where I 
>>>> compile and run.  I also use OpenJDK 7 and OpenJDK 8 on at least a few of 
>>>> the platforms.
>>>>
>>>> I also built and tested on FreeBSD 10.1 using OpenJDK 7.  That's the 
>>>> closest I can approximate to a MacOS machine.  It fails with a hundred or 
>>>> more test failures, but not with the message you're seeing.
>>>>
>>>> I built and tested on FreeBSD 10.1 using OpenJDK 8.  It also fails with 
>>>> a hundred or more test failures, but not the message you're seeing.
>>>>
>>>> I am able to run slave agents on FreeBSD, and the git plugin and git 
>>>> client plugin are able to clone repositories, but I can't compile and test 
>>>> successfully on FreeBSD with either OpenJDK 7 or OpenJDK 8.
>>>>
>>>> I think the problem you're seeing is either platform specific (like my 
>>>> FreeBSD problem), or environment and configuration specific.  
>>>> Unfortunately, I don't have any way to do further diagnosis.
>>>>
>>>> You might check with Craig Rodrigues on this mailing list.  I believe 
>>>> he's a FreeBSD developer.  I don't think I've ever seen a Darwin developer 
>>>> on the list.
>>>>
>>>> Mark Waite
>>>>
>>>> On Tue, Jan 5, 2016 at 7:02 PM Michael Giroux <mlgi...@gmail.com 
>>>> > wrote:
>>>>
>>>>> Mac OS should not matter.  Maven is Java, and Java is platform neutral 
>>>>> (in theory), but maven version may be of interest.
>>>>>
>>>>> What is your specific build environment?
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, January 5, 2016 at 6:02:56 PM UTC-7, Mark Waite wrote:
>>>>>
>>>>>> That's a very strange message.  The only reference I could find to 
>>>>>> that message was a wiki article from 2011.  See 
>>>>>> https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor
>>>>>>  in 
>>>>>> case that gives you any help.
>>>>>>
>>>>>> I see that you're running on MacOS, and I don't have a MacOS machine 
>>>>>> in my mix of development and test environments, so there may be 
>>>>>> something 
>>>>>> specific to the Mac.
>>>>>>
>>>>&g

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-05 Thread Michael Giroux

Mark,

I think there may be a simple solution that can be implemented in the Git 
plugin.  If the job is configured with additional behavior "checkout to 
local branch" AND the local branch name is left blank, then the Git plugin 
could do a checkout of the configured remote branch sans "origin/".  I 
think this allows for current behavior while also allowing maven release 
builds to run.

Michael

On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote:
>
> I think your logic is very reasonable.  The git plugin seems like the 
> right place to do that.  Since the need is to reference a substring of the 
> current GIT_BRANCH value within the context of a Jenkins job, it seems like 
> an addition to the token macro keywords allowed on GIT_BRANCH might meet 
> your need.
>
> You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for 
> a discussion of the fullName=false parameter to GIT_BRANCH, in case that 
> will already handle your case.
>
> Mark Waite
>
> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Accepting that the Git Parameter plugin is technically correct, lets get 
>> back to the maven release build issue.
>> 1. to do a maven release, we MUST configure the "checkout to local 
>> branch" option, or define a pre build step to do a git checkout into a 
>> local branch.
>> 2. the local branch name MUST be the effective name on the remote (sans 
>> origin/) to allow the maven release:prepare to push the pom changes to the 
>> correct branch.
>> 3. we currently can not use the value from the Git Parameter plugin 
>> because that includes the "origin/" prefix resulting in a new branch 
>> created on the remote git repo.
>>
>> I'm not really sure where the option belongs, but to support doing a 
>> maven release on a branch specified by the Git Parameter plugin we need a 
>> clean way to get the code checked out into the correct local branch.
>>
>> The Git plugin could provide an option to derive local branch name, or 
>> the Git Parameter plugin could define an additional parameter containing 
>> the effective branch name.  I'm not sure which is best approach.  I suspect 
>> that the Git plugin should be able to operate whether the Git Parameter 
>> plugin has been configured or not, so I lean toward an option in Git plugin 
>> to "checkout to local branch" that ends up with the required local branch 
>> name, but there may be a more appropriate approach.
>>
>> What is the next step?  
>>
>>
>>
>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote:
>>
>>> 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 <mlgi...@gmail.com> 
>>> 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 se

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-05 Thread Michael Giroux

Have not contributed in past, but willing to take a cut at it.  Off to look 
at it.

As mentioned in a prior post, I've forked the project and ran into a minor 
issue with builds inside Eclipse.  I filed a bug at Eclipse. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485066

Michael

On Tuesday, January 5, 2016 at 12:59:55 PM UTC-7, Mark Waite wrote:
>
> That is am interesting idea.  Giving a semantic meaning to am empty field 
> should not alert behavior for non-empty fields.  Will you be coding it? 
>
> Mark Waite
>
> On Tue, Jan 5, 2016, 11:47 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Mark,
>>
>> I think there may be a simple solution that can be implemented in the Git 
>> plugin.  If the job is configured with additional behavior "checkout to 
>> local branch" AND the local branch name is left blank, then the Git plugin 
>> could do a checkout of the configured remote branch sans "origin/".  I 
>> think this allows for current behavior while also allowing maven release 
>> builds to run.
>>
>> Michael
>>
>>
>> On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote:
>>
>>> I think your logic is very reasonable.  The git plugin seems like the 
>>> right place to do that.  Since the need is to reference a substring of the 
>>> current GIT_BRANCH value within the context of a Jenkins job, it seems like 
>>> an addition to the token macro keywords allowed on GIT_BRANCH might meet 
>>> your need.
>>>
>>> You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for 
>>> a discussion of the fullName=false parameter to GIT_BRANCH, in case that 
>>> will already handle your case.
>>>
>>> Mark Waite
>>>
>>> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <mlgi...@gmail.com> 
>>> wrote:
>>>
>> Accepting that the Git Parameter plugin is technically correct, lets get 
>>>> back to the maven release build issue.
>>>> 1. to do a maven release, we MUST configure the "checkout to local 
>>>> branch" option, or define a pre build step to do a git checkout into a 
>>>> local branch.
>>>> 2. the local branch name MUST be the effective name on the remote (sans 
>>>> origin/) to allow the maven release:prepare to push the pom changes to the 
>>>> correct branch.
>>>> 3. we currently can not use the value from the Git Parameter plugin 
>>>> because that includes the "origin/" prefix resulting in a new branch 
>>>> created on the remote git repo.
>>>>
>>>> I'm not really sure where the option belongs, but to support doing a 
>>>> maven release on a branch specified by the Git Parameter plugin we need a 
>>>> clean way to get the code checked out into the correct local branch.
>>>>
>>>> The Git plugin could provide an option to derive local branch name, or 
>>>> the Git Parameter plugin could define an additional parameter containing 
>>>> the effective branch name.  I'm not sure which is best approach.  I 
>>>> suspect 
>>>> that the Git plugin should be able to operate whether the Git Parameter 
>>>> plugin has been configured or not, so I lean toward an option in Git 
>>>> plugin 
>>>> to "checkout to local branch" that ends up with the required local branch 
>>>> name, but there may be a more appropriate approach.
>>>>
>>>> What is the next step?  
>>>>
>>>>
>>>>
>>>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote:
>>>>
>>>>> 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 <mlgi...@gmail.com> 
>>>>> 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 
>>>>>

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-05 Thread Michael Giroux

Before I start making changes, I'm building from master and getting test 
failures.  Is there a document that explains additional environment setup 
needed to work on plugins?

On Tuesday, January 5, 2016 at 12:59:55 PM UTC-7, Mark Waite wrote:
>
> That is am interesting idea.  Giving a semantic meaning to am empty field 
> should not alert behavior for non-empty fields.  Will you be coding it? 
>
> Mark Waite
>
> On Tue, Jan 5, 2016, 11:47 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Mark,
>>
>> I think there may be a simple solution that can be implemented in the Git 
>> plugin.  If the job is configured with additional behavior "checkout to 
>> local branch" AND the local branch name is left blank, then the Git plugin 
>> could do a checkout of the configured remote branch sans "origin/".  I 
>> think this allows for current behavior while also allowing maven release 
>> builds to run.
>>
>> Michael
>>
>>
>> On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote:
>>
>>> I think your logic is very reasonable.  The git plugin seems like the 
>>> right place to do that.  Since the need is to reference a substring of the 
>>> current GIT_BRANCH value within the context of a Jenkins job, it seems like 
>>> an addition to the token macro keywords allowed on GIT_BRANCH might meet 
>>> your need.
>>>
>>> You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for 
>>> a discussion of the fullName=false parameter to GIT_BRANCH, in case that 
>>> will already handle your case.
>>>
>>> Mark Waite
>>>
>>> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <mlgi...@gmail.com> 
>>> wrote:
>>>
>> Accepting that the Git Parameter plugin is technically correct, lets get 
>>>> back to the maven release build issue.
>>>> 1. to do a maven release, we MUST configure the "checkout to local 
>>>> branch" option, or define a pre build step to do a git checkout into a 
>>>> local branch.
>>>> 2. the local branch name MUST be the effective name on the remote (sans 
>>>> origin/) to allow the maven release:prepare to push the pom changes to the 
>>>> correct branch.
>>>> 3. we currently can not use the value from the Git Parameter plugin 
>>>> because that includes the "origin/" prefix resulting in a new branch 
>>>> created on the remote git repo.
>>>>
>>>> I'm not really sure where the option belongs, but to support doing a 
>>>> maven release on a branch specified by the Git Parameter plugin we need a 
>>>> clean way to get the code checked out into the correct local branch.
>>>>
>>>> The Git plugin could provide an option to derive local branch name, or 
>>>> the Git Parameter plugin could define an additional parameter containing 
>>>> the effective branch name.  I'm not sure which is best approach.  I 
>>>> suspect 
>>>> that the Git plugin should be able to operate whether the Git Parameter 
>>>> plugin has been configured or not, so I lean toward an option in Git 
>>>> plugin 
>>>> to "checkout to local branch" that ends up with the required local branch 
>>>> name, but there may be a more appropriate approach.
>>>>
>>>> What is the next step?  
>>>>
>>>>
>>>>
>>>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote:
>>>>
>>>>> 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 <mlgi...@gmail.com> 
>>>>> 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

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-05 Thread Michael Giroux

LocalBranch could be empty


On Tuesday, January 5, 2016 at 12:59:55 PM UTC-7, Mark Waite wrote:
>
> That is am interesting idea.  Giving a semantic meaning to am empty field 
> should not alert behavior for non-empty fields.  Will you be coding it? 
>
> Mark Waite
>
> On Tue, Jan 5, 2016, 11:47 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Mark,
>>
>> I think there may be a simple solution that can be implemented in the Git 
>> plugin.  If the job is configured with additional behavior "checkout to 
>> local branch" AND the local branch name is left blank, then the Git plugin 
>> could do a checkout of the configured remote branch sans "origin/".  I 
>> think this allows for current behavior while also allowing maven release 
>> builds to run.
>>
>> Michael
>>
>>
>> On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote:
>>
>>> I think your logic is very reasonable.  The git plugin seems like the 
>>> right place to do that.  Since the need is to reference a substring of the 
>>> current GIT_BRANCH value within the context of a Jenkins job, it seems like 
>>> an addition to the token macro keywords allowed on GIT_BRANCH might meet 
>>> your need.
>>>
>>> You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for 
>>> a discussion of the fullName=false parameter to GIT_BRANCH, in case that 
>>> will already handle your case.
>>>
>>> Mark Waite
>>>
>>> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <mlgi...@gmail.com> 
>>> wrote:
>>>
>> Accepting that the Git Parameter plugin is technically correct, lets get 
>>>> back to the maven release build issue.
>>>> 1. to do a maven release, we MUST configure the "checkout to local 
>>>> branch" option, or define a pre build step to do a git checkout into a 
>>>> local branch.
>>>> 2. the local branch name MUST be the effective name on the remote (sans 
>>>> origin/) to allow the maven release:prepare to push the pom changes to the 
>>>> correct branch.
>>>> 3. we currently can not use the value from the Git Parameter plugin 
>>>> because that includes the "origin/" prefix resulting in a new branch 
>>>> created on the remote git repo.
>>>>
>>>> I'm not really sure where the option belongs, but to support doing a 
>>>> maven release on a branch specified by the Git Parameter plugin we need a 
>>>> clean way to get the code checked out into the correct local branch.
>>>>
>>>> The Git plugin could provide an option to derive local branch name, or 
>>>> the Git Parameter plugin could define an additional parameter containing 
>>>> the effective branch name.  I'm not sure which is best approach.  I 
>>>> suspect 
>>>> that the Git plugin should be able to operate whether the Git Parameter 
>>>> plugin has been configured or not, so I lean toward an option in Git 
>>>> plugin 
>>>> to "checkout to local branch" that ends up with the required local branch 
>>>> name, but there may be a more appropriate approach.
>>>>
>>>> What is the next step?  
>>>>
>>>>
>>>>
>>>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote:
>>>>
>>>>> 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 <mlgi...@gmail.com> 
>>>>> 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

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-05 Thread Michael Giroux

.evaluate(InvokeMethod.java:17)

at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)

at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

at org.jvnet.hudson.test.JenkinsRule$2.evaluate(JenkinsRule.java:486)

at org.junit.rules.RunRules.evaluate(RunRules.java:20)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)

at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)

at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)

at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)

at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)

at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)

at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)

at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)

at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)


Running hudson.plugins.git.JGitSCMTriggerRemotePollTest



On Tuesday, January 5, 2016 at 3:55:01 PM UTC-7, Mark Waite wrote:
>
> I'm interested in the test failures you're seeing, since there are 
> currently no test failures on the Cloudbees execution of the automated 
> tests <https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/1031/> on 
> the master branch, and there were only three random failures on my 
> execution of the automated tests on CentOS 6, CentOS 7, Debian 6, Debian 7, 
> Debian 8, Windows 7, and Windows 10, with Java 7 and Java 8.
>
> Mark Waite
>
> On Tue, Jan 5, 2016 at 3:39 PM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Before I start making changes, I'm building from master and getting test 
>> failures.  Is there a document that explains additional environment setup 
>> needed to work on plugins?
>>
>>
>> On Tuesday, January 5, 2016 at 12:59:55 PM UTC-7, Mark Waite wrote:
>>
>>> That is am interesting idea.  Giving a semantic meaning to am empty 
>>> field should not alert behavior for non-empty fields.  Will you be coding 
>>> it? 
>>>
>>> Mark Waite
>>>
>>> On Tue, Jan 5, 2016, 11:47 AM Michael Giroux <mlgi...@gmail.com> wrote:
>>>
>> Mark,
>>>>
>>>> I think there may be a simple solution that can be implemented in the 
>>>> Git plugin.  If the job is configured with additional behavior "checkout 
>>>> to 
>>>> local branch" AND the local branch name is left blank, then the Git plugin 
>>>> could do a checkout of the configured remote branch sans "origin/".  I 
>>>> think this allows for current behavior while also allowing maven release 
>>>> builds to run.
>>>>
>>>> Michael
>>>>
>>>>
>>>> On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote:
>>>>
>>>>> I think your logic is very reasonable.  The git plugin seems like the 
>>>>> right place to do that.  Since the need is to reference a substring of 
>>>>> the 
>>>>> current GIT_BRANCH value within the context of a Jenkins job, it seems 
>>>>> like 
>>>>> an addition to the token macro keywords allowed on GIT_BRANCH might meet 
>>>>> your need.
>>>>>
>>>>> You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for 
>>>>> a discussion of the fullName=false parameter to GIT_BRANCH, in case that 
>>>>> will already handle your case.
>>>>>
>>>>> Mark Waite
>>>>>
>>>>> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <mlgi...@gmail.com> 
>>>>> wrote:
>>>>>
>>>> Accepting that the Git Parameter plugin is technically correct, lets 
>>>>>> get back to the maven release build issue.
>>>>>> 1. to do a maven release, we MUST configure the "checkout to local 
>>>>>> branch" option, or define a pre build step to do a git checkout into a 
>>>&g

Re: Jenkins Git Plugin and Maven Release Builds

2016-01-05 Thread Michael Giroux

Mac OS should not matter.  Maven is Java, and Java is platform neutral (in 
theory), but maven version may be of interest.

What is your specific build environment?



On Tuesday, January 5, 2016 at 6:02:56 PM UTC-7, Mark Waite wrote:
>
> That's a very strange message.  The only reference I could find to that 
> message was a wiki article from 2011.  See 
> https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor in 
> case that gives you any help.
>
> I see that you're running on MacOS, and I don't have a MacOS machine in my 
> mix of development and test environments, so there may be something 
> specific to the Mac.
>
> Mark Waite
>
> On Tue, Jan 5, 2016 at 4:29 PM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Attaching build.log for complete build result.  shows maven version and 
>> java versions at head of file.
>>
>>
>> On Tuesday, January 5, 2016 at 4:25:25 PM UTC-7, Michael Giroux wrote:
>>>
>>> I'm running a build now, will attach console output when tests 
>>> complete.  Here is an example of a failure:
>>>
>>> java.lang.AssertionError: class 
>>> hudson.plugins.git.util.DefaultBuildChooser is missing its descriptor
>>>
>>> at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1165)
>>>
>>> at 
>>> hudson.plugins.git.util.BuildChooser.getDescriptor(BuildChooser.java:142)
>>>
>>> at 
>>> hudson.plugins.git.util.BuildChooser.getDisplayName(BuildChooser.java:45)
>>>
>>> at 
>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:555)
>>>
>>> at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529)
>>>
>>> at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:384)
>>>
>>> at hudson.scm.SCM.poll(SCM.java:401)
>>>
>>> at 
>>> hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1450)
>>>
>>> at hudson.model.AbstractProject._poll(AbstractProject.java:1421)
>>>
>>> at hudson.model.AbstractProject.poll(AbstractProject.java:1332)
>>>
>>> at hudson.plugins.git.SCMTriggerTest.check(SCMTriggerTest.java:271)
>>>
>>> at 
>>> hudson.plugins.git.SCMTriggerTest.testCommitAsBranchSpec_feature4_sha1(SCMTriggerTest.java:206)
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at 
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>> at 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>>
>>> at 
>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>>
>>> at 
>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>>
>>> at 
>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>>
>>> at 
>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>>>
>>> at 
>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>>>
>>> at 
>>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>>>
>>> at org.jvnet.hudson.test.JenkinsRule$2.evaluate(JenkinsRule.java:486)
>>>
>>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>>
>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>
>>> at 
>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>
>>> at 
>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>
>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>
>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>
>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>
>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>
>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>
>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>
>>> at 
>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>>>
>>> at 
>>> org.apache.maven.sur

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-31 Thread Michael Giroux

Accepting that the Git Parameter plugin is technically correct, lets get 
back to the maven release build issue.
1. to do a maven release, we MUST configure the "checkout to local branch" 
option, or define a pre build step to do a git checkout into a local branch.
2. the local branch name MUST be the effective name on the remote (sans 
origin/) to allow the maven release:prepare to push the pom changes to the 
correct branch.
3. we currently can not use the value from the Git Parameter plugin because 
that includes the "origin/" prefix resulting in a new branch created on the 
remote git repo.

I'm not really sure where the option belongs, but to support doing a maven 
release on a branch specified by the Git Parameter plugin we need a clean 
way to get the code checked out into the correct local branch.

The Git plugin could provide an option to derive local branch name, or the 
Git Parameter plugin could define an additional parameter containing the 
effective branch name.  I'm not sure which is best approach.  I suspect 
that the Git plugin should be able to operate whether the Git Parameter 
plugin has been configured or not, so I lean toward an option in Git plugin 
to "checkout to local branch" that ends up with the required local branch 
name, but there may be a more appropriate approach.

What is the next step?  

On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote:
>
> 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 <mlgi...@gmail.com 
> > 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 <mlgi...@gmail.com> 
>>>> 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());
>>>>>  }
>>>>>

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-31 Thread Michael Giroux

I looked at JERKINS-25465 and it looked interesting, so I tried to 
configure the "checkout to local branch" as ${GIT_BRANCH,fullName=false}. 
 This resulted in a checkout to a branch named exactly that, with no 
expansion.

I have Git plugin version 2.4.1 (and all dependent plugins) installed.

I do not see anything in the Git Plugin documentation that references the 
,fullName qualifier on the expansion.

So I'm guessing I'm missing something here.  where exactly can this syntax 
be used, and where is it documented?  Should I be able to use this in the 
additional behaviors?

Michael

On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote:
>
> I think your logic is very reasonable.  The git plugin seems like the 
> right place to do that.  Since the need is to reference a substring of the 
> current GIT_BRANCH value within the context of a Jenkins job, it seems like 
> an addition to the token macro keywords allowed on GIT_BRANCH might meet 
> your need.
>
> You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for 
> a discussion of the fullName=false parameter to GIT_BRANCH, in case that 
> will already handle your case.
>
> Mark Waite
>
> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <mlgi...@gmail.com 
> > wrote:
>
>> Accepting that the Git Parameter plugin is technically correct, lets get 
>> back to the maven release build issue.
>> 1. to do a maven release, we MUST configure the "checkout to local 
>> branch" option, or define a pre build step to do a git checkout into a 
>> local branch.
>> 2. the local branch name MUST be the effective name on the remote (sans 
>> origin/) to allow the maven release:prepare to push the pom changes to the 
>> correct branch.
>> 3. we currently can not use the value from the Git Parameter plugin 
>> because that includes the "origin/" prefix resulting in a new branch 
>> created on the remote git repo.
>>
>> I'm not really sure where the option belongs, but to support doing a 
>> maven release on a branch specified by the Git Parameter plugin we need a 
>> clean way to get the code checked out into the correct local branch.
>>
>> The Git plugin could provide an option to derive local branch name, or 
>> the Git Parameter plugin could define an additional parameter containing 
>> the effective branch name.  I'm not sure which is best approach.  I suspect 
>> that the Git plugin should be able to operate whether the Git Parameter 
>> plugin has been configured or not, so I lean toward an option in Git plugin 
>> to "checkout to local branch" that ends up with the required local branch 
>> name, but there may be a more appropriate approach.
>>
>> What is the next step?  
>>
>>
>>
>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote:
>>
>>> 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 <mlgi...@gmail.com> 
>>> 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 wrot

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-30 Thread 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 <mlgi...@gmail.com 
> > 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 <mlgi...@gmail.com> 
>>>> 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 <mlgi...@gmail.com> 
>>>>>> wrote:
>>>>>>
>>>>> Yes.  
>>>>

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-30 Thread 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 <mlgi...@gmail.com> 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 <mlgi...@gmail.com> 
>>>> 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.  O

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-30 Thread 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 <mlgi...@gmail.com 
> > 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 <mlgi...@gmail.com> 
>>> 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 o

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-30 Thread 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 <mlgi...@gmail.com 
> > 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_br

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-30 Thread 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 <mlgi...@gmail.com> 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 <mlgi...@gmail.com> 
>>>>> 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

Jenkins Git Plugin and Maven Release Builds

2015-12-29 Thread Michael Giroux

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 being build.

NOTE that we have tried to configure the "checkout to local branch" using
the property that is configured by the Git ($BRANCH) but that results in
local branch names of "origin/master", "origin/some_branch", ... This
results in release:prepare doing pushes as "git push ...
origin/some_branch:origin/some_branch" which results in a new remote branch
named "origin/some_branch" We have seen repos with branches named
"origin/master". As a result, the desired branch is not updated, and a new
branch is created.

QUESTION/SUGGESTION/...
It would be nice to have an option in the Git plugin to "checkout to local
branch" that derives the local branch name from the remote branch name,
without having to add our pre-build step. Thus, if I select
"origin/some_branch" from the Git parameter, I could checkout to local
branch using the Git Parameter $BRANCH which would resolve to "some_branch"
sans the "origin/" prefix.

Steps to Reproduce:
1. configure a parameterized job with a git parameter using "BRANCH" as the
parameter name
2. configure the Git scm additional behavour to checkout to local branch
"$BRANCH"
3. configure job with as a maven release.
4. perform a maven releae, selecting one of the branches from the list of
Git Parameter options.
5. observe console output to examine the "git push" commands generated by
the release:prepare goal.

--
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/eeeff5a0-a7c8-4252-bbec-33168968a14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Git Plugin and Maven Release Builds

2015-12-29 Thread Michael Giroux

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 being build.
>
> NOTE that we have tried to configure the "checkout to local branch" using 
> the property that is configured by the Git ($BRANCH) but that results in 
> local branch names of "origin/master", "origin/some_branch", ...  This 
> results in release:prepare doing pushes as "git push ... 
> origin/some_branch:origin/some_branch" which results in a new remote branch 
> named "origin/some_branch"  We have seen repos with branches named 
> "origin/master".  As a result, the desired branch is not updated, and a new 
> branch is created.
>
> QUESTION/SUGGESTION/...
> It would be nice to have an option in the Git plugin to "checkout to local 
> branch" that derives the local branch name from the remote branch name, 
> without having to add our pre-build step.  Thus, if I select 
&

48 matches

Mail list logo