-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: mercurial-plugin
-
Labels:None
-
Environment:Hudson ver. 1.351
-
Similar Issues:
I am using the "Modules" feature of the Mercurial SCM plugin. Unfortunately, this feature does not work as expected.
After starting Hudson, a build will be triggered as soon as a file in the specified module was changed. After a change to a file outside this module, the plugin does not trigger a build as expected ("No changes").
However, although there is a change to a file within the module afterward, the plugin does not detect any change ("No changes"). Though, the "Last Mercurial Polling Log" shows these changed files; there are lines starting with "files:<MODULE>/..."
Restarting Hudson or reloading its configuration does work as a work-around: the next poll will trigger a build - until there is a change outside the module again.
- is duplicated by
-
-
- Closed
-
The error still exists with mercurial-plugin 1.30 and hudson 1.360. Below you can find the obfuscated polling log.
"file2.java" in module "job1" was modified but "job1" build was never triggered.
Started on 01.06.2010 11:35:37
[workspace] $ hg incoming --style "/hudson/jobs/job1/workspace/tmp6554723463433914461style" --no-merges --rev default
comparing with *******************
searching for changes
id:d86b04c63d49ca532342347a93f0ce65cc95b132
files:job2/src/main/webapp/WEB-INF/templates/template1.jsp:
id:5a9ae558edb70dfdddd5979a2b1c1f3cdb43cbed
files:job2/src/main/java/file1.java:job2/src/main/java/file3.java:job2/src/main/webapp/WEB-INF/templates/template2.jsp:job2/src/main/webapp/WEB-INF/templates/template3.jsp:
id:c929549a063426434370b8bbb1e1dbc595d449c3
files:info.txt:
id:deaac939488c0c40d551234234a44da674bee588
files:job2/src/main/webapp/WEB-INF/templates/template5.jsp:
id:587ff66fca234157a20c7ec3243cfd89760f927b
files:job2/src/main/webapp/WEB-INF/templates/template6.jsp:job2/src/main/webapp/WEB-INF/templates/template7.jsp:job1/src/main/java/file2.java
I would need a test case to investigate.
I get this reliably on my system as well. Not sure what you need as a test case?
kohsuke's 27063 seems to have broken things; if parseIncomingOutput gets
id:123 files:ignored: id:456 files:relevant:
where 123 was present in a previous poll,
if (id.equals(baseline.id)) {
break; // no need to go beyond this line
}
stops the parsing at 123 since that is baseline.id. Passing --newest-first to incoming seems to work.
Still trying to reproduce in a test case, however; calling Project.poll(TaskListener) appears to work fine.
Code changed in hudson
User: : jglick
Path:
trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialSCM.java
trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialTagAction.java
trunk/hudson/plugins/mercurial/src/test/java/hudson/plugins/mercurial/MercurialSCMTest.java
http://jenkins-ci.org/commit/31922
Log:
JENKINS-6337 Polling logic broken for modules.
Worked last I checked, and there is test coverage for this. Is still still reproducible for you? Do you have a minimal test case?