[JIRA] (JENKINS-61122) Release parameter-separator-plugin 1.1
Title: Message Title Paul Milliken created an issue Jenkins / JENKINS-61122 Release parameter-separator-plugin 1.1 Issue Type: Improvement Assignee: Unassigned Components: parameter-separator-plugin Created: 2020-02-18 11:17 Priority: Minor Reporter: Paul Milliken We use the parameter-separator-plugin to provide more useful documentation within the parameter page of our pipeline scripts. Due to JENKINS-39138, this causes the job config to be updated on every build (and causes the log the be filled with messages about ParametersAction.keepUndefinedParameters). This issue appears to have been fixed about two years ago, and a newer 1.1 release was tagged in the plugin's github, however, this release does not appear to be available in the Jenkins update centre. Could this release be promoted/published to make this fix available without requiring building a local version of the plugin? Add Comment
[JIRA] (JENKINS-51461) Inconsistent versions in update error message
Title: Message Title Paul Milliken commented on JENKINS-51461 Re: Inconsistent versions in update error message I do not believe that this is specific to the issues with the 2.123 release. It appears that the error popup is built from data which is not necessarily in sync - the error from the previous update attempt, and the currently available update version, as opposed to the version which was available when the attempt was made. I agree that this is very unlikely to occur in general, however, it would make sense if the error reliably indicated which version upgrade was actually attempted. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-51461) Inconsistent versions in update error message
Title: Message Title Paul Milliken created an issue Jenkins / JENKINS-51461 Inconsistent versions in update error message Issue Type: Bug Assignee: Unassigned Components: core Created: 2018-05-21 20:38 Environment: 2.122 on OpenJDK 1.8.0_151-b12, Linux Priority: Trivial Reporter: Paul Milliken Noticed a minor (and very unimportant) glitch as a result of JENKINS-51447. After previously failing to download 2.123, and then manually triggering an update check, the error popup now reads "Upgrade to Jenkins 2.124 failed: Failed to download from http://updates.jenkins-ci.org/download/war/2.123/jenkins.war (redirected to: http://mirrors.jenkins-ci.org/war/2.123/jenkins.war)." (Note the version mismatch between the message and the URL - they matched before the 2.124 update was detected). Triggering the retry correctly downloads the newly released 2.124. (The above was starting from an existing 2.122 installation). Add Comment
[JIRA] (JENKINS-31661) Jenkins.rootUrl too often unset or incorrect
Title: Message Title Paul Milliken edited a comment on JENKINS-31661 Re: Jenkins.rootUrl too often unset or incorrect [~wfollonier] That sounds promising. I'm not set up to be able to test it readily at the moment unfortunately. My Jenkins URL is [http://jenkins..private/|http://jenkins..private/] - hopefully the relation relaxation of the TLD validation will permit that (from a quick read of the code, I think it will). For the time being, I've disabled the admin monitor on my installation.Thanks for the quick response. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-31661) Jenkins.rootUrl too often unset or incorrect
Title: Message Title Paul Milliken commented on JENKINS-31661 Re: Jenkins.rootUrl too often unset or incorrect Wadeck Follonier That sounds promising. I'm not set up to be able to test it readily at the moment unfortunately. My Jenkins URL is http://jenkins..private/ - hopefully the relation of the TLD validation will permit that (from a quick read of the code, I think it will). For the time being, I've disabled the admin monitor on my installation. Thanks for the quick response. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-31661) Jenkins.rootUrl too often unset or incorrect
Title: Message Title Paul Milliken commented on JENKINS-31661 Re: Jenkins.rootUrl too often unset or incorrect Since this has been merged in 2.119, my Jenkins installation is constantly showing the "Jenkins root URL seems to be invalid. It is required for the proper operation of many Jenkins features like email notifications, PR status update, and environment variables such as BUILD_URL." notification. I have tried modified the URL setting to a completely different value, and then back to the correct value to ensure that it is definitely set, yet this message continues to display (even after a Jenkins restart). The configured URL is definitely correct. I'm guessing there's some extra check being performed which makes Jenkins believe it to be incorrect - most likely something related to the docker / nginx setup I've got going on. However, I feel like there should be a simple way of confirming to Jenkins that yes, the URL as configured is the correct one for it to be using and to stop prompting about it. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-41589) Make the change to stacktraces in 2.43 configurable
Title: Message Title Paul Milliken created an issue Jenkins / JENKINS-41589 Make the change to stacktraces in 2.43 configurable Issue Type: Improvement Assignee: Unassigned Components: core Created: 2017/Jan/31 8:11 AM Labels: usability Priority: Minor Reporter: Paul Milliken Jenkins 2.43 introduced a change to display stack traces in a "logical" order. The standard order for displaying stack traces shows the "least important" information at the top. For an end-user (ie, not a Jenkins administrator / developer / java export) this is generally more useful, as it provides (in theory) a summary of the error, rather than the low level technical details. While this change may make sense for developers, it does not make sense for all Jenkins users. Additionally, most Java developers (for whom this is in theory most useful) are used to the standard way stacktraces are presented. Add Comment
[JIRA] [core] (JENKINS-26250) Asynchronous delete of workspace doesn't detect fail to rename
Paul Milliken created JENKINS-26250 Asynchronous delete of workspace doesnt detect fail to rename Issue Type: Bug Assignee: vjuranek Components: core, ws-cleanup-plugin Created: 30/Dec/14 3:22 PM Description: I've witnessed Jenkins randomly fail to remove a workspace (job configured with "Delete workspace before build starts" selected). This seems to happen randomly and results in the build failing due to old data being present. I can force this to occur by opening a command prompt in the workspace before starting the build. I've had a quick glance at the Jenkins code, and it looks like the call workspace.renameTo call in the Wipeout class is failing silently. This in turn seems to be because the implementation of renameTo in FilePath doesn't check the return value of the java.lang.File.renameTo call. If the workspace cannot be renamed for any reason, the cleanup should either fallback to deleting synchronously (and still potentially fail due to whatever lock prevented the rename) or immediately report an error. Environment: Jenkins 1.595. Workspace cleanup plugin 0.24. Windows Server 2008 R2 Enterprise. AMD64. Oracle Java 1.7u25. Project: Jenkins Priority: Minor Reporter: Paul Milliken 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-13509) PROPFILE handling of missing file isn't very nice
Paul Milliken created JENKINS-13509:
---
Summary: PROPFILE handling of missing file isn't very nice
Key: JENKINS-13509
URL: https://issues.jenkins-ci.org/browse/JENKINS-13509
Project: Jenkins
Issue Type: Bug
Components: build-name-setter, token-macro
Environment: Jenkins 1.460
build-name-setter 1.3
token macro plugin 1.5.1
Reporter: Paul Milliken
Assignee: Kohsuke Kawaguchi
Priority: Minor
My build generates a properties file containing version information (derived
from various things like the subverison revision and branch name). I'd like to
be able to include this in my build names automatically. I'm looking at setting
the build name to something like this:
#${BUILD_NUMBER} - ${PROPFILE,file=version.properties,property=version}
Since build-name-setting runs twice (once after checkout and once after build),
the first attempt fails as the properties file doesn't exist yet.
In the case when I try to use an invalid macro, an message is logged in the
console output (Unrecognized macro 'XXX' in ) but the build otherwise
continues. However, in this case, a FATAL error is logged:
FATAL: /home/jenkins/.jenkins/jobs//version.properties (No such file or
directory)
java.io.FileNotFoundException:
/home/jenkins/.jenkins/jobs//version.properties (No such file or directory)
rest of stack trace
It would be nice if the behaviour was consistent, and the absence of the
properties file simply resulted in a warning similar to an invalid macro,
rather than completely breaking the 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-12632) Subversion plugin update fails
[ https://issues.jenkins-ci.org/browse/JENKINS-12632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Milliken reopened JENKINS-12632: - Just re-tested with a fresh setup of Jenkins 1.456 on Fedora. Very simply setup, just grabbed the .war file and ran it. After first startup, the plugin folder contained subversion.jpi, which had a reported version of 1.34 paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.* subversion.jpi paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 Update manager reported that 1.39 was available. Told it to download and install after restart (but not to restart automatically). After the download, had subversion.jpi and subversion.bak (as expected), with the appropriate versions. paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.* subversion.bak subversion.jpi paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.39 paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 Restarted jenkins. paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.* subversion.bak subversion.jpi paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 It looks like the update is still failing to be automatically pinned, resulting in the bundled version overwriting it. Manually pinning the plugin (by creating subversion.jpi.pinned) works. Subversion plugin update fails -- Key: JENKINS-12632 URL: https://issues.jenkins-ci.org/browse/JENKINS-12632 Project: Jenkins Issue Type: Bug Components: cvs, plugin, subversion, update-center Environment: Jenkins 1.450 CentOS 6.2 (2.6.32-220.4.1.el6.centos.plus.x86_64) java version 1.6.0_29 Java(TM) SE Runtime Environment (build 1.6.0_29-b11) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) Reporter: Paul Milliken Labels: jenkins, plugin I'm encountering an issue similar to JENKINS-12514 with Jenkins 1.450. Update manager reports that I'm running subversion plugin 1.34 and 1.37 is available. In my plugins folder I can see: -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi I tell Jenkins to install 1.37. Once it's downloaded I can see: -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak -rw-rw-r--. 1 jenkins jenkins 2103308 Feb 2 15:43 subversion.jpi Checking the manifests: [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.37 Restart jenkins to apply the changes. At this point, the present files are: -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi and the manifests: [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 And update manager still reports 1.34 with 1.37 available. -- 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-12632) Subversion plugin update fails
[ https://issues.jenkins-ci.org/browse/JENKINS-12632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=160107#comment-160107 ] Paul Milliken commented on JENKINS-12632: - Since I reported it on 1.450 in Linux, even if it is a duplicate of 12514, then it wasn't fixed on Linux at that point. I'll retry my test case once 1.456 is released. Subversion plugin update fails -- Key: JENKINS-12632 URL: https://issues.jenkins-ci.org/browse/JENKINS-12632 Project: Jenkins Issue Type: Bug Components: cvs, plugin, subversion, update-center Environment: Jenkins 1.450 CentOS 6.2 (2.6.32-220.4.1.el6.centos.plus.x86_64) java version 1.6.0_29 Java(TM) SE Runtime Environment (build 1.6.0_29-b11) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) Reporter: Paul Milliken Labels: jenkins, plugin I'm encountering an issue similar to JENKINS-12514 with Jenkins 1.450. Update manager reports that I'm running subversion plugin 1.34 and 1.37 is available. In my plugins folder I can see: -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi I tell Jenkins to install 1.37. Once it's downloaded I can see: -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak -rw-rw-r--. 1 jenkins jenkins 2103308 Feb 2 15:43 subversion.jpi Checking the manifests: [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.37 Restart jenkins to apply the changes. At this point, the present files are: -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi and the manifests: [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 And update manager still reports 1.34 with 1.37 available. -- 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
