[JIRA] [core] (JENKINS-15544) Jenkins leaks file handles when expanding a huge log
Mikko Tapaninen commented on JENKINS-15544 Jenkins leaks file handles when expanding a huge log Was able to reproduce with Jenkins 1.532.2, haven't tried more recent version. 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] [perforce] (JENKINS-23184) Perforce plugin to contribute more env variables for the build
Mikko Tapaninen created JENKINS-23184 Perforce plugin to contribute more env variables for the build Issue Type: Bug Assignee: Rob Petti Components: perforce Created: 26/May/14 8:38 AM Description: I would like Perforce plugin to contribute more environment variables for the build. These are what we need: PERFORCE_DEPOT the depot part of the stream definition (e.g. if stream field defined like //foo/bar then PERFORCE_DEPOT=foo) PERFORCE_STREAM the latter part of the stream definition (e.g. if stream field defined like //foo/bar then PERFORCE_STREAM=bar) PERFORCE_CHANGELIST_SOURCE same as P4_CHANGELIST PERFORCE_CHANGELIST_SOURCE_DATE the timestamp of the latest changelist (PERFORCE_CHANGELIST_SOURCE) in the build Project: Jenkins Priority: Major Reporter: Mikko Tapaninen 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] (JENKINS-17354) Label expression kills slave executors
Mikko Tapaninen
created JENKINS-17354
Label _expression_ kills slave executors
Issue Type:
Bug
Assignee:
kbertelson
Components:
matrixtieparent
Created:
26/Mar/13 11:44 AM
Description:
We noticed problems with using label _expression_ as "Node". In our case we used value "buildmachine (group of machine_1,...)". Once the build started, Jenkins started to loose the slave executors. They failed with:
SEVERE: Timer task hudson.model.Queue$MaintainTask@15db104e failed
java.lang.ClassCastException: hudson.model.labels.LabelExpression$And cannot be cast to hudson.model.labels.LabelAtom
at jenkins.model.Jenkins.getLabelAtom(Jenkins.java:1571)
at hudson.model.labels.LabelAtom.get(LabelAtom.java:224)
at hudson.model.labels.LabelExpressionParser.term6(LabelExpressionParser.java:208)
at hudson.model.labels.LabelExpressionParser.term5(LabelExpressionParser.java:164)
at hudson.model.labels.LabelExpressionParser.term4(LabelExpressionParser.java:136)
at hudson.model.labels.LabelExpressionParser.term3(LabelExpressionParser.java:113)
at hudson.model.labels.LabelExpressionParser.term2(LabelExpressionParser.java:83)
at hudson.model.labels.LabelExpressionParser.term1(LabelExpressionParser.java:60)
at hudson.model.labels.LabelExpressionParser.expr(LabelExpressionParser.java:50)
at hudson.model.Label.parseExpression(Label.java:509)
at jenkins.model.Jenkins.getLabel(Jenkins.java:1553)
at hudson.model.AbstractProject.getAssignedLabel(AbstractProject.java:356)
at hudson.model.queue.MappingWorksheet$WorkChunk.getAssignedLabel(MappingWorksheet.java:202)
at hudson.model.queue.MappingWorksheet$WorkChunk.init(MappingWorksheet.java:185)
at hudson.model.queue.MappingWorksheet$WorkChunk.init(MappingWorksheet.java:157)
at hudson.model.queue.MappingWorksheet.init(MappingWorksheet.java:375)
at hudson.model.queue.MappingWorksheet.init(MappingWorksheet.java:303)
at hudson.model.Queue.maintain(Queue.java:1033)
at hudson.model.Queue$MaintainTask.doRun(Queue.java:1759)
at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Mar 26, 2013 1:12:52 PM hudson.triggers.SafeTimerTask run
I checked that running the following groovy script from console fails to our matrix project with the "matrix tie parent" plugin config above:
import jenkins.model.*;
for(item in Jenkins.instance.items) {
println("JOB: '" + item.name + "'");
if (item.getAssignedLabel() != null) {
println("LABEL: '" + item.getAssignedLabel() + "'");
}
}
The outcome is that all executors die (https://wiki.jenkins-ci.org/display/JENKINS/Dead+Executor) and we cannot restart those threads through the UI. Only after I changed the "Node" to "master" I was able to restart the executors. So this really kills the whole Jenkins instance.
Environment:
Jenkins 1.454
matrixtieparent 1.1
Project:
Jenkins
Priority:
Major
Reporter:
Mikko Tapaninen
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-16876) Add support for virtual streams
Mikko Tapaninen created JENKINS-16876 Add support for virtual streams Issue Type: Bug Assignee: Rob Petti Components: perforce Created: 19/Feb/13 11:09 AM Description: Perforce server 2012.1 introduced a new feature: virtual streams. These are logical constructs without depot paths, but can be used like real streams. Currently perforce plugin throws an exception when using a virtual stream: Caught exception communicating with perforce.com.tek42.perforce.PerforceException?: Stream 'foo/bar' doesn't exist. For Command: C:\apps\perforce\p4.exe -v 1 -P 0FA53FA932DFCE7659B95EFCCFA419A6 -s client -S foo/bar -i foo/bar is existing, but is virtual stream. Project: Jenkins Priority: Major Reporter: Mikko Tapaninen 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-16637) problems exposing P4CLIENT and P4PASSWD to env
Mikko Tapaninen commented on JENKINS-16637 problems exposing P4CLIENT and P4PASSWD to env You were correct. I installed a fresh vanilla jenkins 1.500 + latest perforce plugin. There were no such problems exposing P4CLIENT to the env. But after installing envinject (which we have by default on our own customized jenkins war) the problem was visible. Any idea can this be fixed on perforce plugin at all? Or should we go directly to envinject plugin? 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-16637) problems exposing P4CLIENT and P4PASSWD to env
Mikko Tapaninen commented on JENKINS-16637 problems exposing P4CLIENT and P4PASSWD to env Both master and slave are Windows server 2008 (HPC edition) machines with jdk1.7.0_10. I also tested with Windows 7 + jdk1.6.0_29 combination, same results. We used "Windows batch" build step which simply echoed P4CLIENT. It's rather simple to reproduce. 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-16120) Add an option to disable changelogs
Mikko Tapaninen created JENKINS-16120 Add an option to disable changelogs Issue Type: Bug Assignee: Mikko Tapaninen Components: perforce Created: 13/Dec/12 12:26 PM Description: There should be an option to disable changelog generation. Changelogs eat quite quite much Java memory. This would mean getting rid of the "disable sync and changelog" option and adding new option "disable changelog". Option "disable sync" would stay there. Project: Jenkins Priority: Major Reporter: Mikko Tapaninen 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
[JIRA] (JENKINS-16024) SCM Sync fails to check in any files
Mikko Tapaninen commented on JENKINS-16024 SCM Sync fails to check in any files I faced the same issue with Jenkins 1.492 and SCM sync 0.0.6.1. I tried various Git repositories, one even without any access control. And always got the error message "aborted (scm manipulator not settled !)". But after restarting Jenkins everything works fine. So simply: Install scm sync plugin (I did not restart jenkins at this point) Go to jenkins configuration page and enable scm sync configuration plugin Submit -- aborted (scm manipulator not settled !) Restart jenkins (during the restart scm sync plugin is already checking out the repo to JENKINS_HOME\scm-sync-configuration\checkoutConfiguration) Go to jenkins configuration page Submit -- Configurations synced to SCM 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
[JIRA] (JENKINS-15466) Fatal Error No Class Definition found for Kernel32
Mikko Tapaninen commented on JENKINS-15466 Fatal Error No Class Definition found for Kernel32 Jenkins 1.491 Slave_1 with jdk1.6.0_35: 11:16:25 Build step 'Execute Windows batch command' marked build as failure 11:16:26 11:16:38 Deleting project workspace... done Slave_2 with jdk1.6.0_37 11:16:14 Build step 'Execute Windows batch command' marked build as failure 11:16:15 11:16:15 Deleting project workspace... ERROR: Publisher hudson.plugins.ws_cleanup.WsCleanup aborted due to exception 11:16:15 hudson.util.IOException2: remote file operation failed: e:\build_e\slave_2\workspace\image\ebaa21bd at hudson.remoting.Channel@6db17b38:slave_2 11:16:15 at hudson.FilePath.act(FilePath.java:848) 11:16:15 at hudson.FilePath.act(FilePath.java:825) 11:16:15 at hudson.FilePath.deleteRecursive(FilePath.java:981) 11:16:15 at hudson.plugins.ws_cleanup.WsCleanup.perform(WsCleanup.java:68) 11:16:15 at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27) 11:16:15 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) 11:16:15 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:779) 11:16:15 at hudson.model.Build$BuildExecution.cleanUp(Build.java:192) 11:16:15 at hudson.model.Run.execute(Run.java:1560) 11:16:15 at hudson.matrix.MatrixRun.run(MatrixRun.java:146) 11:16:15 at hudson.model.ResourceController.execute(ResourceController.java:88) 11:16:15 at hudson.model.Executor.run(Executor.java:236) 11:16:15 Caused by: java.io.IOException: Remote call on slave_2 failed 11:16:15 at hudson.remoting.Channel.call(Channel.java:674) 11:16:15 at hudson.FilePath.act(FilePath.java:841) 11:16:15 ... 11 more 11:16:15 Caused by: java.lang.NoClassDefFoundError: Could not initialize class hudson.util.jna.Kernel32 11:16:15 at hudson.util.jna.Kernel32Utils.getWin32FileAttributes(Kernel32Utils.java:76) 11:16:15 at hudson.util.jna.Kernel32Utils.isJunctionOrSymlink(Kernel32Utils.java:80) 11:16:15 at hudson.Util.isSymlink(Util.java:322) 11:16:15 at hudson.Util.deleteRecursive(Util.java:283) 11:16:15 at hudson.FilePath$11.invoke(FilePath.java:983) 11:16:15 at hudson.FilePath$11.invoke(FilePath.java:981) 11:16:15 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) 11:16:15 at hudson.remoting.UserRequest.perform(UserRequest.java:118) 11:16:15 at hudson.remoting.UserRequest.perform(UserRequest.java:48) 11:16:15 at hudson.remoting.Request$2.run(Request.java:287) 11:16:15 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 11:16:15 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 11:16:15 at java.util.concurrent.FutureTask.run(FutureTask.java:138) 11:16:15 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 11:16:15 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 11:16:15 at hudson.remoting.Engine$1$1.run(Engine.java:60) 11:16:15 at java.lang.Thread.run(Thread.java:662) 11:16:15 Finished: FAILURE Slaves do have also other differences. Builds where matrix run siblings. 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
[JIRA] (JENKINS-15544) Jenkins leaks file handles when expanding a huge log
Mikko Tapaninen created JENKINS-15544 Jenkins leaks file handles when expanding a huge log Issue Type: Bug Assignee: Unassigned Components: core Created: 17/Oct/12 8:53 AM Description: Jenkins leaks a file handle to the log file (%JENKINS_HOME%\jobs\job_name\builds\build_id\log) when a huge console log is expanded to its full length (http://localhost:8080/job/job_nam/build_number/console -- http://localhost:8080/job/job_nam/build_number/consoleFull) and you navigate away from the page before the page is loaded. Steps to reproduce: 1. Open "Console output" 2. Click "Full log" 3. Navigate out of the page before it has loaded the full log 4. Use e.g. Process Explorer to see that Jenkins has a file handle open to the log file The problem we face due to this bug is that we cannot delete obsolete projects: Status Code: 500 Exception: Stacktrace: java.io.IOException: Unable to delete C:\jenkins\jobs\test\builds\2012-08-23_11-25-44\log at hudson.Util.deleteFile(Util.java:237) at hudson.Util.deleteRecursive(Util.java:287) at hudson.Util.deleteContentsRecursive(Util.java:198) at hudson.Util.deleteRecursive(Util.java:278) at hudson.Util.deleteContentsRecursive(Util.java:198) at hudson.Util.deleteRecursive(Util.java:278) at hudson.Util.deleteContentsRecursive(Util.java:198) at hudson.Util.deleteRecursive(Util.java:278) at hudson.model.AbstractItem.performDelete(AbstractItem.java:530) at hudson.model.Job.performDelete(Job.java:217) at hudson.model.AbstractProject.performDelete(AbstractProject.java:286) at hudson.model.AbstractItem.delete(AbstractItem.java:506) at hudson.model.AbstractProject.doDoDelete(AbstractProject.java:1655) at sun.reflect.GeneratedMethodAccessor2048.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) at org.kohsuke.stapler.Stapler.service(Stapler.java:159) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at
[JIRA] (JENKINS-14687) Password is exposed through browser option view page source
Mikko Tapaninen created JENKINS-14687 Password is exposed through browser option view page source Issue Type: Bug Assignee: Daniel Petisme Components: mask-passwords Created: 06/Aug/12 8:23 AM Description: The password you provide to Mask Password plugin is visible as plain text when you view the configure (either global or job specific) page sources. Project: Jenkins Priority: Blocker Reporter: Mikko Tapaninen 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
[JIRA] (JENKINS-9263) Downstream Build View does not recognize parameterized build trigger
[ https://issues.jenkins-ci.org/browse/JENKINS-9263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162408#comment-162408 ] Mikko Tapaninen commented on JENKINS-9263: -- It's still not working properly. I tested with Parameterized Trigger plugin 2.13 and Downstream buildview plugin at revision https://github.com/jenkinsci/downstream-buildview-plugin/commit/9ce09015e02e371420c40a759c764adf830afd76. If builds are triggered in post-build phase, then downstream view looks good. But if builds are triggered as build step, then downstream view does not get any information (build number, build status) back from the called downstream build. Downstream Build View does not recognize parameterized build trigger Key: JENKINS-9263 URL: https://issues.jenkins-ci.org/browse/JENKINS-9263 Project: Jenkins Issue Type: Bug Components: downstream-buildview, parameterized-trigger Reporter: voorth Assignee: shinodkm I have four jobs: /-DOWNSTREAM1-\ UPSTREAM-| |-JOIN \-DOWNSTREAM2-/ If I configure UPSTREAM to trigger the two downstream jobs using Build other projects, they show up in the downstream view. If I trigger them with Trigger parameterized build on other projects however, they don't. -- 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-13324) Perforce mail address resolver should fall back to other resolvers if mail address is invalid
[ https://issues.jenkins-ci.org/browse/JENKINS-13324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161271#comment-161271 ] Mikko Tapaninen commented on JENKINS-13324: --- Yep, 'n/a' is accepted. At least with 2011.1. Perforce mail address resolver should fall back to other resolvers if mail address is invalid - Key: JENKINS-13324 URL: https://issues.jenkins-ci.org/browse/JENKINS-13324 Project: Jenkins Issue Type: Bug Components: perforce Environment: Perforce 2011.1 perforce-plugin 1.3.12 Reporter: Mikko Tapaninen Perforce mail address resolver is always returning a string, no matter what the actual email address is. I don't know what is the order how Jenkins loops through the various MailAddressResolver instances but if some instance returns an actual string (i.e. non-null), it will stick with that. I don't think it's feasible to really check whether the email address provided by Perforce is valid, but PerforceMailResolver could check for some value (e.g. n/a) and return null if it matches. At least with Perforce 2011.1 you can't have an empty value for an email address. There could be an UI element for configuring which email address would be thought as invalid, but I'm fine with hardcoding n/a there and documenting it somewhere. Would this be ok? -- 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-13324) Perforce mail address resolver should fall back to other resolvers if mail address is invalid
[
https://issues.jenkins-ci.org/browse/JENKINS-13324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161207#comment-161207
]
Mikko Tapaninen commented on JENKINS-13324:
---
{quote}
PerforceMailResolver will return null if no email address is found. The problem
as you said is that perforce will always have an email set for users, and will
invent an email address if none is supplied (usually user@host or user@client).
{quote}
True. But if it finds a Perforce user then it will return some string. And
that's a problem for us because we can't have all the email addresses in
Perforce. We should look them from LDAP instead. For this reason some
predefined string could be interpreted as null.
Perforce mail address resolver should fall back to other resolvers if mail
address is invalid
-
Key: JENKINS-13324
URL: https://issues.jenkins-ci.org/browse/JENKINS-13324
Project: Jenkins
Issue Type: Bug
Components: perforce
Environment: Perforce 2011.1
perforce-plugin 1.3.12
Reporter: Mikko Tapaninen
Perforce mail address resolver is always returning a string, no matter what
the actual email address is. I don't know what is the order how Jenkins loops
through the various MailAddressResolver instances but if some instance
returns an actual string (i.e. non-null), it will stick with that. I don't
think it's feasible to really check whether the email address provided by
Perforce is valid, but PerforceMailResolver could check for some value (e.g.
n/a) and return null if it matches. At least with Perforce 2011.1 you can't
have an empty value for an email address.
There could be an UI element for configuring which email address would be
thought as invalid, but I'm fine with hardcoding n/a there and documenting
it somewhere. Would this be ok?
--
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-13324) Perforce mail address resolver should fall back to other resolvers if mail address is invalid
[ https://issues.jenkins-ci.org/browse/JENKINS-13324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161209#comment-161209 ] Mikko Tapaninen commented on JENKINS-13324: --- That's an alternative. But we also have Perforce specific accounts (buildbots or other robot accounts) and for those we could store email to Perforce. I guess it's not vital to resolve email addresses for these. It's easier for me to use predefined stting but a global option would be simpler for an end user. Perforce mail address resolver should fall back to other resolvers if mail address is invalid - Key: JENKINS-13324 URL: https://issues.jenkins-ci.org/browse/JENKINS-13324 Project: Jenkins Issue Type: Bug Components: perforce Environment: Perforce 2011.1 perforce-plugin 1.3.12 Reporter: Mikko Tapaninen Perforce mail address resolver is always returning a string, no matter what the actual email address is. I don't know what is the order how Jenkins loops through the various MailAddressResolver instances but if some instance returns an actual string (i.e. non-null), it will stick with that. I don't think it's feasible to really check whether the email address provided by Perforce is valid, but PerforceMailResolver could check for some value (e.g. n/a) and return null if it matches. At least with Perforce 2011.1 you can't have an empty value for an email address. There could be an UI element for configuring which email address would be thought as invalid, but I'm fine with hardcoding n/a there and documenting it somewhere. Would this be ok? -- 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-13109) Huge changelogs eat all the Java memory
[
https://issues.jenkins-ci.org/browse/JENKINS-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=160458#comment-160458
]
Mikko Tapaninen commented on JENKINS-13109:
---
I was thinking of letting user to decide the limit. I have an implementation
for that but I'll need to investigate further does it help and how the memory
gets reserved.
Huge changelogs eat all the Java memory
---
Key: JENKINS-13109
URL: https://issues.jenkins-ci.org/browse/JENKINS-13109
Project: Jenkins
Issue Type: Bug
Components: perforce
Environment: Windows Server 2008 HPC Edition
64-bit JVM 1.6.0_29
Running Jenkins service with arguments-Xrs -Xmx2048m
-Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar
%BASE%\jenkins.war --httpPort=8080/arguments
Reporter: Mikko Tapaninen
With really huge changelists the p4 plugin can run out of java heap space. At
least it looks like the reason for memory problems would be huge
changelog.xml files. An example case:
- a changelist with 40 files
- results in a changelog.xml size 110MB
- Jenkins runs out of memory: {{java.lang.OutOfMemoryError: Java heap space}}
Maybe there should be an option to limit the amount of files that p4 plugin
reads to from changelists?
--
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-13057) Support for integrated changelists in Changes view
[
https://issues.jenkins-ci.org/browse/JENKINS-13057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=160180#comment-160180
]
Mikko Tapaninen commented on JENKINS-13057:
---
I could add this enhancement. But just thinking should there be configuration
option for this or should it be the default behavior?
Support for integrated changelists in Changes view
Key: JENKINS-13057
URL: https://issues.jenkins-ci.org/browse/JENKINS-13057
Project: Jenkins
Issue Type: Improvement
Components: perforce
Reporter: Mikko Tapaninen
Especially with Streams, you are most probably merging lot between
development-main-release type streams. For better visibility of the build
content, the Changes view should show also integrated changes. So instead
for running {{p4 changes}} run {{p4 changes -i}}.
--
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-12902) Polling operation overrides client mappings with default parameters (for parametrized job with default values)
Mikko Tapaninen created JENKINS-12902: - Summary: Polling operation overrides client mappings with default parameters (for parametrized job with default values) Key: JENKINS-12902 URL: https://issues.jenkins-ci.org/browse/JENKINS-12902 Project: Jenkins Issue Type: Bug Components: perforce Reporter: Mikko Tapaninen If a job is parametrized with default parameter values and if the job uses these parameters in it's view map, then the polling operation always saves the workspace view maps again by using the default parameter values. So if you've forced a build with different parameter values, the next polling operation will overwrite the mappings in your workspace back to the default values. Is this a desired behavior? Shouldn't the polling just query the workspace object and see if there are 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-12902) Polling operation overrides client mappings with default parameters (for parametrized job with default values)
[ https://issues.jenkins-ci.org/browse/JENKINS-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159592#comment-159592 ] Mikko Tapaninen commented on JENKINS-12902: --- Right, didn't think that far. The stream support that I provided is missing parameter substitution support for stream name. I'll provide a patch for that. Polling operation overrides client mappings with default parameters (for parametrized job with default values) -- Key: JENKINS-12902 URL: https://issues.jenkins-ci.org/browse/JENKINS-12902 Project: Jenkins Issue Type: Bug Components: perforce Reporter: Mikko Tapaninen If a job is parametrized with default parameter values and if the job uses these parameters in it's view map, then the polling operation always saves the workspace view maps again by using the default parameter values. So if you've forced a build with different parameter values, the next polling operation will overwrite the mappings in your workspace back to the default values. Is this a desired behavior? Shouldn't the polling just query the workspace object and see if there are 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-11369) Use ToolInstallation as replacement to p4 path specified in Jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159271#comment-159271 ] Mikko Tapaninen commented on JENKINS-11369: --- I'm working on this one and I'll create a pull request once ready. I would remove p4 executable path setting from the job level and have it as a tool installation. As a migration path I was thinking to add a tool installation for each different p4 executable path that are being used (case insensitive for Windows). No matter whether the job is enabled or not and whether it's tied on master or slave. Correct tool installation would then be picked for each job. There could be some extra unneeded tool installations but I think it's fair enough. Comments? Use ToolInstallation as replacement to p4 path specified in Jobs Key: JENKINS-11369 URL: https://issues.jenkins-ci.org/browse/JENKINS-11369 Project: Jenkins Issue Type: Improvement Components: perforce Reporter: Nicolas De Loof Assignee: Rob Petti Priority: Minor Got this issue : job is configured with p4 path on build slave /usr/bin/p4. When tagging a build, an error occurred because executing on master that don't have p4 installed on same path. perforce plugin should use the Jenkins concept of ToolInstallation + NodeSpecific, so that it gets simpler to manage differences between nodes. -- 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-10326) Password is exposed in build metadata.
[ https://issues.jenkins-ci.org/browse/JENKINS-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158992#comment-158992 ] Mikko Tapaninen commented on JENKINS-10326: --- Has there been any progress on this one? Any insight to give what to actually look at if we fix it on our end and provide a patch later? Password is exposed in build metadata. -- Key: JENKINS-10326 URL: https://issues.jenkins-ci.org/browse/JENKINS-10326 Project: Jenkins Issue Type: Bug Components: perforce Environment: Perforce Plugin 1.2.8 Reporter: Rob Petti Assignee: Rob Petti Priority: Critical I've recently discovered that the perforce plugin stores the perforce password plain text in the build.xml files used for serializing build information. This seems to be a side effect of the PerforceTagAction including the Depot object for later use during tagging, which has the password inside it. This may or may not depend upon JENKINS-2947, as that would eliminate the need for the Depot object to be stored. -- 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-10326) Password is exposed in build metadata.
[ https://issues.jenkins-ci.org/browse/JENKINS-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159080#comment-159080 ] Mikko Tapaninen commented on JENKINS-10326: --- Thanks Rob. I'll let you know if we start fixing this. Password is exposed in build metadata. -- Key: JENKINS-10326 URL: https://issues.jenkins-ci.org/browse/JENKINS-10326 Project: Jenkins Issue Type: Bug Components: perforce Environment: Perforce Plugin 1.2.8 Reporter: Rob Petti Assignee: Rob Petti Priority: Critical I've recently discovered that the perforce plugin stores the perforce password plain text in the build.xml files used for serializing build information. This seems to be a side effect of the PerforceTagAction including the Depot object for later use during tagging, which has the password inside it. This may or may not depend upon JENKINS-2947, as that would eliminate the need for the Depot object to be stored. -- 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
