[JIRA] (JENKINS-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling

2012-06-04 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163496#comment-163496
 ] 

jglick commented on JENKINS-13174:
--

Note that subrepositories are not really supported yet; there is an open RFE 
for that.

> Stop changeset tags from being counted as a change in Mercurial Plugin polling
> --
>
> Key: JENKINS-13174
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: Neil Kay
>Assignee: jglick
>
> We have the slave build machines polling Mercurial repositories, using the 
> Mercurial plugin, to trigger builds.
> During the Jenkins job, we create and push a tag changeset as part of the 
> build process.
> This tag changeset is detected by polling and causing an infinite loop of 
> builds.
> I've looked into other options, I notice the notice away from polling to be 
> more push activated, which sounds good, but it seems this still relies on 
> polling to detect what has changed, so it seems this would still be a problem.
> The other thing that sounded like it may help was "modules" in the Mercurial 
> plugin, but this is a huge change to move lots of repositories to put 
> everything except the hgtags file into a sub folder and then specify that sub 
> folder as a module.
> If tag changesets were ignorred by polling, similar to a change that was made 
> to ignore merge changesets, all would be good in the world :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling

2012-06-04 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163495#comment-163495
 ] 

jglick commented on JENKINS-13174:
--

There is already a separate RFE for configurable ignore lists; when implemented 
that ought to be made to subsume this, perhaps by defaulting the ignore list to 
include {{.hgignore}} and {{.hgtags}}.

> Stop changeset tags from being counted as a change in Mercurial Plugin polling
> --
>
> Key: JENKINS-13174
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: Neil Kay
>Assignee: jglick
>
> We have the slave build machines polling Mercurial repositories, using the 
> Mercurial plugin, to trigger builds.
> During the Jenkins job, we create and push a tag changeset as part of the 
> build process.
> This tag changeset is detected by polling and causing an infinite loop of 
> builds.
> I've looked into other options, I notice the notice away from polling to be 
> more push activated, which sounds good, but it seems this still relies on 
> polling to detect what has changed, so it seems this would still be a problem.
> The other thing that sounded like it may help was "modules" in the Mercurial 
> plugin, but this is a huge change to move lots of repositories to put 
> everything except the hgtags file into a sub folder and then specify that sub 
> folder as a module.
> If tag changesets were ignorred by polling, similar to a change that was made 
> to ignore merge changesets, all would be good in the world :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13842) Mercurial poll triggers build due to unrelated changes

2012-05-30 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163334#comment-163334
 ] 

jglick commented on JENKINS-13842:
--

A test case would be something like a bundle repo (or a set of Hg commands to 
create an equivalent repo starting with hg init), plus the SCM snippet from a 
job config.xml - whatever concrete instructions are needed to reproduce the 
issue from scratch. (A unit test is of course ideal but more work to prepare if 
you have not played with the sources.)

Regarding Mercurial versions, my own organization runs 1.3.1 on some servers 
due to a serious regression in the merge algorithm in 1.4. General policy for 
the plugin is that it should work on 1.0+ unless there is a compelling need to 
require a newer version; certain optional features are conditionally enabled 
based on version, such as hg relink.

> Mercurial poll triggers build due to unrelated changes
> --
>
> Key: JENKINS-13842
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13842
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: Thomas Lotze
>Assignee: Kohsuke Kawaguchi
>
> The current Mercurial poll command is formulated such that it may falsely 
> detect new changes if there have ever been any branches with the same name as 
> that relevant to the build, but which are not ancestors of the current 
> working-directory revision in terms of the revision DAG.
> If the repository happens to contain another branch with the same name, 
> Jenkins will continuously build the project and the only way to stop it is to 
> push a dummy merge of that other branch into the line of development Jenkins 
> is supposed to build.
> A better way to ask for new descendants of the current working-directory 
> revision would be this:
> hg log --branch $branch --rev "descendants(children($revision))"
> The children predicate is needed because descendants always include the named 
> revision itself.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13637) Cannot release using M3

2012-05-29 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163281#comment-163281
 ] 

jglick commented on JENKINS-13637:
--

Activating the Jenkins repos by default, which would affect _any_ Maven 
projects, does not seem like a reasonable workaround; passing {{\-Pjenkins}} 
during {{release:prepare}} would be an unpleasant but unacceptable workaround 
if that sufficed. A proper fix would be in {{plugin-*.pom}} to declare the 
{{pluginRepository}} it needs (or avoid using {{maven-hpi-plugin}} if it does 
not), so that the release plugin works without special configuration.

> Cannot release using M3
> ---
>
> Key: JENKINS-13637
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13637
> Project: Jenkins
>  Issue Type: Bug
>  Components: plugin
> Environment: Ubuntu, JDK 6
>Reporter: jglick
>  Labels: maven, release-plugin
>
> Given the {{mercurial}} plugin with parent 
> {{org.jenkins-ci.plugins:plugin:1.400}}, but also reproducible with 
> {{1.461}}, Maven 3 {{mvn -B release:prepare}} fails with
> {code}
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO] Transforming 'Jenkins Mercurial plugin'...
> Downloading: 
> /org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.pom
> [WARNING] The POM for org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 is 
> missing, no dependency information available
> Downloading: 
> /org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.jar
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 5.310s
> [INFO] Finished at: Fri Apr 27 19:30:03 EDT 2012
> [INFO] Final Memory: 10M/164M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on 
> project mercurial: Execution default-cli of goal 
> org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare failed: Failed to 
> build parent project for org.jenkins-ci.plugins:mercurial:hpi:1.39-SNAPSHOT: 
> Some problems were encountered while processing the POMs:
> [ERROR] [ERROR] Unresolveable build extension: Plugin 
> org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could 
> not be resolved: Could not find artifact 
> org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (/) 
> @: 1 problem was encountered while building the effective model for 
> org.jenkins-ci.plugins:plugin:1.461
> [ERROR] [ERROR] Unresolveable build extension: Plugin 
> org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could 
> not be resolved: Could not find artifact 
> org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (/) 
> @
> {code}
> Indeed I think the error message is correct: {{plugin-1.400.pom}} (or again 
> {{plugin-1.461.pom}}) refers to {{maven-hpi-plugin}} yet does not declare any 
> {{}} in which it might be found. (Nor does its own parent.)
> Maven 2 succeeds in this case; apparently it does not care where the plugin 
> came from. But Maven 3 as described in 
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>  does care.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13669) NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith

2012-05-22 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163082#comment-163082
 ] 

jglick commented on JENKINS-13669:
--

Interesting... are there any errors noted in your polling log?

> NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith
> --
>
> Key: JENKINS-13669
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13669
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial, plugin
>Affects Versions: current
> Environment: Windows 2003 R2
> Java 6.0.30
> Jenkins 1.447.1 LTS
> Mercurial plugin 1.39
>Reporter: Ronald Klop
>Assignee: jglick
>  Labels: exception, plugin
>
> When polling I get this error in the log. It repeats for a couple of days 
> now. I don't which of my projects gives this, but it polls every half an hour 
> and gives this NPE.
> May 1, 2012 4:00:46 PM hudson.triggers.SCMTrigger$Runner runPolling
> SEVERE: Failed to record SCM polling
> java.lang.NullPointerException
>   at 
> hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith(MercurialSCM.java:241)
>   at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
>   at hudson.scm.SCM.poll(SCM.java:373)
>   at hudson.model.AbstractProject.poll(AbstractProject.java:1323)
>   at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
>   at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
>   at 
> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>   at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>   at java.util.concurrent.FutureTask.run(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13669) NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith

2012-05-22 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163077#comment-163077
 ] 

jglick commented on JENKINS-13669:
--

{{cachedSource}} is being used without being checked for null.

Did you perhaps turn on the "sharing" option? And not "caching"?

> NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith
> --
>
> Key: JENKINS-13669
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13669
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial, plugin
>Affects Versions: current
> Environment: Windows 2003 R2
> Java 6.0.30
> Jenkins 1.447.1 LTS
> Mercurial plugin 1.39
>Reporter: Ronald Klop
>Assignee: jglick
>  Labels: exception, plugin
>
> When polling I get this error in the log. It repeats for a couple of days 
> now. I don't which of my projects gives this, but it polls every half an hour 
> and gives this NPE.
> May 1, 2012 4:00:46 PM hudson.triggers.SCMTrigger$Runner runPolling
> SEVERE: Failed to record SCM polling
> java.lang.NullPointerException
>   at 
> hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith(MercurialSCM.java:241)
>   at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
>   at hudson.scm.SCM.poll(SCM.java:373)
>   at hudson.model.AbstractProject.poll(AbstractProject.java:1323)
>   at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
>   at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
>   at 
> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>   at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>   at java.util.concurrent.FutureTask.run(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13669) NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith

2012-05-22 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick reassigned JENKINS-13669:


Assignee: jglick  (was: Kohsuke Kawaguchi)

> NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith
> --
>
> Key: JENKINS-13669
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13669
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial, plugin
>Affects Versions: current
> Environment: Windows 2003 R2
> Java 6.0.30
> Jenkins 1.447.1 LTS
> Mercurial plugin 1.39
>Reporter: Ronald Klop
>Assignee: jglick
>  Labels: exception, plugin
>
> When polling I get this error in the log. It repeats for a couple of days 
> now. I don't which of my projects gives this, but it polls every half an hour 
> and gives this NPE.
> May 1, 2012 4:00:46 PM hudson.triggers.SCMTrigger$Runner runPolling
> SEVERE: Failed to record SCM polling
> java.lang.NullPointerException
>   at 
> hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith(MercurialSCM.java:241)
>   at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
>   at hudson.scm.SCM.poll(SCM.java:373)
>   at hudson.model.AbstractProject.poll(AbstractProject.java:1323)
>   at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
>   at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
>   at 
> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>   at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>   at java.util.concurrent.FutureTask.run(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13842) Mercurial poll triggers build due to unrelated changes

2012-05-22 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163076#comment-163076
 ] 

jglick commented on JENKINS-13842:
--

A self-contained reproducible test case is worth a thousand words.

Using revsets is probably not feasible since they will not work on older 
versions of Mercurial. It would be possible to check the Hg version and switch 
behavior, but this makes testing ineffective.

> Mercurial poll triggers build due to unrelated changes
> --
>
> Key: JENKINS-13842
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13842
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: Thomas Lotze
>Assignee: Kohsuke Kawaguchi
>
> The current Mercurial poll command is formulated such that it may falsely 
> detect new changes if there have ever been any branches with the same name as 
> that relevant to the build, but which are not ancestors of the current 
> working-directory revision in terms of the revision DAG.
> If the repository happens to contain another branch with the same name, 
> Jenkins will continuously build the project and the only way to stop it is to 
> push a dummy merge of that other branch into the line of development Jenkins 
> is supposed to build.
> A better way to ask for new descendants of the current working-directory 
> revision would be this:
> hg log --branch $branch --rev "descendants(children($revision))"
> The children predicate is needed because descendants always include the named 
> revision itself.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling

2012-05-22 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick reassigned JENKINS-13174:


Assignee: jglick  (was: Kohsuke Kawaguchi)

> Stop changeset tags from being counted as a change in Mercurial Plugin polling
> --
>
> Key: JENKINS-13174
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: Neil Kay
>Assignee: jglick
>
> We have the slave build machines polling Mercurial repositories, using the 
> Mercurial plugin, to trigger builds.
> During the Jenkins job, we create and push a tag changeset as part of the 
> build process.
> This tag changeset is detected by polling and causing an infinite loop of 
> builds.
> I've looked into other options, I notice the notice away from polling to be 
> more push activated, which sounds good, but it seems this still relies on 
> polling to detect what has changed, so it seems this would still be a problem.
> The other thing that sounded like it may help was "modules" in the Mercurial 
> plugin, but this is a huge change to move lots of repositories to put 
> everything except the hgtags file into a sub folder and then specify that sub 
> folder as a module.
> If tag changesets were ignorred by polling, similar to a change that was made 
> to ignore merge changesets, all would be good in the world :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling

2012-05-22 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163075#comment-163075
 ] 

jglick commented on JENKINS-13174:
--

Ken tested a snapshot of the plugin and confirmed the fixed behavior.

> Stop changeset tags from being counted as a change in Mercurial Plugin polling
> --
>
> Key: JENKINS-13174
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: Neil Kay
>Assignee: jglick
>
> We have the slave build machines polling Mercurial repositories, using the 
> Mercurial plugin, to trigger builds.
> During the Jenkins job, we create and push a tag changeset as part of the 
> build process.
> This tag changeset is detected by polling and causing an infinite loop of 
> builds.
> I've looked into other options, I notice the notice away from polling to be 
> more push activated, which sounds good, but it seems this still relies on 
> polling to detect what has changed, so it seems this would still be a problem.
> The other thing that sounded like it may help was "modules" in the Mercurial 
> plugin, but this is a huge change to move lots of repositories to put 
> everything except the hgtags file into a sub folder and then specify that sub 
> folder as a module.
> If tag changesets were ignorred by polling, similar to a change that was made 
> to ignore merge changesets, all would be good in the world :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-3324) Ability to configure Reply-To header for broken build mail

2012-05-21 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163039#comment-163039
 ] 

jglick commented on JENKINS-3324:
-

I think just one hardcoded value would be fine. For example, this could be a 
development list for the project. Typically it would be the same as the "To" 
field.

> Ability to configure Reply-To header for broken build mail
> --
>
> Key: JENKINS-3324
> URL: https://issues.jenkins-ci.org/browse/JENKINS-3324
> Project: Jenkins
>  Issue Type: Improvement
>  Components: email-ext
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: jglick
>Assignee: abayer
>
> If you set the From field for a Hudson installation to some generic address -
> hud...@whatever.com - but send To a real alias - 
> my-project-croa...@whatever.com
> - then Reply will send back to hud...@whatever.com and Reply All will send to
> both addresses. Probably you would want to send
> From: hud...@whatever.com
> To: my-project-croa...@whatever.com
> Reply-To: my-project-croa...@whatever.com
> to make it easier for developers to respond to the message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13624) BitBucket URL not validated for format

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick updated JENKINS-13624:
-

Summary: BitBucket URL not validated for format  (was: When using bitbucket 
as a code browser, links to changeset are incorrect)

> BitBucket URL not validated for format
> --
>
> Key: JENKINS-13624
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13624
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Reporter: benoit guerin
>Assignee: Kohsuke Kawaguchi
>Priority: Minor
>
> They are https://bitbucket.org///src/changeset//
> The good link is https://bitbucket.org///changeset//

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13457) support for hg flow

2012-05-01 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162287#comment-162287
 ] 

jglick commented on JENKINS-13457:
--

This request is more specific and idiosyncratic than what the Mercurial plugin 
generally can support. Would need to be in its own plugin. The architectural 
question then is what can be programmatically reused from the basic Hg plugin. 
Can you create an {{SCM}} on the fly for a job and do some polling/updates/etc. 
with it? Or do you need to define your own {{SCM}} which delegates some 
functions?

(JENKINS-11102 would cover some of the basic parts of this request.)

> support for hg flow 
> 
>
> Key: JENKINS-13457
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13457
> Project: Jenkins
>  Issue Type: New Feature
>  Components: mercurial
>Reporter: Joe Passavanti
>Assignee: Kohsuke Kawaguchi
>  Labels: hgflow, mercurial
>
> hg flow (https://bitbucket.org/yinwm/hgflow/wiki/Home) adds process control 
> in Mercurial similar to git flow (https://github.com/nvie/gitflow).  One of 
> the outcomes of this process is that it creates and deletes branches all the 
> time.
> For example: the "releases" branch in itself really doesn't have anything in 
> it.  In our process, we have mapped this to staging, so that, when we create 
> a release, hg flow will create a branch under releases with whatever name we 
> come up with.  example: releases/rel_12
> Once we deem this release as tested and ready to go live, hg flow will then 
> merge it into the default (sometimes known as master) branch, which is where 
> we then push out to our servers for production.
> It would be nice, if the Jenkins Mercurial plugin could help match this 
> process.  As it is today, when we create a new release, I have Jenkins set up 
> with a parameter for the job, that we have to type in the current release 
> branch every time we push an update. It would be nice if there could a 
> checkbox or job config that would tell jenkins which of the top branches to 
> monitor (releases,default,develop, etc.).  Then the process would go as:
> # query hg branches and look for any branches under the branch named in the 
> above config variable
> ## if its the releases branch, there should always only be 0 or 1 according 
> to hg flow
> ## if 0, nothing for jenkins to do
> ## if more than 1, some kind of process problem, jenkins shouldn't continue
> # assuming there is a branch under releases, switch to it
> # run hg update on the branch
> ## if there are updates, process updates, run rest of job, capture the branch 
> name (example: rel_15 for the branch releases/rel_15) and allow it to be a 
> variable for post build actions (example: to be used with Jira plugin to tag 
> tickets with the release branch for Jira changelog)
> ## if not, don't process rest of job

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13329) Mercurial debug causes clone repository each time Mrather than update

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on JENKINS-13329 started by Kohsuke Kawaguchi.

> Mercurial debug causes clone repository each time Mrather than update
> -
>
> Key: JENKINS-13329
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13329
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
> Environment: Linux, Jenkis 1.458, mercurial 1.7
>Reporter: Vladimir Kralik
>Assignee: Kohsuke Kawaguchi
>Priority: Minor
>
> JENKINS-4672 gives possibility to setup Marcurial debug flag.
> When I switch it on, the all mercurial call is done with option "--debug".
> The first command, during the build, checks if configuration of repository 
> wasn't changed.
> This check is done by comparision result of commad "hg showconfig 
> paths.default" with jenkins configuration.
> But there is a different output if the debug option is ON.
> Without debug option : 
>  $ hg showconfig paths.default
>  https://hg/hg/zpis
> With debug option : 
>  hg --debug showconfig paths.default
>  read config from: /etc/mercurial/hgrc
>  read config from: /data/hudson/.hgrc
>  none: https://hg/hg/zpis
> So with the debug option, the mercurial configuration is always different as 
> jenkins configuration.
> Result is : 
> ---
> Building in workspace /data/hudson/jobs/vlk-pokus/workspace
> [workspace] $ hg --debug showconfig paths.default
> read config from: /etc/mercurial/hgrc
> read config from: /data/hudson/.hgrc
> none: https://hg/hg/zpis
> which looks different than https://hg/hg/zpis
> so falling back to fresh clone rather than incremental update
> Workaround : Switch off the degug option.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13149) SCM Poll causing non-stop builds

2012-05-01 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162279#comment-162279
 ] 

jglick commented on JENKINS-13149:
--

Subrepos are not yet supported (JENKINS-4838). No idea how the plugin behaves 
with the largefiles extension, but probably there are bugs; certainly 
interaction with this plugin is not tested.

> SCM Poll causing non-stop builds
> 
>
> Key: JENKINS-13149
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13149
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
> Environment: HG 2.0.1 / Jenkins 1.456 / Plugin 1.3.8
>Reporter: Justin Rovang
>Assignee: Kohsuke Kawaguchi
>Priority: Critical
>
> I hate to bring such conflicting information into a bug report but I'm at a 
> loss on this!
> This only happens for this one repo - I've deleted and re-created it, and 
> setup from scratch with no joy.
> HG SCM Poll log insists it's finding changes  and is firing a build off of 
> 'Dependent changes detected'.
> Started on Mar 19, 2012 11:00:24 PM
> [src] $ hg pull --rev default
> pulling from /var/hg/repos/mpl
> no changes found
> [src] $ hg log --style 
> /var/lib/jenkins/jobs/mpl/workspace/tmp2857899180971434423style --branch 
> default --no-merges --prune 9c80c470fa3ef8d89c2352c08babb3f466b9aa24
> id:5b02d29a94c43648da2eb0a16f12c2e42eb46c87
> files:build.xml:
> Dependent changes detected
> Done. Took 0.21 sec
> Changes found
> There's no open/un-merged heads in the repo either:
> default  141:9c80c470fa3e
> If I downgrade to 1.3.7, it works fine (seems to run a different technique)
> HG SCM Poll log from 1.3.7: 
> Started on Mar 19, 2012 11:11:14 PM
> [src] $ hg incoming --style 
> /var/lib/jenkins/jobs/mpl/workspace/tmp1826463261407545325style --no-merges 
> --rev default --newest-first
> comparing with /var/hg/repos/mpl
> no changes found
> Done. Took 53 ms
> No changes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-12404) Mercurial poller triggers new build if workspace doesn't exist

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-12404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick resolved JENKINS-12404.
--

  Assignee: Willem Verstraeten  (was: Kohsuke Kawaguchi)
Resolution: Fixed

Seems to have been fixed in pull request #17 (1.39 plugin), so long as you have 
caching enabled. (Without caching it is not possible, since Mercurial has no 
commands to extract arbitrary information from a remote repository.)

> Mercurial poller triggers new build if workspace doesn't exist
> --
>
> Key: JENKINS-12404
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12404
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
> Environment: Master: RHEL 6.2 / Jenkins ver. 1.424.2 / Mercurial 
> plugin 1.38
> Slave: Fedora Core 15 i386 / workspaces located on a tmpfs mount
>Reporter: Yury Zaytsev
>Assignee: Willem Verstraeten
>
> Hi!
> I have workspaces on my slaves on tmpfs, so every time I reboot a slave the 
> workspace, of course, disappears. Now git and svn work totally fine with 
> that, but mercurial triggers a new build if the workspace doesn't exist and 
> leaves an entry like that in the polling log:
> {quote}
> This page captures the polling log that triggered this build.
> Started on Jan 12, 2012 10:30:55 PM
> No workspace is available, so can't check for updates.
> Scheduling a new build to get a workspace.
> Done. Took 14 ms
> Changes found
> {quote}
> This is very annoying, because sometimes I need to reboot the slaves to apply 
> kernel updates etc. and tmpfs is just so much faster than using a 
> non-volatile memory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-11368) redmineweb should be a supported repository browser type for all Version Control Systems

2012-05-01 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-11368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162277#comment-162277
 ] 

jglick commented on JENKINS-11368:
--

Speaking for the Mercurial plugin: if you use this service, you are best placed 
to write a browser plugin for it - submit a pull request.

> redmineweb should be a supported repository browser type for all Version 
> Control Systems
> 
>
> Key: JENKINS-11368
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11368
> Project: Jenkins
>  Issue Type: Improvement
>  Components: bazaar, mercurial
>Reporter: Al Budden
>Assignee: sdirector
>Priority: Minor
>
> Redmine supports a variety of version control systems (SVN, CVS, Git, 
> Mercurial, Bazaar and Darcs according to the website).  When using the git 
> plugin in Jenkins, among the repository browser options that are available is 
> redmineweb, to point at a redmine repository browser.  Is there any reason 
> why this can't also be offered for Mercurial and Bazaar?  (I haven't checked 
> whether is is offered for SVN, CVS or Darcs).
> I assume this would be extremely simple to implement...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-1420) Local repo location string not aggressively normalized

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick resolved JENKINS-1420.
-

Resolution: Duplicate

Possibly resolved by the fix of JENKINS-13400. If the problem persists in the 
future, reopen (or file a new bug) and include the portion of the build log 
that says "...which looks different than..." as that will indicate how to write 
a test for the problem.

> Local repo location string not aggressively normalized
> --
>
> Key: JENKINS-1420
> URL: https://issues.jenkins-ci.org/browse/JENKINS-1420
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: medotin
>Assignee: jglick
>Priority: Minor
>
> This is v1.8 of the Mercurial plugin, and (though I believe it's irrelevant)
> 1.186 of hudson.
> I'm running Hudson on the same machine as my hg repo.  I entered the path to 
> my
> repo as /xyz.  The first build was fine, but because the cloned repo's hgrc 
> file
> listed the repo location as c:\xyz,
> hudson.plugins.mercurial.MercurialSCM.checkout saw these two strings as
> different and tried to do a clone instead of an update.  It correctly did an
> update once I changed my hudson config repo string to c:\xyz to match hgrc. 
> Perhaps there's some normalization to be done on local repo paths.
> On a side note, and I haven't looked into this, when it was trying to do the
> clone via first doing a delete, it could not delete the hgrc file (using
> Windows).  However if I deleted hgrc manually, then ran the build, it deleted
> the rest of the stuff just fine.  Seems like a bug.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-12361) Modules with directory separators don't work on Windows

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick resolved JENKINS-12361.
--

Resolution: Fixed

> Modules with directory separators don't work on Windows
> ---
>
> Key: JENKINS-12361
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12361
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
> Environment: Windows
>Reporter: Kevin Bell
>Assignee: Kevin Bell
>Priority: Minor
>  Labels: plugin, windows
>
> Specifying a module such as 'src/main' does not work on windows.
> Internally, the mercurial plugin converts the module paths to have unix '/' 
> separators, but paths returned by 'hg status' have '\' separators, so the 
> String.startsWith(...) test in MercurialSCM.dependentChanges() always returns 
> false.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-10706) MERCURIAL_BRANCH environment variable

2012-05-01 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-10706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162274#comment-162274
 ] 

jglick commented on JENKINS-10706:
--

GH pull requests will be considered. The attached patch is undesirable since it 
does not keep the branch information in {{MercurialTagAction}} like the other 
bits of info (changeset node ID, and recently also revision number).

> MERCURIAL_BRANCH environment variable
> -
>
> Key: JENKINS-10706
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10706
> Project: Jenkins
>  Issue Type: New Feature
>  Components: mercurial
>Reporter: Sergiu Ivasenco
>Assignee: Kohsuke Kawaguchi
> Attachments: 0001-Added-MERCURIAL_BRANCH-variable.patch
>
>
> Currently the plugin makes available only the variable MERCURIAL_REVISION.
> Would it make sense to add MERCURIAL_BRANCH?
> Please find attached the patch that does it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-10706) MERCURIAL_BRANCH environment variable

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-10706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick updated JENKINS-10706:
-

Summary: MERCURIAL_BRANCH environment variable  (was: Adding more variables)

> MERCURIAL_BRANCH environment variable
> -
>
> Key: JENKINS-10706
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10706
> Project: Jenkins
>  Issue Type: New Feature
>  Components: mercurial
>Reporter: Sergiu Ivasenco
>Assignee: Kohsuke Kawaguchi
> Attachments: 0001-Added-MERCURIAL_BRANCH-variable.patch
>
>
> Currently the plugin makes available only the variable MERCURIAL_REVISION.
> Would it make sense to add MERCURIAL_BRANCH?
> Please find attached the patch that does it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-11991) Polling shows changes after job commits and pushes changes

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick closed JENKINS-11991.


Resolution: Duplicate

> Polling shows changes after job commits and pushes changes
> --
>
> Key: JENKINS-11991
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11991
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Reporter: Jarek Potiuk
>Assignee: Kohsuke Kawaguchi
>
> As of latest version of mercurial plugin (1.38) the behaviour of the plugin 
> changed. We used to make some manuals release jobs to commit some changes 
> (increase build number and set a tag) and push it to the origin repo. It 
> seems that now every time after release job is executed (and commit and push 
> happen), the plugin detects that the repo has changed and triggers another 
> build. It was not working like that before...
> Some outputs:
> 1st job (release job run manually):
> 21:25:04  [workspace] $ hg showconfig paths.default
> 21:25:04  [workspace] $ hg pull --rev 1_0
> 21:25:04  [workspace] $ hg update --clean --rev 1_0
> 21:25:04  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 21:25:04  [workspace] $ hg log --rev . --template {node}
> 21:25:05  [workspace] $ hg log --rev cc3b37d8df1298eabedfad328cbd4a068e27abf8
> 21:25:05  [workspace] $ hg log --template " author='{author|xmlescape}' rev='{rev}' 
> date='{date}'>{desc|xmlescape}{file_adds|stringify|xmlescape}{file_dels|stringify|xmlescape}{files|stringify|xmlescape}{parents}\n"
>  --rev 1_0:0 --follow --prune cc3b37d8df1298eabedfad328cbd4a068e27abf8
> Inside the job:
> hg commit -m "Incrementing application version to 1.0-TEST (345" -u 
> b...@polidea.pl AndroidManifest.xml 
> hg tag -f Release_1.0-TEST_345 -u b...@polidea.pl
> hg push 
> Then polling triggers another job:
> 21:27:04  Started by an SCM change
> 21:27:04  Building on master
> 21:27:04  [workspace] $ hg showconfig paths.default
> 21:27:04  [workspace] $ hg pull --rev 1_0
> 21:27:04  [workspace] $ hg update --clean --rev 1_0
> 21:27:04  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 21:27:04  [workspace] $ hg log --rev . --template {node}
> 21:27:05  [workspace] $ hg log --rev cc3b37d8df1298eabedfad328cbd4a068e27abf8
> 21:27:05  [workspace] $ hg log --template " author='{author|xmlescape}' rev='{rev}' 
> date='{date}'>{desc|xmlescape}{file_adds|stringify|xmlescape}{file_dels|stringify|xmlescape}{files|stringify|xmlescape}{parents}\n"
>  --rev 1_0:0 --follow --prune cc3b37d8df1298eabedfad328cbd4a068e27abf8

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13292) Problem to update to a tagged revision

2012-05-01 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick closed JENKINS-13292.


Resolution: Duplicate

Using tag names in the "branch" field was never tested or supported. If it 
happened to work in some versions of the plugin, it was by accident.

> Problem to update to a tagged revision
> --
>
> Key: JENKINS-13292
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13292
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: Helen Her
>Assignee: Kohsuke Kawaguchi
>
> In the previous version we were able to clone the remote repository and 
> update it to a tagged revision
> as you can see the log here, v4.6.0.118 it's the tag of the branch r4.6.0.118
> $ hg clone --rev v4.6.0.118 remote_repository_url local_repository
> adding changesets
> adding manifests
> adding file changes
> added 199 changesets with 13401 changes to 6466 files
> updating to branch r4.6.0.118
> But when we updated the plugin to the version 1.38, we couldn't clone the 
> remote repository and update it to a tagged revision
> $ hg clone --rev v4.6.0.118 --noupdate remote_repository_url local_repository
> adding changesets
> adding manifests
> adding file changes
> added 199 changesets with 13401 changes to 6466 files
> [v4.6.0.118] $ hg update --rev v4.6.0.118
> abort: unknown revision 'v4.6.0.118'!
> So we had to downgrade the mercurial plugin to 1.37 for the time being.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-11549) return changeset integer revision id to environment as well as the node

2012-05-01 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-11549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162266#comment-162266
 ] 

jglick commented on JENKINS-11549:
--

https://github.com/jenkinsci/mercurial-plugin/pull/23 has a better patch, will 
use that.

> return changeset integer revision id to environment as well as the node
> ---
>
> Key: JENKINS-11549
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11549
> Project: Jenkins
>  Issue Type: Improvement
>  Components: mercurial, plugin
>Affects Versions: current
>Reporter: Trevor Baker
>Assignee: Kohsuke Kawaguchi
>Priority: Minor
> Attachments: hg_revid.patch
>
>
> Our builds require the integer revision id {rev} as well as the hash.  The 
> following patch created a new environment variable MERCURIAL_REVISIONID and 
> assigns the {rev} to it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-7239) Support Excluded Regions in SCM Polling

2012-04-30 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162230#comment-162230
 ] 

jglick commented on JENKINS-7239:
-

No one working on this (or JENKINS-5480) at the moment I think. Would be good 
to have an updated pull request that solves these two together, probably using 
regexps for flexibility. Needs to quietly upgrade existing job configs, as 
{{HUDSON-5480.diff}} did.

> Support Excluded Regions in SCM Polling
> ---
>
> Key: JENKINS-7239
> URL: https://issues.jenkins-ci.org/browse/JENKINS-7239
> Project: Jenkins
>  Issue Type: New Feature
>  Components: mercurial
>Reporter: gilesie
>Assignee: jglick
> Attachments: hudson-mercurial-excluded-regions.patch, 
> hudson-mercurial-excluded-regions.patch
>
>
> Currently there is no support for excluding regions of the repository from 
> SCM polling modifications to prevent unwanted builds.
> Attached is a patch to provide this functionality that is the same as the 
> functionality in the CVS SCM.
> If set Hudson will ignore any files and/or folders in this list when 
> determining if a build needs to be triggered.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-10558) Jenkins mercurial plugin - add support for bookmarks

2012-04-30 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-10558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162226#comment-162226
 ] 

jglick commented on JENKINS-10558:
--

http://mercurial.selenic.com/wiki/Bookmarks is the current feature description.

Since it makes no sense to specify both a branch name and a bookmark, probably 
the UI should be a checkbox that indicates that the "branch" field is really a 
bookmark name. (It would be great if the plugin could automatically detect 
this, but I doubt that is possible.)

Pull requests implementing this feature without affecting existing usage would 
be considered. (Wujek's change may make subtle changes to behavior of jobs not 
using bookmarks; the use of {{\--rev}} rather than {{\--branch}} is 
intentional. It also includes no new tests, is long out of date with 
{{master}}, and does not seem to be available as a pull request anyway.)

> Jenkins mercurial plugin - add support for bookmarks
> 
>
> Key: JENKINS-10558
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10558
> Project: Jenkins
>  Issue Type: New Feature
>  Components: mercurial
>Affects Versions: current
> Environment: all
>Reporter: wujek srujek
>Assignee: Kohsuke Kawaguchi
>Priority: Critical
>
> Mercurial plugin supports branches, which is nice. However, there are a lot 
> of people, especially these coming from git, who think that such named 
> branches are no good (they stay for ever, the branch is baked into the 
> commit), and prefer using bookmarks* instead. There seems to be a lot of 
> momentum around that extension, which culminated in it being incorporated 
> into mercurial core since hg 1.8 (which means it is not an extension any 
> more; rather, it is a first-class citizen now).
> * http://mercurial.selenic.com/wiki/BookmarksExtension, 
> http://www.mronge.com/2009/04/01/a-sample-mercurial-bookmark-workflow, 
> http://groups.google.com/group/mercurial_general/browse_thread/thread/5f7d2d7c5cfc109b?fwc=2
>  (post #4 by Daniel Carrera is really good)
> Bookmarks is the closest thing that mercurial currently supports that 
> resembles git-like branches. This is what we would love to use (as we share 
> the view that such long running named branches are no good), but we can't 
> since the Jenkins plugin doesn't support this (we would like to create ad-hoc 
> Jenkins jobs for our features (topic branches), which are bookmarks, not 
> branches, and once the feature is implemented, we drop the Jenkins job).
> A basic bookmarks workflow (in a repository):
> $ hg bookmark feature_x
> ... work work work
> $ hg commit -m 'some feature_x code'
> ... push to some canonical repo for others to see
> $ hg push -B feature_x -f // -f most likely needed as bookmarks are simply 
> 'named heads' - but it doesn't matter for Jenkins
> Now some other collaborator:
> $ hg incoming -B // shows that there is a new bookmark, 'feature_x'
> $ hg pull -B feature_x
> and they can now start working on this bookmark ('lightweight branch').
> I tried simply changing the value of the 'branch' field in my project 
> configuration, but it doesn't work. But it is very close. What seems not to 
> work is the fact that Jenkins doesn't know the '-B' switch, and doesn't know 
> that I want to import the bookmark. What Jenkins does is this (shortened a 
> little, the template is not used):
> $ hg incoming --quiet --bundle hg.bundle --template "..." --rev feature_x
> $ hg unbundle hg.bundle
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> $ hg update --clean --rev feature_x
> abort: unknown revision 'test'!
> This means that the incoming changes were found with the bookmark name and 
> were pulled, but the bookmark itself wasn't imported, and doesn't exist 
> locally - and update fails. With the '-B' switch, it would work fine (tested 
> on the command line):
> $ hg incoming --quiet --bundle hg.bundle --template "..." --rev feature_x
> $ hg unbundle hg.bundle
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> $ hg pull -B feature_x // <- that's the missing 
> link
> no changes found
> importing bookmark test
> $ hg update --clean --rev feature_x
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> With the single call to pull the bookmark (which effectively imports it) 
> makes it work!
> Of course, there could be a mix of branch and bookmark, so the 'incoming' 
> should use the branch name, and if and only if a bookmark is specified, a 
> 'pull -B ' should be issued, and the update should

[JIRA] (JENKINS-4838) Subrepo support

2012-04-30 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162223#comment-162223
 ] 

jglick edited comment on JENKINS-4838 at 4/30/12 8:20 PM:
--

I do not know of anyone actively working on this. Since my organization does 
not use subrepos I am not inclined to work on it myself.

I would expect it to be a relatively difficult change, i.e. you would need to 
understand all aspects of the current plugin; handle (or explicitly forbid) 
interaction with various existing features such as caching & sharing, polling 
exclusions, and browsers, which are all written to assume that the portion of 
the workspace under consideration is the checkout of one node of one 
repository; and write a full JUnit suite detailing the expected behavior, 
ideally before starting to make changes to main sources.

Note that for jobs formerly using the Forest extension the recommendation is to 
use the Multi-SCM plugin instead - basically configuring a separate instance of 
the Mercurial plugin for each repo in the "forest". This seems to work fine, if 
perhaps a little more verbose to configure. But subrepos work differently due 
to {{.hgsubstate}}, so I doubt you could use the Multi-SCM plugin for this 
purpose.

Also beware of subrepos using foreign SCMs like Subversion; it is not clear 
whether or how the Mercurial plugin (in cooperation with other SCM plugins) 
could behave correctly with such a setup.

  was (Author: jglick):
I do not know of anyone actively working on this. Since my organization 
does not use subrepos I am not inclined to work on it myself.

I would expect it to be a relatively difficult change, i.e. you would need to 
understand all aspects of the current plugin; handle (or explicitly forbid) 
interaction with various existing features such as caching & sharing, polling 
exclusions, and browsers, which are all written to assume that the portion of 
the workspace under consideration is the checkout of one node of one 
repository; and write a full JUnit suite detailing the expected behavior, 
ideally before starting to make changes to main sources.

Note that for jobs formerly using the Forest extension the recommendation is to 
use the Multi-SCM plugin instead - basically configuring a separate instance of 
the Mercurial plugin for each repo in the "forest". This seems to work fine, if 
perhaps a little more verbose to configure. But subrepos work differently due 
to `.hgsubstate`, so I doubt you could use the Multi-SCM plugin for this 
purpose.

Also beware of subrepos using foreign SCMs like Subversion; it is not clear 
whether or how the Mercurial plugin (in cooperation with other SCM plugins) 
could behave correctly with such a setup.
  
> Subrepo support
> ---
>
> Key: JENKINS-4838
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4838
> Project: Jenkins
>  Issue Type: New Feature
>  Components: mercurial
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: jglick
>Assignee: jglick
>
> In addition to supporting the Forest extension, it would be good to support 
> the
> new subrepo system in Hg 1.3+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-4838) Subrepo support

2012-04-30 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162223#comment-162223
 ] 

jglick commented on JENKINS-4838:
-

I do not know of anyone actively working on this. Since my organization does 
not use subrepos I am not inclined to work on it myself.

I would expect it to be a relatively difficult change, i.e. you would need to 
understand all aspects of the current plugin; handle (or explicitly forbid) 
interaction with various existing features such as caching & sharing, polling 
exclusions, and browsers, which are all written to assume that the portion of 
the workspace under consideration is the checkout of one node of one 
repository; and write a full JUnit suite detailing the expected behavior, 
ideally before starting to make changes to main sources.

Note that for jobs formerly using the Forest extension the recommendation is to 
use the Multi-SCM plugin instead - basically configuring a separate instance of 
the Mercurial plugin for each repo in the "forest". This seems to work fine, if 
perhaps a little more verbose to configure. But subrepos work differently due 
to `.hgsubstate`, so I doubt you could use the Multi-SCM plugin for this 
purpose.

Also beware of subrepos using foreign SCMs like Subversion; it is not clear 
whether or how the Mercurial plugin (in cooperation with other SCM plugins) 
could behave correctly with such a setup.

> Subrepo support
> ---
>
> Key: JENKINS-4838
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4838
> Project: Jenkins
>  Issue Type: New Feature
>  Components: mercurial
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: jglick
>Assignee: jglick
>
> In addition to supporting the Forest extension, it would be good to support 
> the
> new subrepo system in Hg 1.3+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13400) Workspace repository is not updated, and will be dropped and re-cloned

2012-04-30 Thread jgl...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162216#comment-162216
 ] 

jglick commented on JENKINS-13400:
--

{{file:/var/hg/bar}} (no specified host component) is the preferred syntax, 
which is why the plugin is getting confused.

> Workspace repository is not updated, and will be dropped and re-cloned
> --
>
> Key: JENKINS-13400
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13400
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: cactusman
>Assignee: cactusman
>
> If the Mercurial repository 'file://', has determined a different repository 
> Jenkins Mercurial plugin by mistake.
> Therefore, the repository of the Workspace repository is not updated, and 
> will be droped and re-cloned.
> Console output:
> [workspace] $ hg showconfig paths.default
> ERROR: Workspace reports paths.default as /var/hg/bar
> which looks different than file:///var/hg/bar
> so falling back to fresh clone rather than incremental update

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13400) Workspace repository is not updated, and will be dropped and re-cloned

2012-04-30 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick updated JENKINS-13400:
-

Summary: Workspace repository is not updated, and will be dropped and 
re-cloned  (was: Workspace repository is not updated, and will be droped and 
re-cloned)

> Workspace repository is not updated, and will be dropped and re-cloned
> --
>
> Key: JENKINS-13400
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13400
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
>Affects Versions: current
>Reporter: cactusman
>Assignee: cactusman
>
> If the Mercurial repository 'file://', has determined a different repository 
> Jenkins Mercurial plugin by mistake.
> Therefore, the repository of the Workspace repository is not updated, and 
> will be droped and re-cloned.
> Console output:
> [workspace] $ hg showconfig paths.default
> ERROR: Workspace reports paths.default as /var/hg/bar
> which looks different than file:///var/hg/bar
> so falling back to fresh clone rather than incremental update

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13637) Cannot release using M3

2012-04-27 Thread jgl...@java.net (JIRA) 
jglick created JENKINS-13637:


 Summary: Cannot release using M3
 Key: JENKINS-13637
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13637
 Project: Jenkins
  Issue Type: Bug
  Components: plugin
 Environment: Ubuntu, JDK 6
Reporter: jglick


Given the {{mercurial}} plugin with parent 
{{org.jenkins-ci.plugins:plugin:1.400}}, but also reproducible with {{1.461}}, 
Maven 3 {{mvn -B release:prepare}} fails with

{code}
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] Transforming 'Jenkins Mercurial plugin'...
Downloading: 
/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.pom
[WARNING] The POM for org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 is 
missing, no dependency information available
Downloading: 
/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.jar
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 5.310s
[INFO] Finished at: Fri Apr 27 19:30:03 EDT 2012
[INFO] Final Memory: 10M/164M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on 
project mercurial: Execution default-cli of goal 
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare failed: Failed to 
build parent project for org.jenkins-ci.plugins:mercurial:hpi:1.39-SNAPSHOT: 
Some problems were encountered while processing the POMs:
[ERROR] [ERROR] Unresolveable build extension: Plugin 
org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not 
be resolved: Could not find artifact 
org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (/) 
@: 1 problem was encountered while building the effective model for 
org.jenkins-ci.plugins:plugin:1.461
[ERROR] [ERROR] Unresolveable build extension: Plugin 
org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not 
be resolved: Could not find artifact 
org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (/) @
{code}

Indeed I think the error message is correct: {{plugin-1.400.pom}} (or again 
{{plugin-1.461.pom}}) refers to {{maven-hpi-plugin}} yet does not declare any 
{{}} in which it might be found. (Nor does its own parent.)

Maven 2 succeeds in this case; apparently it does not care where the plugin 
came from. But Maven 3 as described in 
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
 does care.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13428) CCE: cannot assign instance of StreamBuildListener to field MercurialSCM$1.val$listener of type BuildListener

2012-04-12 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick resolved JENKINS-13428.
--

Resolution: Fixed

Seems the {{checkout}} method makes an anonymous {{FileCallable}}. Was 
apparently fixed in ef5b34289131b737a4329fc6544015e79be01c96. Should be fixed 
in 1.38 version of the plugin.

> CCE: cannot assign instance of StreamBuildListener to field 
> MercurialSCM$1.val$listener of type BuildListener
> -
>
> Key: JENKINS-13428
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13428
> Project: Jenkins
>  Issue Type: Bug
>  Components: mercurial
> Environment: Linux on master and slave. Hudson 2.1.2, Mercurial 
> plugin 1.35.
>Reporter: jglick
>Assignee: jglick
>  Labels: remoting, serialization
>
> We frequently - but not usually - get build failures of the form:
> {code}
> See 
> --
> Started by timer
> Building remotely on Push-to-Silver-Node
> FATAL: cannot assign instance of hudson.model.StreamBuildListener to field 
> hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
> hudson.model.BuildListener in instance of 
> hudson.plugins.mercurial.MercurialSCM$1
> java.lang.ClassCastException: cannot assign instance of 
> hudson.model.StreamBuildListener to field 
> hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
> hudson.model.BuildListener in instance of 
> hudson.plugins.mercurial.MercurialSCM$1
>   at 
> java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2039)
>   at 
> java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
>   at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1952)
>   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
>   at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
>   at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
>   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
>   at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
>   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
>   at hudson.remoting.UserRequest.deserialize(UserRequest.java:178)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:98)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:283)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>   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:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> {code}
> The job config in this case is
> {code:xml}
> 
>   default Mercurial with caching
>   http://hg.netbeans.org/main-silver/
>   
>   false
>   false
>   
> http://hg.netbeans.org/main-silver/
>   
> 
> {code}
> but other jobs also fail as well. Possibly a problem with unserializable 
> anonymous classes being passed around in remoting.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13428) CCE: cannot assign instance of StreamBuildListener to field MercurialSCM$1.val$listener of type BuildListener

2012-04-12 Thread jgl...@java.net (JIRA) 

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jglick updated JENKINS-13428:
-

Description: 
We frequently - but not usually - get build failures of the form:

{code}
See 
--
Started by timer
Building remotely on Push-to-Silver-Node
FATAL: cannot assign instance of hudson.model.StreamBuildListener to field 
hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
hudson.model.BuildListener in instance of 
hudson.plugins.mercurial.MercurialSCM$1
java.lang.ClassCastException: cannot assign instance of 
hudson.model.StreamBuildListener to field 
hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
hudson.model.BuildListener in instance of 
hudson.plugins.mercurial.MercurialSCM$1
at 
java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2039)
at 
java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1952)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:178)
at hudson.remoting.UserRequest.perform(UserRequest.java:98)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:283)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}

The job config in this case is

{code:xml}

  default Mercurial with caching
  http://hg.netbeans.org/main-silver/
  
  false
  false
  
http://hg.netbeans.org/main-silver/
  

{code}

but other jobs also fail as well. Possibly a problem with unserializable 
anonymous classes being passed around in remoting.

  was:
We frequently - but not usually - get build failures of the form:

See 
--
Started by timer
Building remotely on Push-to-Silver-Node
FATAL: cannot assign instance of hudson.model.StreamBuildListener to field 
hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
hudson.model.BuildListener in instance of 
hudson.plugins.mercurial.MercurialSCM$1
java.lang.ClassCastException: cannot assign instance of 
hudson.model.StreamBuildListener to field 
hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
hudson.model.BuildListener in instance of 
hudson.plugins.mercurial.MercurialSCM$1
at 
java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2039)
at 
java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1952)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:178)
at hudson.remoting.UserRequest.perform(UserRequest.java:98)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:283)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask

[JIRA] (JENKINS-13428) CCE: cannot assign instance of StreamBuildListener to field MercurialSCM$1.val$listener of type BuildListener

2012-04-12 Thread jgl...@java.net (JIRA) 
jglick created JENKINS-13428:


 Summary: CCE: cannot assign instance of StreamBuildListener to 
field MercurialSCM$1.val$listener of type BuildListener
 Key: JENKINS-13428
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13428
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
 Environment: Linux on master and slave. Hudson 2.1.2, Mercurial plugin 
1.35.
Reporter: jglick
Assignee: jglick


We frequently - but not usually - get build failures of the form:

See 
--
Started by timer
Building remotely on Push-to-Silver-Node
FATAL: cannot assign instance of hudson.model.StreamBuildListener to field 
hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
hudson.model.BuildListener in instance of 
hudson.plugins.mercurial.MercurialSCM$1
java.lang.ClassCastException: cannot assign instance of 
hudson.model.StreamBuildListener to field 
hudson.plugins.mercurial.MercurialSCM$1.val$listener of type 
hudson.model.BuildListener in instance of 
hudson.plugins.mercurial.MercurialSCM$1
at 
java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2039)
at 
java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1952)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:178)
at hudson.remoting.UserRequest.perform(UserRequest.java:98)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:283)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

The job config in this case is

  
default Mercurial with caching
http://hg.netbeans.org/main-silver/

false
false

  http://hg.netbeans.org/main-silver/

  

but other jobs also fail as well. Possibly a problem with unserializable 
anonymous classes being passed around in remoting.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira