[JIRA] (JENKINS-13970) Build variable CC_BASELINE not populated with used baseline
[
https://issues.jenkins-ci.org/browse/JENKINS-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163645#comment-163645
]
Christian Wolfgang commented on JENKINS-13970:
--
Great! :)
Build variable CC_BASELINE not populated with used baseline
---
Key: JENKINS-13970
URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
Project: Jenkins
Issue Type: Bug
Components: clearcase-ucm
Affects Versions: current
Environment: Microsoft Windows Server 2003, Standard x64 Edition,
Service Pack 2
Reporter: Tim Pillsbury
Assignee: Christian Wolfgang
Labels: clearcase, clearcase-ucm
CCUCM says it is using the latest baseline, but the CC_BASELINE build
variable is not always set to it.
The problem seems to occur after Updating view using all modules if CCUCM
finds activities and versions involved.
{panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
[CCUCM] Retrieved 28 baselines:
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT
2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT
2012)
[CCUCM] ...
[CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT
2012)*_(n)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT
2012)
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)
[CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
[CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except
CPF\workspace\view
[CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Reusing view root
[CCUCM] Determine if view tag exists
[CCUCM] Reusing view tag
[CCUCM] UUID resulted in
CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Getting snapshotview
[CCUCM] Rebasing development stream
(CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent
stream (WRKB_RLS_2012_06_00_ECM) Done
[CCUCM] Updating view using all modules
[CCUCM] _*Found 3 activities. 20 versions involved*_(i)
{panel}
But then Injected environment variable CC_BASELINE is incorrect
{panel:title=Injected environment
variables|titleBGColor=#E7D6C1|bgColor=#CE}
|CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
{panel}
--
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-11814) Maven artifact fingerprints are computed and recorded twice
[ https://issues.jenkins-ci.org/browse/JENKINS-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163646#comment-163646 ] youri bonnaffe commented on JENKINS-11814: -- I've tried with the line mar.recordFingerprints(); commented but I see no difference in build time. From MavenFingerPrinter it seems that fingerprinting is required to keep track of dependencies so maybe it is necessary to launch others build when snapshot dependencies change or to use only build changed modules option. Note that the I use maven jobs with automatic artifact archiving disabled. Maven artifact fingerprints are computed and recorded twice --- Key: JENKINS-11814 URL: https://issues.jenkins-ci.org/browse/JENKINS-11814 Project: Jenkins Issue Type: Improvement Components: maven2 Reporter: kutzi Assignee: kutzi Priority: Minor The artifacts which are produced by a maven job have their artifacts fingerprinted twice. Once in MavenFingerprinter and once in MavenArtifactArchiver (*). This adds unnecessary overhead to maven jobs. Proposal: as fingerprints are needed in the MavenArtifact records generated in the MavenArtifactArchiver, it probably doesn't make much sense to remove the fingerprinting from there. Instead, I'd propose to fingerprint all 'used' artifacts in the MavenFingerprinter and all 'produced' artifacts in the MavenArtifactArchiver *) Note that fingerprints are even generated in MavenArtifactArchiver if automatic artifact archiving is disabled -- 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-10835) Add support for JaCoCo coverage results
[ https://issues.jenkins-ci.org/browse/JENKINS-10835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163647#comment-163647 ] Markus Schlegel commented on JENKINS-10835: --- Hi Jose I do not know maven, and you did not provide the maven-config... I have the xslt still in use (with ant), the only thing I changed in the meantime is, that I use BRANCH instead of COMPLEXITY on line 102. Add support for JaCoCo coverage results --- Key: JENKINS-10835 URL: https://issues.jenkins-ci.org/browse/JENKINS-10835 Project: Jenkins Issue Type: New Feature Components: emma Reporter: Daniel Hirscher Assignee: Kohsuke Kawaguchi Attachments: jacoco_to_emma.xslt JaCoCo is the successor of emma. Maybe it is possible to support the new coverage file format. -- 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-14056) Run Groovy scripts from files and environment variables
Balazs Jagri created JENKINS-14056: -- Summary: Run Groovy scripts from files and environment variables Key: JENKINS-14056 URL: https://issues.jenkins-ci.org/browse/JENKINS-14056 Project: Jenkins Issue Type: New Feature Components: envinject Reporter: Balazs Jagri Assignee: Gregory Boissinot Priority: Minor Currently there is no way to reference external Groovy scripts, they have to be typed in on the job configuration page. It may lead to the same script being duplicated among many jobs, making it difficult to maintain. -- 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-14057) Active Directory Plugin doesn't work anymore
Thorsten Löber created JENKINS-14057: Summary: Active Directory Plugin doesn't work anymore Key: JENKINS-14057 URL: https://issues.jenkins-ci.org/browse/JENKINS-14057 Project: Jenkins Issue Type: Bug Components: active-directory Affects Versions: current Environment: Win Server 2008, AIX Reporter: Thorsten Löber Using the Project-based Matrix Authorization Strategy the identification of the usernames doesn't work properly. Sometimes the username is recognized, sometimes the user fullname is recognized, sometimes nor the username neither the full name are recognized. It worked in old versions of jenkins and the plugin (1.16). The errormessage is: org.acegisecurity.BadCredentialsException: Failed to retrieve user information for xyz; nested exception is javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece -- 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-10771) hudson.util.IOException2: remote file operation failed
[ https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163649#comment-163649 ] Pailloncy Michaël commented on JENKINS-10771: - Does anyone have a solution or a workaround for this issue ? We always have this problem in our production environment and it's very difficult to get slaves back to their normal state after the bug occurs. hudson.util.IOException2: remote file operation failed: /path/to/job at hudson.remoting.Channel@5e165e16:slave1 at hudson.FilePath.act(FilePath.java:754) at hudson.FilePath.act(FilePath.java:740) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1193) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443) at hudson.model.Run.run(Run.java:1376) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:175) Caused by: java.io.IOException: Remote call slave1 failed at hudson.remoting.Channel.call(Channel.java:677) at hudson.FilePath.act(FilePath.java:747) ... 10 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class hudson.model.Hudson at hudson.scm.SubversionWorkspaceSelector.syncWorkspaceFormatFromMaster(SubversionWorkspaceSelector.java:85) at hudson.scm.SubversionSCM.createSvnClientManager(SubversionSCM.java:823) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:766) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1994) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) 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 hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:662) [TASKS] Skipping publisher since build result is FAILURE [WARNINGS] Skipping publisher since build result is FAILURE Email was triggered for: Failure Sending email for trigger: Failure Sending email to: em...@email.fr Notifying upstream projects of job completion Finished: FAILURE hudson.util.IOException2: remote file operation failed -- Key: JENKINS-10771 URL: https://issues.jenkins-ci.org/browse/JENKINS-10771 Project: Jenkins Issue Type: Bug Components: master-slave Affects Versions: current Environment: node: Windows Server 2008 R2, amd64 - Intel64 Family 6 Model 15 Stepping 1, GenuineIntel, jvm 1.6.0_25-b06 master: AIX Reporter: Thorsten Löber After upgrading jenkins from 1.415 to 1.426 we cannot build anymore any project on our windows node. We get the exception: Building remotely on WSJENKINSDEV01 hudson.util.IOException2: remote file operation failed: d:\Program Files\jenkins_slave\workspace\TASC Workbench at hudson.remoting.Channel@4f854f85:WSJENKINSDEV01 at hudson.FilePath.act(FilePath.java:754) at hudson.FilePath.act(FilePath.java:740) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:731) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:676) at hudson.model.AbstractProject.checkout(AbstractProject.java:1193) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443) at hudson.model.Run.run(Run.java:1376) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) Caused by: java.io.IOException: Remote call on WSJENKINSDEV01 failed at hudson.remoting.Channel.call(Channel.java:677) at hudson.FilePath.act(FilePath.java:747) ... 10 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class hudson.model.Hudson at
[JIRA] (JENKINS-14058) WORKSPACE VARIABLE is not enabled
Victor Martinez created JENKINS-14058: - Summary: WORKSPACE VARIABLE is not enabled Key: JENKINS-14058 URL: https://issues.jenkins-ci.org/browse/JENKINS-14058 Project: Jenkins Issue Type: Improvement Components: scripttrigger Affects Versions: current Environment: RHEL 5 64 BITS Reporter: Victor Martinez Assignee: Gregory Boissinot environment variables for the job (JOB_NAME, WORKSPACE, etc) should be available to the script according to the version 0.9, but I cannot see the workspace variable: Polling for the job AP_2.5_2 Looking nodes where the poll can be run. Looking for a candidate node to run the poll. Looking for a polling node with the assigned project label ubuntutest. Polling remotely on rbm-83 The expected script execution code is 0 Evaluating the script: env [jenkins] $ /bin/sh -xe /tmp/hudson4842223712068824960.sh + env HOME=/var/bob-home HUDSON_COOKIE=64bc14ec-7466-419f-8a53-23c21cd1cf11 HUDSON_HOME=/storage/tools/jenkins/.jenkins HUDSON_SERVER_COOKIE=66cfbe25f08f4d76d41fbb169f0fe20e JENKINS_HOME=/storage/tools/jenkins/.jenkins JENKINS_SERVER_COOKIE=66cfbe25f08f4d76d41fbb169f0fe20e JOBS_URL=http://rbm-13:2020/jenkins/job JOB_NAME=AP_2.5_2 LANG=en_GB.UTF-8 LOGNAME=bob MAIL=/var/mail/bob NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat NODE_LABELS=cluster coverity linux rbm-83 test ubuntu NODE_NAME=rbm-83 PATH=/usr/kerberos/bin:/usr/local/sbin PWD=/storage/jenkins SHELL=/bin/bash SHLVL=2 SSH_CLIENT=172.xx.xx.XXX X 22 SSH_CONNECTION=172.XXX.XXX.XXX Y 172.XXX.XXX.XXX 22 TMPDIR=/tmp USER=bob XDG_SESSION_COOKIE=b81ba24ca526785bb3ed28804f0f1f97-1338544823131.856266-1065288812321 XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt _=/usr/bin/env The exit code is '0'. Testing if the script execution code returns '0'. Polling complete. Took 44 ms. Changes found. Scheduling a build. -- 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-14060) Provide a way to launch a grails command as a promotion action (i.e. using the release plugin)
Davide Cavestro created JENKINS-14060: - Summary: Provide a way to launch a grails command as a promotion action (i.e. using the release plugin) Key: JENKINS-14060 URL: https://issues.jenkins-ci.org/browse/JENKINS-14060 Project: Jenkins Issue Type: Improvement Components: grails Affects Versions: current Reporter: Davide Cavestro Assignee: jeffg2one Attachments: promotion_process.png I have some grails projects for which I'd like to make a release using the grails [release plugin|http://grails.org/plugin/release] but it seems that invoking a grails command is not among available options on the drop-down used to add a promotion process action. In the meantime I have to call grails from a shell script, loosing jenkins grails configuration. !promotion_process.png! -- 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-7408) Ability to specify the order of post build actions
[ https://issues.jenkins-ci.org/browse/JENKINS-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Héritier resolved JENKINS-7408. -- Assignee: Kohsuke Kawaguchi Resolution: Fixed Was fixed in 1.463. See : https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-dev/UQLvxQclyb4 Ability to specify the order of post build actions -- Key: JENKINS-7408 URL: https://issues.jenkins-ci.org/browse/JENKINS-7408 Project: Jenkins Issue Type: Improvement Components: core Affects Versions: current Environment: All Reporter: zankya Assignee: Kohsuke Kawaguchi Currently there is no way to specify the order in which the post build actions should get executed. It will be great to have ability to specify the order on the job configuration page (Just like how we can drag and drop the build steps in ay order that we want) The project configuration should then persist this order and execute the post build actions (such as JUnit result processing. PMD, FindBugs processing etc etc ) in that order. We want the trend graphs (for PMD, FindBugs, JUnit etc.) to be displayed in the order of their importance for the project. Currently it appears that the graphs are getting displayed in the order of their plugin names. -- 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-7408) Ability to specify the order of post build actions
[ https://issues.jenkins-ci.org/browse/JENKINS-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163652#comment-163652 ] Henri Gomez commented on JENKINS-7408: -- I was using 1.447 (LTS) and updated some instances to 1.465 and see it was fixed. Sorry for the noise Ability to specify the order of post build actions -- Key: JENKINS-7408 URL: https://issues.jenkins-ci.org/browse/JENKINS-7408 Project: Jenkins Issue Type: Improvement Components: core Affects Versions: current Environment: All Reporter: zankya Assignee: Kohsuke Kawaguchi Currently there is no way to specify the order in which the post build actions should get executed. It will be great to have ability to specify the order on the job configuration page (Just like how we can drag and drop the build steps in ay order that we want) The project configuration should then persist this order and execute the post build actions (such as JUnit result processing. PMD, FindBugs processing etc etc ) in that order. We want the trend graphs (for PMD, FindBugs, JUnit etc.) to be displayed in the order of their importance for the project. Currently it appears that the graphs are getting displayed in the order of their plugin names. -- 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-10222) Jenkins cleaning out workspace unnecessarily when polling SCM (SVN)
[ https://issues.jenkins-ci.org/browse/JENKINS-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163655#comment-163655 ] Damien Finck commented on JENKINS-10222: Hello, I have exactly the same problem. In Jenkins, I have about 30 projects. For two of my projects, I have this problem for some time. The first one has this configuration: - An SVN repository on https://company.fr:433/svn/project in the folder trunk of my workspace - Use 'svn update' as much as possible And at each build, Jenkins said Checking out a fresh workspace Because The workspace is not https://company.fr:443/svn/project For the second project that is the problem, it is configured this way: - 3 SVN repositories * https://company.fr/svn/project1 in the folder project1 * https://company.fr:433/svn/project2 in the Project2 * https://company.fr:433/svn/project3 in the project3 - Use 'svn update' as much as possible And at each build, Jenkins said Checking out a fresh workspace Because The workspace is not https://company.fr:443/svn/project3 I have a problem only on the third repositorie. I tried to remove the first project and recreate it: Same problem. I read in a forum user who said: I had a similar problem but It Was Because The name of the SVN server in my path Was in CAPS. I changed it to lower case and it worked. ... So, I changed my path from https://company.fr:433/svn/folder to https://company.fr/svn/folder and it works in my two projects . It like if repositorie has once time a bug, Jenkins do each other time a svn checkout on this repositorie instead of an svn update. Sincerely, Damien Jenkins cleaning out workspace unnecessarily when polling SCM (SVN) --- Key: JENKINS-10222 URL: https://issues.jenkins-ci.org/browse/JENKINS-10222 Project: Jenkins Issue Type: Bug Components: subversion Environment: Windows Reporter: Giles Dermody I am using a SVN repository which is being checked out at the beginning of every build in a Jenkins job. It is set to poll SCM for updates. However, regardless of whether there were changes or not it is cleaning out the workspace and downloading the whole repository in it's entirety every time which is unnecessary. Builds are taking much longer than they should as the SVN poll should only be checking out newly-updated files. Sample log: Checking out a fresh workspace because the workspace is not file://PICKLE/Repositories/project Cleaning workspace. -- 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-6963) CGit browser support.
[ https://issues.jenkins-ci.org/browse/JENKINS-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163656#comment-163656 ] SCM/JIRA link daemon commented on JENKINS-6963: --- Code changed in jenkins User: Seiji Sogabe Path: src/main/java/hudson/plugins/git/browser/CGit.java src/main/resources/hudson/plugins/git/browser/CGit/config.jelly http://jenkins-ci.org/commit/git-plugin/6e4060ede07917902a48190d9226d646717ae1c8 Log: [FIXED JENKINS-6963] CGit browser support. CGit browser support. - Key: JENKINS-6963 URL: https://issues.jenkins-ci.org/browse/JENKINS-6963 Project: Jenkins Issue Type: Improvement Components: git Affects Versions: current Environment: All Reporter: mkalika Assignee: sogabe Priority: Minor Attachments: 0001-Add-CGit-git-browser-support.patch Please add cgit support to the git plugin. I added the plugin support for it (heavily based on the existing GitWeb code). I'll uploaded the patch next. Thank you for your consideration. -- 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-14061) publish html report should give the option of changing the build result when the report is missing
Martin d'Anjou created JENKINS-14061:
Summary: publish html report should give the option of changing
the build result when the report is missing
Key: JENKINS-14061
URL: https://issues.jenkins-ci.org/browse/JENKINS-14061
Project: Jenkins
Issue Type: Bug
Components: htmlpublisher
Affects Versions: current
Reporter: Martin d'Anjou
Assignee: mcrooney
Publish HTML report should give the option of NOT changing the build result
when the report is missing.
{noformat}
ERROR: Specified HTML directory '...' does not exist.
Build step 'Publish HTML reports' changed build result to FAILURE
{noformat}
The workaround is to forcibly create a dummy report. This adds complexity.
--
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-11814) Maven artifact fingerprints are computed and recorded twice
[ https://issues.jenkins-ci.org/browse/JENKINS-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163657#comment-163657 ] kutzi commented on JENKINS-11814: - There are other reasons why a Maven job might be slower than a freestyle job. You might want to try the Timestamper plugin to get a clue where the time is spent. Maven artifact fingerprints are computed and recorded twice --- Key: JENKINS-11814 URL: https://issues.jenkins-ci.org/browse/JENKINS-11814 Project: Jenkins Issue Type: Improvement Components: maven2 Reporter: kutzi Assignee: kutzi Priority: Minor The artifacts which are produced by a maven job have their artifacts fingerprinted twice. Once in MavenFingerprinter and once in MavenArtifactArchiver (*). This adds unnecessary overhead to maven jobs. Proposal: as fingerprints are needed in the MavenArtifact records generated in the MavenArtifactArchiver, it probably doesn't make much sense to remove the fingerprinting from there. Instead, I'd propose to fingerprint all 'used' artifacts in the MavenFingerprinter and all 'produced' artifacts in the MavenArtifactArchiver *) Note that fingerprints are even generated in MavenArtifactArchiver if automatic artifact archiving is disabled -- 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-2556) Use svn switch where applicable
[
https://issues.jenkins-ci.org/browse/JENKINS-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163658#comment-163658
]
Steven Lee commented on JENKINS-2556:
-
Just ran into this too and it takes way too long to delete everything and then
check it out again.
We have a large amount of static files (mp3, mov, etc.) in subversion which are
deployed to apache.
Use svn switch where applicable
---
Key: JENKINS-2556
URL: https://issues.jenkins-ci.org/browse/JENKINS-2556
Project: Jenkins
Issue Type: Patch
Components: subversion
Affects Versions: current
Environment: Platform: All, OS: All
Reporter: rombert
Attachments: subversion.diff, subversion2.diff, subversion3.diff
When updating the 'stable' builds of our projects, I update the repository URL
from svn://aaa/project/branches/182 to svn://aaa/project/branches/183 ( for
instance ).
This results in a clean checkout ( Checking out a fresh workspace because the
workspace is not svn://aaa/project/branches/183 ), which takes somewhere
around
30 (!) minutes, when a svn switch would've taken a few seconds.
What I suggest is a (perhaps per job configurable) setting which would use svn
switch if all but the last {x} path elements are the same.
For instance, a setting of 1 would allow switch to be used for
svn://aaa/project/branches/183 - svn://aaa/project/branches/184
but not for
svn://aaa/project/branches/183 - svn://aaa/project/trunk
A setting of 2 would allow switch to be used for both.
A setting of 0 would disallow the usage of svn switch.
--
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-13550) Git Tag to push should trim whitespace
[
https://issues.jenkins-ci.org/browse/JENKINS-13550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163659#comment-163659
]
SCM/JIRA link daemon commented on JENKINS-13550:
Code changed in jenkins
User: Seiji Sogabe
Path:
src/main/java/hudson/plugins/git/GitPublisher.java
http://jenkins-ci.org/commit/git-plugin/39f7ffc016f187ded38767f7e0fb941322eb567e
Log:
[FIXED JENKINS-13550] Git Tag to push should trim whitespace
Git Tag to push should trim whitespace
Key: JENKINS-13550
URL: https://issues.jenkins-ci.org/browse/JENKINS-13550
Project: Jenkins
Issue Type: Bug
Components: git
Reporter: Willem Stuursma
Assignee: Nicolas De Loof
Priority: Minor
Using git plugin 1.1.17.
If you accidentally leave in whitespace in the Tag to push field, git will
create a tag with the whitespace replaced by an _. E.g. if you configure a
tag like build-${BUILD_NUMBER} (note the whitespace at the end of the
field), the created tag will then be build-121_ or the like.
The tag will be created locally but pushing the tag will fail because it will
try to push the tag without the _, and this tag will not exist.
{code}
Pushing tag build-121 to repo origin
ERROR: Failed to push tag build-121 to origin
hudson.plugins.git.GitException: Command git push
git-comp...@server.company.com:/srv/company.git build-121 returned status
code 128:
stdout:
stderr: fatal: remote part of refspec is not a valid name in build-121
at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:779)
at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:741)
at hudson.plugins.git.GitAPI.push(GitAPI.java:797)
at hudson.plugins.git.GitPublisher$3.invoke(GitPublisher.java:277)
at hudson.plugins.git.GitPublisher$3.invoke(GitPublisher.java:247)
at hudson.FilePath.act(FilePath.java:832)
at hudson.FilePath.act(FilePath.java:814)
at hudson.plugins.git.GitPublisher.perform(GitPublisher.java:247)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627)
at hudson.model.Run.run(Run.java:1446)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Build step 'Git Publisher' changed build result to FAILURE
{code}
This error kind of pointed me in the wrong direction and it took some time to
figure this out, it would be really great if the field could be trimmed,
hopefully it will save some people some time if they have this same problem.
Alternatively, you could give an error when leaving whitespace in the Tag to
push field.
--
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-13550) Git Tag to push should trim whitespace
[
https://issues.jenkins-ci.org/browse/JENKINS-13550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SCM/JIRA link daemon resolved JENKINS-13550.
Resolution: Fixed
Git Tag to push should trim whitespace
Key: JENKINS-13550
URL: https://issues.jenkins-ci.org/browse/JENKINS-13550
Project: Jenkins
Issue Type: Bug
Components: git
Reporter: Willem Stuursma
Assignee: Nicolas De Loof
Priority: Minor
Using git plugin 1.1.17.
If you accidentally leave in whitespace in the Tag to push field, git will
create a tag with the whitespace replaced by an _. E.g. if you configure a
tag like build-${BUILD_NUMBER} (note the whitespace at the end of the
field), the created tag will then be build-121_ or the like.
The tag will be created locally but pushing the tag will fail because it will
try to push the tag without the _, and this tag will not exist.
{code}
Pushing tag build-121 to repo origin
ERROR: Failed to push tag build-121 to origin
hudson.plugins.git.GitException: Command git push
git-comp...@server.company.com:/srv/company.git build-121 returned status
code 128:
stdout:
stderr: fatal: remote part of refspec is not a valid name in build-121
at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:779)
at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:741)
at hudson.plugins.git.GitAPI.push(GitAPI.java:797)
at hudson.plugins.git.GitPublisher$3.invoke(GitPublisher.java:277)
at hudson.plugins.git.GitPublisher$3.invoke(GitPublisher.java:247)
at hudson.FilePath.act(FilePath.java:832)
at hudson.FilePath.act(FilePath.java:814)
at hudson.plugins.git.GitPublisher.perform(GitPublisher.java:247)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627)
at hudson.model.Run.run(Run.java:1446)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Build step 'Git Publisher' changed build result to FAILURE
{code}
This error kind of pointed me in the wrong direction and it took some time to
figure this out, it would be really great if the field could be trimmed,
hopefully it will save some people some time if they have this same problem.
Alternatively, you could give an error when leaving whitespace in the Tag to
push field.
--
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-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163662#comment-163662 ] Guillaume Bilodeau commented on JENKINS-13227: -- Just came back from vacation, switched to the 2.4 release and everything works like a charm. Thank you so much Michael! CVS plugin 2.1 does not detect changes -- Key: JENKINS-13227 URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 Project: Jenkins Issue Type: Bug Components: cvs Reporter: Guillaume Bilodeau Assignee: Michael Clarke Priority: Critical Labels: cvs Attachments: rlog.txt As presented in the user group: https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS repository for a few weeks now, without any problems. The CVS plugin (v1.6) was using the local cvsnt install. We've since upgraded the CVS plugin to version 2.1 (by manually pinning the plugin) and since then, CVS changes are not detected. The CVS polling log is triggered properly, tons of cvs rlog instructions are sent, but at the end No changes is displayed. Using CVS plugin 1.6 the cvs polling command looked like this (executed at 5:26:21 PM EDT): cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D Thursday, March 22, 2012 9:26:21 PM UTC Using CVS plugin 2.1, the last cvs checkout command looked like this (executed at 11:56:16 AM EDT): cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 11:56:16 EDT -d portailInt portailInt We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- 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-14062) can we zip ALL the backups and not just the 'old' ones?
Maddy Goss created JENKINS-14062: Summary: can we zip ALL the backups and not just the 'old' ones? Key: JENKINS-14062 URL: https://issues.jenkins-ci.org/browse/JENKINS-14062 Project: Jenkins Issue Type: Improvement Components: thinBackup Reporter: Maddy Goss Assignee: Thomas Fürer Priority: Minor We have scripts that copy our backups around and write them to tape and they are MUCH easier to manage (and faster too) if they are all zip files and not just the old backups. -- 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-12042) SVN_REVISION varable is empty if URL contains @Revision
[
https://issues.jenkins-ci.org/browse/JENKINS-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163663#comment-163663
]
jonathan_w_brown commented on JENKINS-12042:
Output excerpt taken from a build shell script step for a non-decorated svn url:
U.
At revision 72666
[workspace] $ /bin/sh -xe /tmp/hudson1315590806389520477.sh
+ env
+ grep SVN
SVN_URL=http://urlpath
SVN_REVISION=72603
Then I add a string build parameter [REVISION] and modify the svn url to be in
the form http://urlpath/@${REVISION}. For this test I set the value of my
REVISION parameter to '71640'.
U.
At revision 71640
no revision recorded for http://urlpath/ in the previous build
[workspace] $ /bin/sh -xe /tmp/hudson6960655887912316261.sh
+ env
+ grep SVN
The result is the same if I hardcode the revision number as part of the url
rather than parameterize it.
Environment: Jenkins 1.466, svn plugin 1.40.
Let me know if there is any additional information I can provide.
SVN_REVISION varable is empty if URL contains @Revision
-
Key: JENKINS-12042
URL: https://issues.jenkins-ci.org/browse/JENKINS-12042
Project: Jenkins
Issue Type: Bug
Components: core, subversion
Environment: Jenkins 1.442
Subversion plugin 1.37
Reporter: Oleksandr Popov
Priority: Blocker
SVN_REVISION variable is not set if I specify revision (or keyword like HEAD)
in URL (like @123).
--
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-14064) Copying the source file on the Hudson master failed / Clang / autotools VPATH
Yury Zaytsev created JENKINS-14064:
--
Summary: Copying the source file on the Hudson master failed /
Clang / autotools VPATH
Key: JENKINS-14064
URL: https://issues.jenkins-ci.org/browse/JENKINS-14064
Project: Jenkins
Issue Type: Bug
Components: warnings
Environment: Master: RHEL 6.2, Jenkins LTS, Warnings 4.5; Slave:
Fedora Core 16
Reporter: Yury Zaytsev
Assignee: Ulli Hafner
Priority: Minor
Hi,
I set up a VPATH build of an autotools-based software in a custom workspace
(set per node) in build directory:
/mnt/ram/workspace/[job-id]/build
Therefore generally files are referenced in the log as ../../folder/file.cpp,
because the build directory only contains Makefiles and other temporarily
generated data. E.g. when files from nestkernel are compiled through the
Makefiles in
/mnt/ram/workspace/[job-id]/build/nestkernel
the source files are referenced as ../../nestkernel/file.cpp so that it
resolves as
/mnt/ram/workspace/[job-id]/nestkernel/file.cpp
I'm afraid this can't be possibly changed. Now because of that LLVM parser
extracts warnings as belonging e.g. to ../../nestkernel, so apparently the
file references are later resolved as
/mnt/nestkernel/file.cpp
relative to
/mnt/ram/workspace/[job-id]/
and not to
/mnt/ram/workspace/[job-id]/build/nestkernel
which of course doesn't exist so I'm getting the following kind of errors when
I try to see the file:
{code}
Content of file connection_manager.cpp
01 Copying the source file '../../nestkernel/connection_manager.cpp' from the
workspace to the build folder
'/var/lib/jenkins/jobs/nest-clang-test/builds/2012-06-08_17-46-33/workspace-files/7976711b.tmp'
on the Hudson master failed.
02 Seems that the path is relative, however an absolute path is required when
copying the sources.%nIs the file 'connection_manager.cpp' contained more than
once in your workspace?
03 Is the file '../../nestkernel/connection_manager.cpp' a valid filename?
04 If you are building on a slave: please check if the file is accessible under
'$HUDSON_HOME/[job-name]/../../nestkernel/connection_manager.cpp'
05 If you are building on the master: please check if the file is accessible
under
'$HUDSON_HOME/[job-name]/workspace/../../nestkernel/connection_manager.cpp'
06 hudson.util.IOException2: remote file operation failed:
../../nestkernel/connection_manager.cpp at
hudson.remoting.Channel@68b7cdc6:fc-16-i386-2
07 at hudson.FilePath.act(FilePath.java:780)
08 at hudson.FilePath.act(FilePath.java:766)
09 at hudson.FilePath.copyTo(FilePath.java:1460)
10 at
hudson.plugins.analysis.core.HealthAwarePublisher.copyFilesWithAnnotationsToBuildFolder(HealthAwarePublisher.java:398)
11 at
hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:355)
12 at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27)
13 at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:697)
14 at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:672)
15 at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:650)
16 at hudson.model.Build$RunnerImpl.post2(Build.java:162)
17 at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:619)
18 at hudson.model.Run.run(Run.java:1429)
19 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
20 at hudson.model.ResourceController.execute(ResourceController.java:88)
21 at hudson.model.Executor.run(Executor.java:238)
22 Caused by: java.io.FileNotFoundException:
../../nestkernel/connection_manager.cpp (No such file or directory)
23 at java.io.FileInputStream.open(Native Method)
24 at java.io.FileInputStream.init(FileInputStream.java:137)
25 at hudson.FilePath$31.invoke(FilePath.java:1465)
26 at hudson.FilePath$31.invoke(FilePath.java:1460)
27 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2045)
28 at hudson.remoting.UserRequest.perform(UserRequest.java:118)
29 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
30 at hudson.remoting.Request$2.run(Request.java:287)
31 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
32 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
33 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
34 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
35 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
36 at java.lang.Thread.run(Thread.java:679)
{code}
A typical log snippet looks like this:
{code}
mv -f .deps/libdevelopermodule_la-maturing_connector_fr.Tpo
.deps/libdevelopermodule_la-maturing_connector_fr.Plo
/bin/sh ../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H -I.
-I../../developer -I../libnestutil -I../../libnestutil
[JIRA] (JENKINS-14064) Copying the source file on the Hudson master failed / Clang / autotools VPATH
[
https://issues.jenkins-ci.org/browse/JENKINS-14064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Zaytsev updated JENKINS-14064:
---
Attachment: consoleText.log.zip
Exemplar console build log
Copying the source file on the Hudson master failed / Clang / autotools VPATH
-
Key: JENKINS-14064
URL: https://issues.jenkins-ci.org/browse/JENKINS-14064
Project: Jenkins
Issue Type: Bug
Components: warnings
Environment: Master: RHEL 6.2, Jenkins LTS, Warnings 4.5; Slave:
Fedora Core 16
Reporter: Yury Zaytsev
Assignee: Ulli Hafner
Priority: Minor
Attachments: consoleText.log.zip
Hi,
I set up a VPATH build of an autotools-based software in a custom workspace
(set per node) in build directory:
/mnt/ram/workspace/[job-id]/build
Therefore generally files are referenced in the log as ../../folder/file.cpp,
because the build directory only contains Makefiles and other temporarily
generated data. E.g. when files from nestkernel are compiled through the
Makefiles in
/mnt/ram/workspace/[job-id]/build/nestkernel
the source files are referenced as ../../nestkernel/file.cpp so that it
resolves as
/mnt/ram/workspace/[job-id]/nestkernel/file.cpp
I'm afraid this can't be possibly changed. Now because of that LLVM parser
extracts warnings as belonging e.g. to ../../nestkernel, so apparently the
file references are later resolved as
/mnt/nestkernel/file.cpp
relative to
/mnt/ram/workspace/[job-id]/
and not to
/mnt/ram/workspace/[job-id]/build/nestkernel
which of course doesn't exist so I'm getting the following kind of errors
when I try to see the file:
{code}
Content of file connection_manager.cpp
01 Copying the source file '../../nestkernel/connection_manager.cpp' from the
workspace to the build folder
'/var/lib/jenkins/jobs/nest-clang-test/builds/2012-06-08_17-46-33/workspace-files/7976711b.tmp'
on the Hudson master failed.
02 Seems that the path is relative, however an absolute path is required when
copying the sources.%nIs the file 'connection_manager.cpp' contained more
than once in your workspace?
03 Is the file '../../nestkernel/connection_manager.cpp' a valid filename?
04 If you are building on a slave: please check if the file is accessible
under '$HUDSON_HOME/[job-name]/../../nestkernel/connection_manager.cpp'
05 If you are building on the master: please check if the file is accessible
under
'$HUDSON_HOME/[job-name]/workspace/../../nestkernel/connection_manager.cpp'
06 hudson.util.IOException2: remote file operation failed:
../../nestkernel/connection_manager.cpp at
hudson.remoting.Channel@68b7cdc6:fc-16-i386-2
07 at hudson.FilePath.act(FilePath.java:780)
08 at hudson.FilePath.act(FilePath.java:766)
09 at hudson.FilePath.copyTo(FilePath.java:1460)
10 at
hudson.plugins.analysis.core.HealthAwarePublisher.copyFilesWithAnnotationsToBuildFolder(HealthAwarePublisher.java:398)
11 at
hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:355)
12 at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27)
13 at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:697)
14 at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:672)
15 at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:650)
16 at hudson.model.Build$RunnerImpl.post2(Build.java:162)
17 at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:619)
18 at hudson.model.Run.run(Run.java:1429)
19 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
20 at hudson.model.ResourceController.execute(ResourceController.java:88)
21 at hudson.model.Executor.run(Executor.java:238)
22 Caused by: java.io.FileNotFoundException:
../../nestkernel/connection_manager.cpp (No such file or directory)
23 at java.io.FileInputStream.open(Native Method)
24 at java.io.FileInputStream.init(FileInputStream.java:137)
25 at hudson.FilePath$31.invoke(FilePath.java:1465)
26 at hudson.FilePath$31.invoke(FilePath.java:1460)
27 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2045)
28 at hudson.remoting.UserRequest.perform(UserRequest.java:118)
29 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
30 at hudson.remoting.Request$2.run(Request.java:287)
31 at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
32 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
33 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
34 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
35 at
[JIRA] (JENKINS-14065) Add a field/option to allow custom email headers
[ https://issues.jenkins-ci.org/browse/JENKINS-14065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slide-O-Mix closed JENKINS-14065. - Resolution: Duplicate JENKINS-13912 Add a field/option to allow custom email headers Key: JENKINS-14065 URL: https://issues.jenkins-ci.org/browse/JENKINS-14065 Project: Jenkins Issue Type: New Feature Components: email-ext Affects Versions: current Environment: Linux Java 1.6.x Reporter: Youssuf ElKalay Assignee: Slide-O-Mix Priority: Minor Please add a feature to the email-ext plugin whereby a user can add non standard email headers to the email that is sent out. I have a use case where users would like email notifications to be flagged with high importance on failed/unstable builds. For example - I'd like to be able to add X-Priority: 1 to Jenkins email notification headers. -- 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-13086) Clone to directory named for repository
[ https://issues.jenkins-ci.org/browse/JENKINS-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163672#comment-163672 ] Doug Borg commented on JENKINS-13086: - [~rmorgenstein], that is not exactly ideal as the multiple SCMs plugin does not support post-commit / post-update triggers. Furthermore, it just makes sense that the Local subdirectory for repo should be a per-repo option, not part of the global git configuration. Even the name of the option is confusing the way it is now and other SCM plugins have the ability to do this without having to resort to the Multiple-SCMs Plugin. Clone to directory named for repository --- Key: JENKINS-13086 URL: https://issues.jenkins-ci.org/browse/JENKINS-13086 Project: Jenkins Issue Type: New Feature Components: git Affects Versions: current Reporter: Tom Haggie Assignee: Nicolas De Loof Priority: Minor Labels: git, jenkins In a Jenkins Job you can select to use git to clone / pull from multiple repositories but it always pulls straight to the working directory so if you have multiple they end up overwriting each other. What I'd like is a checkbox to say clone to a directory (under the workspace) named for the git repository. So (when checked) if I had the command as: https://github.com/jenkinsci/jenkins.git it would checkout to .../workspace/job_name/jenkins -- 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-13912) Add the ability to add custom header fields to emails
[ https://issues.jenkins-ci.org/browse/JENKINS-13912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163674#comment-163674 ] Slide-O-Mix commented on JENKINS-13912: --- Yes Add the ability to add custom header fields to emails - Key: JENKINS-13912 URL: https://issues.jenkins-ci.org/browse/JENKINS-13912 Project: Jenkins Issue Type: Improvement Components: email-ext Reporter: Dirk Kuypers Assignee: Slide-O-Mix IMHO it would be nice to be able to add custom header fields to emails. In our environment we are continuously building and testing different branches in parallel. Failing tests send out emails where filtering on custom header fields would add quite some comfort to the work of our developers.;-) Example: X-Branch: main X-BRanch: Version_2.60 and so on... -- 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-13734) CVS plugin crashes Maven release builds with the error Cannot prepare the release because you have local modifications
[
https://issues.jenkins-ci.org/browse/JENKINS-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163677#comment-163677
]
SCM/JIRA link daemon commented on JENKINS-13734:
Code changed in jenkins
User: mc1arke
Path:
src/main/java/hudson/scm/CVSSCM.java
http://jenkins-ci.org/commit/cvs-plugin/b0653878a7316dc676e25894b10235590e7fe327
Log:
[FIXED JENKINS-13734] Remove sticky date tag properly
Prevent CVS thinking we're on an old date and therefore aren't up-to-date
Compare: https://github.com/jenkinsci/cvs-plugin/compare/de148b3...b065387
CVS plugin crashes Maven release builds with the error Cannot prepare the
release because you have local modifications
Key: JENKINS-13734
URL: https://issues.jenkins-ci.org/browse/JENKINS-13734
Project: Jenkins
Issue Type: Bug
Components: cvs
Affects Versions: current
Environment: CentOS, Jenkins 1.463, CVS plugin 2.3, Jenkins Maven
Release Plugin 0.9.1
Reporter: Sergey Skladchikov
Labels: cvs, maven, plugin, release
Attachments: config.xml, log
1. Install Jenkins Maven Release Plugin 0.9.1
2. Make a new project and add the pom.xml file containing the following
settings:
{code:xml}
...
scm
developerConnectionscm:cvs:pserver:CVS-ACCOUNT:PASSWORD@CVS-SERVER:/REPOSITORY:MODULE/developerConnection
/scm
...
build
plugins
plugin
groupIdmaven/groupId
artifactIdmaven-scm-plugin/artifactId
version1.6.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.2.2/version
configuration
useReleaseProfilefalse/useReleaseProfile
/configuration
/plugin
/plugins
/build
...
distributionManagement
repository
idmy-releases/id
!-- specify any valid HTTP URL --
urlANY_RELEASES_REPOSITORY_URL/url
/repository
/distributionManagement
...
{code}
3. Import the project into your CVS server
4. Create a new maven job and specify all the necessary CVS connection
settings
5. Open the job page and click the link Perform Maven Release
Expected: the job compiles the project and publishes a newly created artefact
Actual: the job is crushed with the error Cannot prepare the release because
you have local modifications (see attachments for details)
Important note: everything works properly if I use CVS plugin version 1.6
--
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-13734) CVS plugin crashes Maven release builds with the error Cannot prepare the release because you have local modifications
[
https://issues.jenkins-ci.org/browse/JENKINS-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SCM/JIRA link daemon resolved JENKINS-13734.
Resolution: Fixed
CVS plugin crashes Maven release builds with the error Cannot prepare the
release because you have local modifications
Key: JENKINS-13734
URL: https://issues.jenkins-ci.org/browse/JENKINS-13734
Project: Jenkins
Issue Type: Bug
Components: cvs
Affects Versions: current
Environment: CentOS, Jenkins 1.463, CVS plugin 2.3, Jenkins Maven
Release Plugin 0.9.1
Reporter: Sergey Skladchikov
Labels: cvs, maven, plugin, release
Attachments: config.xml, log
1. Install Jenkins Maven Release Plugin 0.9.1
2. Make a new project and add the pom.xml file containing the following
settings:
{code:xml}
...
scm
developerConnectionscm:cvs:pserver:CVS-ACCOUNT:PASSWORD@CVS-SERVER:/REPOSITORY:MODULE/developerConnection
/scm
...
build
plugins
plugin
groupIdmaven/groupId
artifactIdmaven-scm-plugin/artifactId
version1.6.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.2.2/version
configuration
useReleaseProfilefalse/useReleaseProfile
/configuration
/plugin
/plugins
/build
...
distributionManagement
repository
idmy-releases/id
!-- specify any valid HTTP URL --
urlANY_RELEASES_REPOSITORY_URL/url
/repository
/distributionManagement
...
{code}
3. Import the project into your CVS server
4. Create a new maven job and specify all the necessary CVS connection
settings
5. Open the job page and click the link Perform Maven Release
Expected: the job compiles the project and publishes a newly created artefact
Actual: the job is crushed with the error Cannot prepare the release because
you have local modifications (see attachments for details)
Important note: everything works properly if I use CVS plugin version 1.6
--
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-13734) CVS plugin crashes Maven release builds with the error Cannot prepare the release because you have local modifications
[
https://issues.jenkins-ci.org/browse/JENKINS-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Clarke reassigned JENKINS-13734:
Assignee: Michael Clarke
CVS plugin crashes Maven release builds with the error Cannot prepare the
release because you have local modifications
Key: JENKINS-13734
URL: https://issues.jenkins-ci.org/browse/JENKINS-13734
Project: Jenkins
Issue Type: Bug
Components: cvs
Affects Versions: current
Environment: CentOS, Jenkins 1.463, CVS plugin 2.3, Jenkins Maven
Release Plugin 0.9.1
Reporter: Sergey Skladchikov
Assignee: Michael Clarke
Labels: cvs, maven, plugin, release
Attachments: config.xml, log
1. Install Jenkins Maven Release Plugin 0.9.1
2. Make a new project and add the pom.xml file containing the following
settings:
{code:xml}
...
scm
developerConnectionscm:cvs:pserver:CVS-ACCOUNT:PASSWORD@CVS-SERVER:/REPOSITORY:MODULE/developerConnection
/scm
...
build
plugins
plugin
groupIdmaven/groupId
artifactIdmaven-scm-plugin/artifactId
version1.6.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.2.2/version
configuration
useReleaseProfilefalse/useReleaseProfile
/configuration
/plugin
/plugins
/build
...
distributionManagement
repository
idmy-releases/id
!-- specify any valid HTTP URL --
urlANY_RELEASES_REPOSITORY_URL/url
/repository
/distributionManagement
...
{code}
3. Import the project into your CVS server
4. Create a new maven job and specify all the necessary CVS connection
settings
5. Open the job page and click the link Perform Maven Release
Expected: the job compiles the project and publishes a newly created artefact
Actual: the job is crushed with the error Cannot prepare the release because
you have local modifications (see attachments for details)
Important note: everything works properly if I use CVS plugin version 1.6
--
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-7641) Slaves hang when archiving artifacts
[
https://issues.jenkins-ci.org/browse/JENKINS-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163679#comment-163679
]
crusius commented on JENKINS-7641:
--
Happening every single time on an OSX 10.4 SSH slave, Jenkins {{1.467}}. It was
not copying the artifacts at all with {{1.461}}, and now it simply hangs.
Cancelling the slave job does not work (the job does not die), I have to cancel
the main job instead. I reverted to using {{1.461}} in the time being -- it
also does not work, but at least it does not hang.
Slaves hang when archiving artifacts
Key: JENKINS-7641
URL: https://issues.jenkins-ci.org/browse/JENKINS-7641
Project: Jenkins
Issue Type: Bug
Components: ssh-slaves
Affects Versions: current
Environment: Ubuntu Server 10.04 64-bit
Reporter: ieure
Assignee: Kohsuke Kawaguchi
Fix For: current
I don't know why this happens, but my slaves have begun to hang when they get
to the Archiving Artifacts portion of my job:
{noformat}
Archiving artifacts
ERROR: Failed to archive artifacts: dist/**
hudson.util.IOException2: Failed to extract
/mnt/hudsonslave/workspace/simplegeo-puppet-manifests/dist/**
at hudson.FilePath.readFromTar(FilePath.java:1577)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1491)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:117)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:580)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:558)
at hudson.model.Build$RunnerImpl.post2(Build.java:157)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528)
at hudson.model.Run.run(Run.java:1303)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:137)
Caused by: java.io.IOException
at
hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:173)
at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61)
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:221)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:92)
at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257)
at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223)
at
hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:345)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:999)
at hudson.util.IOUtils.copy(IOUtils.java:33)
at hudson.FilePath.readFromTar(FilePath.java:1565)
... 12 more
{noformat}
I aborted this job, so I don't know if the error is related or not. The job
runs fine, but it hangs during archiving. If I restart the connection to the
node (in /computer/; not restarting Hudson or the node itself), jobs will
build successfully again for a while.
--
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-13912) Add the ability to add custom header fields to emails
[ https://issues.jenkins-ci.org/browse/JENKINS-13912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163680#comment-163680 ] Youssuf ElKalay commented on JENKINS-13912: --- Any ETA oh the release date? Looks like you're releasing once a month based on the release history so far. Add the ability to add custom header fields to emails - Key: JENKINS-13912 URL: https://issues.jenkins-ci.org/browse/JENKINS-13912 Project: Jenkins Issue Type: Improvement Components: email-ext Reporter: Dirk Kuypers Assignee: Slide-O-Mix IMHO it would be nice to be able to add custom header fields to emails. In our environment we are continuously building and testing different branches in parallel. Failing tests send out emails where filtering on custom header fields would add quite some comfort to the work of our developers.;-) Example: X-Branch: main X-BRanch: Version_2.60 and so on... -- 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-13796) Expose selected browser/os/version information as environment variables
[ https://issues.jenkins-ci.org/browse/JENKINS-13796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163686#comment-163686 ] Ross Rowe commented on JENKINS-13796: - The plugin will now expose SELENIUM_BROWSER, SELENIUM_PLATFORM and SELENIUM_VERSION environment variables if a single browser is selected. Expose selected browser/os/version information as environment variables --- Key: JENKINS-13796 URL: https://issues.jenkins-ci.org/browse/JENKINS-13796 Project: Jenkins Issue Type: Improvement Components: sauce-ondemand Reporter: Ross Rowe Assignee: Ross Rowe Currently, the selected browser information is exposed via the SELENIUM_DRIVER and SAUCE_ONDEMAND_BROWSERS variables. If a single browser combination is selected, this information should be exposed via specific environment variables. -- 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
