[JIRA] (JENKINS-12783) Delete workspace before build starts ignores Exlude patterns (for directories)
Title: Message Title Tim Bradt commented on JENKINS-12783 Re: Delete workspace before build starts ignores Exlude patterns (for directories) This bug is unfortunate. We're trying to preserve our IntelliJ project files so we don't have to restore project settings every time we build. This should really be addressed. +1 vote Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.143241.1329315126000.8882.1565100780377%40Atlassian.JIRA.
[JIRA] (JENKINS-57159) Improve JobConfigHistory to support managed files
Title: Message Title Tim Bradt commented on JENKINS-57159 Re: Improve JobConfigHistory to support managed files Excellent! Thank you Jochen. You can definitely close out this ticket then from my view. The config history for system configs is different enough from the job configuration that it would be helpful to add content for it to the documentation. Thanks again. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57159) Improve JobConfigHistory to support managed files
Title: Message Title Tim Bradt commented on JENKINS-57159 Re: Improve JobConfigHistory to support managed files The fact that all of the managed files are stored in a single xml file is a disappointing design when it comes to this, but not a deal breaker in the end. I can live with that. However... Now that I find these entries by going to the config history for system configuration, I notice that there is no way to do the following: diff between 2 versions restore a selected version (though this is probably not wise given that all of the files are in a single xml format so let's ignore this point) So at least I can get to the history which is a good start and still useful, but I would need to copy and paste the content into external files and use a different tool to diff them. I can do that, but this issue morphs into an improvement to perhaps provide a means to at least diff the managed config. This might involve UI changes to allow for separating the config history of managed config from the other system configurations if it doesn't make sense to provide diff for other system configs. But maybe it wouldn't hurt to provide diff on the rest of it as well. I haven't looked that closely at the actual files to know for sure, nor have I had reasons previously to need a diff on the other content. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57159) Improve JobConfigHistory to support managed files
Title: Message Title Tim Bradt created an issue Jenkins / JENKINS-57159 Improve JobConfigHistory to support managed files Issue Type: New Feature Assignee: Stefan Brausch Components: jobconfighistory-plugin Created: 2019-04-23 15:12 Environment: Cloudbees Core Managed Master 2.138.2.2-rolling OS unknown - whatever Cloudbees uses Job Configuration History Plugin 2.18.3 Using Chrome for web browser Priority: Major Reporter: Tim Bradt The JobConfigHistory plugin works for jobs as well as system configuration. The other primary component that serves a good chunk of our configuration is the managed files, which this plugin does not currently support, and we feel that pain. It would be extremely useful to have this. Add Comment
[JIRA] (JENKINS-18567) Add Watch button to Job summary screen
Title: Message Title Tim Bradt commented on JENKINS-18567 Re: Add Watch button to Job summary screen Never mind. I found it where I didn't expect it. It's not in the main navigation on the top left, but you'll find it when you scroll down the categories in the job summary itself. I was looking at a multi-job so had to scroll down below the display of job status. There still should have been some documentation added for the feature. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-18567) Add Watch button to Job summary screen
Title: Message Title Tim Bradt commented on JENKINS-18567 Re: Add Watch button to Job summary screen I've enabled the option in system configuration, but can't find any Watch option on the project page in Jenkins. And there is no documentation for this feature on the main help page for this plugin. Only cursory mention of it in the revision history. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42477) Rebuild open merge requests option of "Never" does not work
Title: Message Title Tim Bradt commented on JENKINS-42477 Re: Rebuild open merge requests option of "Never" does not work This is a bug with fairly significant impact for us as folks are still in the habit of closing their merge requests after pushing changes, and creating new merge requests. Then the failed acceptance of the merge request by Jenkins causes our team another support investigation. None of this should happen since we have it configured to "Never" rebuild open merge requests. Any update on when work is going to start on this? 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-42477) Rebuild open merge requests option of "Never" does not work
Title: Message Title Tim Bradt created an issue Jenkins / JENKINS-42477 Rebuild open merge requests option of "Never" does not work Issue Type: Bug Assignee: Robin Müller Components: gitlab-plugin Created: 2017/Mar/03 5:24 PM Environment: Jenkins 2.32.2 running on Ubuntu 14 64-bit, with GitLab Plugin 1.4.5. Priority: Critical Reporter: Tim Bradt After upgrading, it appears that the "Never" option for the Rebuild open Merge Requests is broken. As soon as anything is pushed to the source branch for an open merge request, a rebuild occurs automatically even though we have selected "Never". In 1.1.32 this worked fine and blocked the auto rebuild. We have developers used to closing their merge request and opening a new one, but now they are closing the MR that triggered the build. So Jenkins fails attempting to accept the merge request. Add Comment
[JIRA] (JENKINS-28529) Git polling deletes files in workspace if "clean" and "ignore commits in path" are both enabled
Title: Message Title Tim Bradt commented on JENKINS-28529 Re: Git polling deletes files in workspace if "clean" and "ignore commits in path" are both enabled We also had the same behavior if "Clean before checkout" and "Polling ignores commits with certain messages" are both enabled. Fortunately there is a workaround that will work for some. Unless the sequence is critical, switching to "Clean after checkout" eliminates the clean during polling. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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] [subversion-plugin] (JENKINS-22568) Subversion polling not work when Repository URL value is variable - E125002: Malformed URL '${SVN_REPO_VARIABLE}'
Title: Message Title
Tim Bradt commented on JENKINS-22568
Re: Subversion polling not work when Repository URL value is variable - E125002: Malformed URL '${SVN_REPO_VARIABLE}'
Confirmed. Updated to 2.5.2 and confirmed that polling with a variable URL works.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
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] [subversion-plugin] (JENKINS-22922) Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44)
Title: Message Title Tim Bradt commented on JENKINS-22922 Re: Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44) Thanks much for the update. I just updated to 2.5.2 and confirmed that polling with a variable URL works! Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [subversion-plugin] (JENKINS-22922) Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44)
Title: Message Title
Tim Bradt commented on JENKINS-22922
Re: Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44)
Manuel, are you saying we are supposed to use $REPO as opposed to $ {REPO}
. I've always used $ {envvar}
for the SCM URL, but the 2 formats appear to be interchangeable. They both work for the actual build when triggered manually. However, neither works for SCM polling.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
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] [subversion-plugin] (JENKINS-22922) Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44)
Title: Message Title
Tim Bradt commented on JENKINS-22922
Re: Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44)
Using %Var% in the URL is not valid syntax. You must use $ {SVN_PERIPHERALS-P2_LATEST}
. The only place you can use standard Windows syntax (%) is inside a Windows batch command build step. Everywhere else it requires Java syntax.
With that, you should be able to do a check out. It's just SCM Polling that fails.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
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] [categorized-view-plugin] (JENKINS-27865) Regex not working in categorized jobs plugin
Tim Bradt updated JENKINS-27865 Regex not working in categorized jobs plugin Change By: Tim Bradt (15/Apr/15 3:50 PM) Attachment: TestCategoryView.png 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] [categorized-view-plugin] (JENKINS-27865) Regex not working in categorized jobs plugin
Tim Bradt commented on JENKINS-27865 Regex not working in categorized jobs plugin I just set up your scenario on my dev Jenkins - added a view with a job named "Branch 8.2.2" and then set up a regex category with your same regex. It worked fine. Somehow it didn't register the first time I looked at this... As shown in your after-creating-view.PNG, do you actually have no jobs in My View? If so, then that's your problem. You can't have a job group categorization for a view that contains no jobs, or a categorization for jobs the view doesn't contain. Under "Job Filters" in the view configuration, you'll need to either select individual jobs using check boxes or "Use a regular _expression_ to include jobs into the view". Once "Branch 8.2.2" actually is included in your view, your category regex will work. I'll try to attach a pic. 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] [subversion-plugin] (JENKINS-27898) Change Subversion plugin to allow configuration of different ways to react to working copy locked
Tim Bradt commented on JENKINS-27898 Change Subversion plugin to allow configuration of different ways to react to working copy locked These jobs do not actually share workspaces, to be accurate. They each have their own workspace, but within the same working copy of the repository. That is because we have one big repository for our entire suite of software. Inside that repo we have different sections for our different modules that belong to this suite (i.e. - Foundation, Picking, Sorting, Planning, etc). The base URL for the source for these is GII/All/trunk/30-Dev, so my workspaces are at /30-Dev/Foundation, /30-Dev/Picking, /30-Dev/Sorting, etc... So even though I may only be updating the portion of the working copy at 30-Dev/Picking, SVN locks the working copy up at 30-Dev. Thus, I cannot update 30-Dev/Sorting while my Picking job is updating. There are interdependencies between the aforementioned modules (primarily on Foundation) that would make it difficult to break away from a shared working copy. Basically, this repository was designed to simplify developers lives. Yes, this is less than ideal (I would love to have individual repositories as we did in Gen 1 of our software), but we are dealing with the constraints given to us. It presents some challenges in a build environment, but the head architect decided to go this direction as it makes a ton of sense for the application side of the business who are actually customizing our product and implementing it for our customers. It may appear to lack sense to someone from the outside looking in with no knowledge of our business model, but it's the hand we've been dealt. Throttle Concurrent Builds Plugin really does not provide what I'm after, any more than what I could achieve with limiting executors, though it would simplify that approach. That would queue up my other jobs, which is counter-productive to fast feedback for builds triggered by commits. I don't want to throttle at the job level. I simply want the ability to wait during the svn update portion of these jobs. We may look at building our own custom plugin for svn updates if this does not make sense to the core community. I would like to have a plugin that is flexible enough to deal with our business constraints, but if that can't happen then I suppose it's time to start creating our own. 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] [subversion-plugin] (JENKINS-22568) Subversion polling not work when Repository URL value is variable - E125002: Malformed URL '${SVN_REPO_VARIABLE}'
Tim Bradt
commented on JENKINS-22568
Subversion polling not work when Repository URL value is variable - E125002: Malformed URL '${SVN_REPO_VARIABLE}'
I figured that would be the case. The problem appears to be that the plug in does not expand variables, and I doubted it mattered where they originated.
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] [subversion-plugin] (JENKINS-27898) Change Subversion plugin to allow configuration of different ways to react to working copy locked
Tim Bradt created JENKINS-27898 Change Subversion plugin to allow configuration of different ways to react to working copy locked Issue Type: Improvement Assignee: Unassigned Components: subversion-plugin Created: 10/Apr/15 8:15 PM Description: The Jenkins job/build immediately fails if the working copy is locked. For me, this is undesirable due to the structure of our repository. We have multiple builds trying to update their individual portions of the working copy. Unfortunately, svn locks the working copy one directory above the one in which the update occurs, so we get failures if multiple builds are triggered concurrently, even though they are in different sections of the repository. The way it currently works, we are notifying commiters that they have a build failure even though the changes themselves did not cause the failure, and then if they have nothing more to commit there is no choice but to MANUALLY trigger the job again. I would much prefer to have this be configurable. Let me decide if I want it to fail (current behavior), or try again every ___ seconds with ___ total attempts, other... Environment: Windows Server 2012 R2 Jenkins v1.573 Subversion Plug-in v2.5 Chrome Project: Jenkins Priority: Major Reporter: Tim Bradt 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] [categorized-view-plugin] (JENKINS-27865) Regex not working in categorized jobs plugin
Tim Bradt commented on JENKINS-27865 Regex not working in categorized jobs plugin Critical? Anyway...You could try ^Branch\s8.2.2$, or just remove the space from your job name (replace with underscore or something). 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] [subversion-plugin] (JENKINS-22568) Subversion polling not work when Repository URL value is variable - E125002: Malformed URL '${SVN_REPO_VARIABLE}'
Tim Bradt
commented on JENKINS-22568
Subversion polling not work when Repository URL value is variable - E125002: Malformed URL '${SVN_REPO_VARIABLE}'
Also does not work in Subversion plugin 2.5 when defining the variables in global properties. This is already linked to JENKINS-22922 which spells that out.
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] [subversion-plugin] (JENKINS-22922) Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44)
Tim Bradt
commented on JENKINS-22922
Subversion : environment variables work only partially (got broken in 2.3 or prior, after 1.44)
This is still a problem in Subversion plug-in 2.5...
Started on Apr 10, 2015 3:42:02 PM
ERROR: Failed to check repository revision for ${SVN_URL_ROOT}30-Dev/DatabaseBuild
org.tmatesoft.svn.core.SVNException: svn: E125002: Malformed URL '${SVN_URL_ROOT}30-Dev/DatabaseBuild'
${SVN_URL_ROOT} is defined in global properties, and I do not have/need any credentials on this repo to do an update.
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] [subversion-plugin] (JENKINS-21625) Subversion Polling does not work properly whenever using variables in the Repository URL
Tim Bradt
commented on JENKINS-21625
Subversion Polling does not work properly whenever using variables in the Repository URL
This is still a problem in Subversion plug-in 2.5...
Started on Apr 10, 2015 3:42:02 PM
ERROR: Failed to check repository revision for ${SVN_URL_ROOT}30-Dev/DatabaseBuild
org.tmatesoft.svn.core.SVNException: svn: E125002: Malformed URL '${SVN_URL_ROOT}30-Dev/DatabaseBuild'
I don't have any credential issues.
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] [other] (JENKINS-2107) email notification when disk space runs low.
Tim Bradt commented on JENKINS-2107 email notification when disk space runs low. Perspective. Technically I agree that no build is impacted by marking a node offline - I can address the issue and resume the build. However, my issue is that I have a department full of developers and ScrumMasters that are relying on our full nightly build being completed and waiting when they come in the next day. I can't afford to fall below my threshold and queue up the remainder of that process due to offline node. So my non-technical perspective (and that of my management I expect) is that I effectively failed the build/deploy/test process by causing a significant delay. Big impact on human resources. I agree that a soft/warning threshold would meet the requirement for a proactive solution that doesn't suspend a running build. 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] [other] (JENKINS-2107) email notification when disk space runs low.
Tim Bradt edited a comment on JENKINS-2107 email notification when disk space runs low. Did you even read my entire comment before commenting on it? "I just implemented Oleg's suggested solution..." And where in my comments do I mention anything about a disconnect? How are any further jobs supposed to be executed on an offline node? Coming in the next day with the remainder of my build jobs queued up due to falling below the disk space threshold is not desirable. Effectively that is a failed build. I (likely along with the person who originally requested this) am looking for a proactive solution. And another thing...I don't want emails every time the node goes offline because I've got something in my process that restarts the slave machine - by design. I just want an email when disk space falls below the threshold. So obviously I tried the solution. I just assumed I must have misinterpreted the fairly ambiguous description for the solution to come with this much "baggage". 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] [other] (JENKINS-2107) email notification when disk space runs low.
Tim Bradt commented on JENKINS-2107 email notification when disk space runs low. Did you even read my entire comment before commenting on it? "I just implemented Oleg's suggested solution..." And where in my comments do I mention anything about a disconnect? How are any further jobs supposed to be executed on an offline node? Coming in the next day with the remainder of my build jobs queued up due to falling below the disk space threshold is not desirable. And another thing...I don't want emails every time the node goes offline because I've got something in my process that restarts the slave machine - by design. I just want an email when disk space falls below the threshold. So obviously I tried the solution. I just assumed I must have misinterpreted the fairly ambiguous description for the solution to come with this much "baggage". 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] [other] (JENKINS-2107) email notification when disk space runs low.
Tim Bradt reopened JENKINS-2107 email notification when disk space runs low. I don't like the fix, personally. And I also don't think it satisfied the original request which allows no room for an offline node. I just implemented Oleg's suggested solution, but my complaint with it is that it takes the node (master or slave) offline in order to achieve the desired notification. That means I could very well have a build in progress when free disk space falls below the setting, and then the node will be taken offline. That's not at all what I want! I want to be proactive, and set a threshold that lets me know I'm running a bit low on disk space so that I can address it BEFORE it impacts a single build. Node monitoring and notification based on online/offline status certainly does not meet that need. At that point it's still too late. Whether I run out of disk space or the node goes offline, the result is the same - I've just failed a build. Please feel free to correct me if I misinterpreted the resolution, as it seemed a bit open to interpretation. Change By: Tim Bradt (16/Feb/15 10:28 PM) Resolution: Fixed Status: Resolved Reopened 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] [subversion-plugin] (JENKINS-26944) Subversion plugin does not resolve environment variables for SCM polling
Tim Bradt commented on JENKINS-26944 Subversion plugin does not resolve environment variables for SCM polling Agree that the defects themselves are different. I was just pointing to a comment within that bug that seemed relevant to this subject, though I'm be happy to know I apparently misinterpreted. 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] [subversion-plugin] (JENKINS-26944) Subversion plugin does not resolve environment variables for SCM polling
Tim Bradt commented on JENKINS-26944 Subversion plugin does not resolve environment variables for SCM polling In the Jenkins system configuration, under Global Properties. 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] [subversion-plugin] (JENKINS-26944) Subversion plugin does not resolve environment variables for SCM polling
Tim Bradt created JENKINS-26944 Subversion plugin does not resolve environment variables for SCM polling Issue Type: Bug Assignee: Unassigned Components: subversion-plugin Created: 12/Feb/15 8:58 PM Description: The subversion plug-in of course resolves environment variables for updating the working copy. However, when using SCM polling env vars are not resolved. I have found the following comment in Jenkins-13075: Michael Clarke added a comment - 18/Nov/12 9:37 AM During polling the plugin isn't provided the environmental variables so wouldn't be able to do an expansion for you. This is partly because polling is supposed to be a task that doesn't require user input so there would be no way of handling user defined parameters. I don't understand the problem with SCM polling allowing a dependency on environment variables. This is not dynamic user input, but a static environment variable in Jenkins. Polling and the environment variable both reside in Jenkins. Why can polling then not be coded to access an environment variable? Perhaps the other "partly" of the explanation would make more sense. So this may end up being resolved through explanation, but for now I'm creating it as a bug. The logic behind the omission escapes me so my perspective at the moment is defect. Project: Jenkins Priority: Minor Reporter: Tim Bradt 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] [powershell-plugin] (JENKINS-15890) [PATCH] Powershell improvements
Tim Bradt commented on JENKINS-15890 [PATCH] Powershell improvements I just installed the plugin today (v1.2) and my job did not fail even though the Powershell errored: Started by user anonymous [EnvInject] - Loading node environment variables. Building on master in workspace C:\SPE\Jenkins\jobs\Test1\workspace [EnvInject] - Injecting environment variables from a build step. [EnvInject] - Injecting as environment variables the properties file path 'C:/SPE/Jenkins/DailyBuild/buildtime.properties' [EnvInject] - Variables injected successfully. [workspace] $ cmd /c call C:\Users\SPESER~1\AppData\Local\Temp\hudson868747164412287880.bat C:\SPE\Jenkins\jobs\Test1\workspace>rem echo BUILDTIME=1027 > C:\SPE\Jenkins\DailyBuild\buildtime.properties C:\SPE\Jenkins\jobs\Test1\workspace>exit 0 [workspace] $ powershell.exe "& 'C:\Users\SPESER~1\AppData\Local\Temp\hudson7972185748419603015.ps1'" out-file : Could not find a part of the path 'C:\SPE\Jenkins\jobs\Test1\workspace%SE_R_MASTER%\buildtime.properties'. At C:\Users\speservice\AppData\Local\Temp\hudson7972185748419603015.ps1:2 char:1 + Write-Output "BUILDTIME=$time" > %SE_R_MASTER%\buildtime.properties + ~~~ + CategoryInfo : OpenError: ( [Out-File], DirectoryNotFoundException + FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.OutFileCommand Finished: SUCCESS I don't like being locked in to being path relative to workspace (the windows batch command doesn't do this). Yes, I have already adjusted my path, but my primary issue is having the false positive. That makes it unusable in a production environment. 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] [subversion-plugin] (JENKINS-18935) Make Subversion plugin support Subversion 1.8
Tim Bradt commented on JENKINS-18935 Make Subversion plugin support Subversion 1.8 Glad to hear externals work since we have 3 of them. @Jason/Shannon - For reasons I won't go into, we also have a large repository which takes 30-40 minutes for a full checkout (we then build pieces of it using custom workspaces), so deleting and checking out for every build would definitely be undesirable. "Emulate clean checkout.." works great for us. If we have to delete the working copy in order to do the upgrade via new checkout, that's fine. 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] [subversion] (JENKINS-24247) Subversion Repository URL validation does not support variable substitution
Tim Bradt edited a comment on JENKINS-24247 Subversion Repository URL validation does not support variable substitution Why only validate a portion of the URL in the first place? Why not perform ALL substitutions first, and then do the validation? 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] [subversion] (JENKINS-24247) Subversion Repository URL validation does not support variable substitution
Tim Bradt commented on JENKINS-24247 Subversion Repository URL validation does not support variable substitution Why not perform ALL substitutions first, and then do the validation? 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] [subversion] (JENKINS-24247) Subversion Repository URL validation does not support variable substitution
Tim Bradt created JENKINS-24247 Subversion Repository URL validation does not support variable substitution Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: subversion Created: 13/Aug/14 3:00 PM Description: Variable substitution is supported for polling SCM and for checkouts, but not for validation of the Repository URL. At best this is extremely misleading - the first time I tried variable substitution I aborted any further attempts since the URL validation told me it was invalid. It was only after I later returned to the concept and did research that I found out it appeared others were using this approach and I tried it successfully. To me, this seems like a defect, or at least a design flaw that should be addressed. If the product supports variable substitution, then so should the on screen validation. Environment: Windows Server 2012, Java 1.8.0_05, Jenkins 1.573 Project: Jenkins Priority: Major Reporter: Tim Bradt 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] [subversion] (JENKINS-18935) Make Subversion plugin support Subversion 1.8
Tim Bradt commented on JENKINS-18935 Make Subversion plugin support Subversion 1.8 And there you have it @Jeff Dege...exactly what we're doing on our build servers. After a year, I'm tired of waiting for Jenkins to get current so succumbing to a downgrade of SVN clients on our build servers. I had upgraded them to 1.8 and made my own clean checkout script, but that means no Poll SCM build trigger. 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] [subversion] (JENKINS-18935) Make Subversion plugin support Subversion 1.8
Tim Bradt commented on JENKINS-18935 Make Subversion plugin support Subversion 1.8 Latest SVNKIT stable version 1.8.3 as of 1/21/14 fully supports 1.8. Hope we see some activity here soon. +10 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.
