[JIRA] (JENKINS-60041) P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US
Title: Message Title Ken Morse commented on JENKINS-60041 Re: P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US I got suspicious that maybe the Jenkins cache (%USERPROFILE%\.jenkins\cache) had become corrupt so I deleted the folder and restarted the agent. That completely corrected the problem reported. I can't say why this happened in the first place or why the P4 plugin was singled out, but all seems well now. Thank you Paul Allen and Karl Wirth. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202869.1572884428000.9362.1572964920409%40Atlassian.JIRA.
[JIRA] (JENKINS-60041) P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US
Title: Message Title Ken Morse commented on JENKINS-60041 Re: P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US Sure, Karl Wirth – log of brand new Freestyle job below and screenshot attached. Started by user Ken Running as SYSTEM [EnvInject] - Loading node environment variables. Building remotely on buildvpc10 in workspace E:\WinPC\Main\p4test (p4):cmd:... p4 login -s p4 login -s User p4dti-replicator0 ticket expires in 8 hours 40 minutes. (p4):stop:3 (p4):cmd:... p4 client -o BuildMachine-Perforce-Test p4 client -o BuildMachine-Perforce-Test (p4):stop:4 (p4):cmd:... p4 counter change p4 counter change (p4):stop:5 (p4):cmd:... p4 changes -m1 -ssubmitted //BuildMachine-Perforce-Test/... p4 changes -m1 -ssubmitted //BuildMachine-Perforce-Test/... Change 34054 on 2014/03/05 by Ken@Ken_Viper_P4Test 'Test change 2 of 2. ' (p4):stop:6 (p4):cmd:... p4 counter change p4 counter change (p4):stop:7 (p4):cmd:... p4 changes -m1 -ssubmitted //BuildMachine-Perforce-Test/...@33054,34054 p4 changes -m1 -ssubmitted //BuildMachine-Perforce-Test/...@33054,34054 Change 34054 on 2014/03/05 by Ken@Ken_Viper_P4Test 'Test change 2 of 2. ' (p4):stop:8 P4: builds: 34054 P4: Connection retry: 1 Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US ERROR: P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US Finished: FAILURE Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-60041) P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US
Title: Message Title Ken Morse updated an issue Jenkins / JENKINS-60041 P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US Change By: Ken Morse Attachment: P4SCM.png Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202869.1572884428000.8551.1572894300310%40Atlassian.JIRA.
[JIRA] (JENKINS-60041) P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US
Title: Message Title Ken Morse created an issue Jenkins / JENKINS-60041 P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US Issue Type: Bug Assignee: Unassigned Components: p4-plugin Created: 2019-11-04 16:20 Environment: Windows 10, Jenkins 2.190.2 (LTS) Priority: Blocker Reporter: Ken Morse Since around plugin version 1.10.5, get the following when using Perforce as Source repository: P4: builds: 35908 P4: Connection retry: 1 Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US ERROR: P4: Task Exception: Can't find bundle for base name org.jenkinsci.plugins.p4.Identifier, locale en_US Add Comment
[JIRA] (JENKINS-51716) Blueocean stuck in loading
Title: Message Title Ken Morse commented on JENKINS-51716 Re: Blueocean stuck in loading Gavin Mogan - just confirmed that 1.14.0 does fix the problem I was seeing in Blue Ocean. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51716) Blueocean stuck in loading
Title: Message Title Ken Morse commented on JENKINS-51716 Re: Blueocean stuck in loading Gavin Mogan Here's what I'm seeing in the console: Error fetching page TypeError: Cannot read property 'self' of undefined at ActivityService.bunkerKey (blueocean-core-js.js:57498) at ActivityService.setItem (blueocean-core-js.js:57541) at executeAction (blueocean-core-js.js:40729) at ActivityService.res (blueocean-core-js.js:40701) at PipelineService._this.bunkerMapper (blueocean-core-js.js:58507) at PipelineService.setItem (blueocean-core-js.js:57540) at executeAction (blueocean-core-js.js:40729) at PipelineService.res (blueocean-core-js.js:40701) at blueocean-core-js.js:57559 at Array.map () at PipelineService.setItems (blueocean-core-js.js:57558) at blueocean-core-js.js:58160 at executeAction (blueocean-core-js.js:40729) at res (blueocean-core-js.js:40701) (anonymous) @ blueocean-core-js.js:58176 Will send you the log as well. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51716) Blueocean stuck in loading
Title: Message Title Ken Morse commented on JENKINS-51716 Re: Blueocean stuck in loading Gavin Mogan – be happy to send whatever would be useful. I see the problem on the main Jenkins screen (with all the Jobs showing), then select "Open Blue Ocean" from the left sidebar. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51716) Blueocean stuck in loading
Title: Message Title Ken Morse commented on JENKINS-51716 Re: Blueocean stuck in loading I still see this behavior in Jenkins 2.150.3 and BO 1.13.1. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51716) Blueocean stuck in loading
Title: Message Title
Ken Morse commented on JENKINS-51716
Re: Blueocean stuck in loading
Am still stuck in loading as well, now using Jenkins 2.138.1 (LTS) and Blue Ocean 1.8.3. There is still a _javascript_ error which may be contributing to the problem: VM1191 blueocean-core-js.js:57938 Error fetching page TypeError: Cannot read property 'self' of undefined {{ at ActivityService.bunkerKey (VM1191 blueocean-core-js.js:57260)}} {{ at ActivityService.setItem (VM1191 blueocean-core-js.js:57303)}} {{ at executeAction (VM1191 blueocean-core-js.js:40729)}} {{ at ActivityService.res (VM1191 blueocean-core-js.js:40701)}} {{ at PipelineService._this.bunkerMapper (VM1191 blueocean-core-js.js:58269)}} {{ at PipelineService.setItem (VM1191 blueocean-core-js.js:57302)}} {{ at executeAction (VM1191 blueocean-core-js.js:40729)}} {{ at PipelineService.res (VM1191 blueocean-core-js.js:40701)}} {{ at VM1191 blueocean-core-js.js:57321}} {{ at Array.map ()}} {{ at PipelineService.setItems (VM1191 blueocean-core-js.js:57320)}} {{ at VM1191 blueocean-core-js.js:57922}} {{ at executeAction (VM1191 blueocean-core-js.js:40729)}} {{ at res (VM1191 blueocean-core-js.js:40701)}}
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-plugin] (JENKINS-34409) Document accessing environment variables in Git Publisher
Title: Message Title Ken Morse created an issue Jenkins / JENKINS-34409 Document accessing environment variables in Git Publisher Issue Type: Improvement Assignee: Mark Waite Components: git-plugin Created: 2016/Apr/23 12:47 PM Environment: Mac OS 10.11, Windows 10, Jenkins 1.651, Git Plugin 2.4.4. Priority: Minor Reporter: Ken Morse Popup documentation for tag in Git Publisher states: Environment variables may be used in the tag name - they will be replaced at build time. It would be great if this text also included how to access the variables. It appears to be a simple $ prefix on Mac but is that platform specific? Just another sentence in the documentation here could really help. Add Comment
[JIRA] [postbuild-task-plugin] (JENKINS-12303) Post build task - 'Add another task' does not work
Ken Morse commented on JENKINS-12303 Post build task - Add another task does not work @b2jrock great work-around, will have to give that a try! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [p4-plugin] (JENKINS-26696) On Windows, P4 plugin pulls down wrong encoding for UTF-16
Ken Morse created JENKINS-26696 On Windows, P4 plugin pulls down wrong encoding for UTF-16 Issue Type: Bug Assignee: Unassigned Components: p4-plugin Created: 29/Jan/15 6:21 PM Description: When using the new P4 Plugin to populate a workspace, we noticed that if a file of type UTF-16 is pulled down by the plugin, it will be encoded in Big-endian format instead of the Little-endian format more appropriate for Windows. Syncing this same file with either the p4 command line utility or P4V will bring down the file with the proper encoding. Environment: Jenkins 1.580.3 running on 64-bit Windows 8.1, P4 Plugin 1.1.2 Project: Jenkins Priority: Major Reporter: Ken Morse This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [slave-setup] (JENKINS-18697) Can't launch agent on slave using jnlp file
Ken Morse created JENKINS-18697 Cant launch agent on slave using jnlp file Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: slave-setup Created: 10/Jul/13 6:39 PM Description: With recent updates to Jenkins or Java, the UI no longer shows when launching the JNLP file from a browser on the slave (orange launch button), or when running "javaws http://path/slave-agent.jnlp" on the slave from the command line. Interestingly, the headless version does work, "java -jar slave.jar -jnlpUrl http://path/slave-agent.jnlp". Global Security is not enabled so this does not appear to be a security issue (not to mention the headless version works). Perhaps there is an issue with displaying the "Jenkins Slave Agent" window? There doesn't seem to be any error returned, but I note that after attempting a launch, Task Manager shows an instance of "Java Platform SE binary" remains running. Environment: Slave is 64-bit Windows 8 PC with JDK version 1.6.0_43. Project: Jenkins Priority: Major Reporter: Ken Morse This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-17580) Add token for project Display Name
Ken Morse commented on JENKINS-17580 Add token for project Display Name Very cool! Thanks, Alex! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163480#comment-163480 ] Ken Morse commented on JENKINS-13174: - Perhaps the user should be able to configure which files are ignored by the plugin. Alternatively, the build looping problem could also be resolved by ignoring any changes from the build machine, rather than ignoring changes to particular files. 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
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162416#comment-162416 ] Ken Morse commented on JENKINS-13174: - Yes, hopefully we'll see a 1.40 released soon that includes the fix. 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: Kohsuke Kawaguchi 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
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162392#comment-162392 ] Ken Morse commented on JENKINS-13174: - @Jarek - thanks for the info. I had been wondering what might have changed as the plugin seemed to work flawlessly for polling before the 1.38 version. 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: Kohsuke Kawaguchi 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
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162346#comment-162346 ] Ken Morse commented on JENKINS-13174: - Curious why this build loop happened in the first place -- seems like the build machine would tag, then push, so any further comparison should show no change between the build machine and whatever repository it's polling... 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: Kohsuke Kawaguchi 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
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162270#comment-162270 ] Ken Morse commented on JENKINS-13174: - If there's any kind of logging we can turn on for this plugin or anything else we can do to help track down this problem, please let us know. 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: Kohsuke Kawaguchi 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
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161795#comment-161795 ] Ken Morse commented on JENKINS-13174: - Could be same issue as [JENKINS-11991|https://issues.jenkins-ci.org/browse/JENKINS-11991] - Polling shows changes after job commits and pushes changes. 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: Improvement Components: mercurial Affects Versions: current Reporter: Neil Kay Assignee: Kohsuke Kawaguchi 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
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Morse updated JENKINS-13174: Issue Type: Bug (was: Improvement) 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: Kohsuke Kawaguchi 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
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161695#comment-161695 ] Ken Morse commented on JENKINS-13174: - This is a big problem if the build tags its own release. I believe this issues is new with 1.38; we upgraded the plugin today and didn't have this problem earlier. 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: Improvement Components: mercurial Affects Versions: current Reporter: Neil Kay Assignee: Kohsuke Kawaguchi 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-11991) Polling shows changes after job commits and pushes changes
[
https://issues.jenkins-ci.org/browse/JENKINS-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161696#comment-161696
]
Ken Morse commented on JENKINS-11991:
-
We're seeing this happen too with 1.38; our build tags itself but that now
seems to cause an infinite loop of building. Maybe versions prior to 1.38
ignored the .hgtags file?
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 changeset node='{node}'
author='{author|xmlescape}' rev='{rev}'
date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\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 changeset node='{node}'
author='{author|xmlescape}' rev='{rev}'
date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\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
