[JIRA] (JENKINS-36189) Credentials from instance profile?
Title: Message Title Trevor Baker created an issue Jenkins / JENKINS-36189 Credentials from instance profile? Issue Type: Bug Assignee: Nicolas De Loof Components: amazon-ecr-plugin Created: 2016/Jun/23 2:45 PM Priority: Minor Reporter: Trevor Baker Is it possible to leverage ec2 instance profiles rather than iam access keys bound to users for the aws credentials? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] [core] (JENKINS-34189) footer overlaps with content due to css settings
Title: Message Title Trevor Baker commented on JENKINS-34189 Re: footer overlaps with content due to css settings See https://github.com/jenkinsci/jenkins/pull/2254 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] [core] (JENKINS-34189) footer overlaps with content due to css settings
Title: Message Title Trevor Baker created an issue Jenkins / JENKINS-34189 footer overlaps with content due to css settings Issue Type: Bug Assignee: Frédéric Camblor Attachments: Screen Shot 2016-04-12 at 7.24.31 PM.png Components: core, scm-sync-configuration-plugin Created: 2016/Apr/13 12:37 AM Environment: Jenkins 1.648 scm-sync-configuration 0.0.9 Priority: Major Reporter: Trevor Baker The footer CSS has position: absolute and had a variable height. Since the footer can contain error messages from plugins, the height would grow to cover up actual content (console logs, etc.). For example, the scm-sync-configuration plugin has the option to put scm failures in the footer. It adds as many newlines are there are failing commits, which can be many lines until someone fixes the problem or clears the log. The footer expands upwards and occludes the console log, which makes diagnosing failed builds problematic.
[JIRA] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker commented on JENKINS-32690 Re: Cannot manually provision new slave if one already exists The problem case, IMO, is "stop on idle." The terminate case seems straight forward. I'm not a committer, nor do I use stop-on-idle. I am a heavy user of the plugin though and would rather use the head revision than my own fork so am trying to spitball solutions. 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] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker edited a comment on JENKINS-32690 Re: Cannot manually provision new slave if one already exists It worked for me.# Provision a node with some tags that Jenkins sets.# Stop the ec2 instance.# Attempt to provision another node same as step 1, get returned the instance id from step #1# Choose "Launch slave agent" and it will start and reconnect to instance# Stop the ec2 instance in ec2 console# Remove or modify the ec2 tags via the ec2 console so they don't match what is on the Jenkins slave template# Attempt to provision another node same as step 1, you get a new instance launch# Delete new second instance from Jenkins UI# Modify the EC2 tags on the original instance via the ec2 console back to match the Jenkins slave template# Attempt to provision another node same as step 1, get returned the original instance id from step #1If the proposed "always provision a new node when asked for interactively" was implemented, deleting instance 2 in step 8 above wouldn't have been necessary. The code in question is here:https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L525-L549 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] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker commented on JENKINS-32690 Re: Cannot manually provision new slave if one already exists It worked for me. Provision a node with some tags that Jenkins sets. Stop the ec2 instance. Attempt to provision another node same as step 1, get returned the instance id from step #1 Choose "Launch slave agent" and it will start and reconnect to instance Stop the ec2 instance in ec2 console Remove or modify the ec2 tags via the ec2 console so they don't match what is on the Jenkins slave template Attempt to provision another node same as step 1, you get a new instance launch Delete new second instance from Jenkins UI Modify the EC2 tags on the original instance via the ec2 console back to match the Jenkins slave template Attempt to provision another node same as step 1, get returned the original instance id from step #1 If the proposed "always provision a new node when asked for interactively" was implemented, deleting instance 2 in step 8 above wouldn't have been necessary. Add Comment
[JIRA] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title
Trevor Baker edited a comment on JENKINS-32690
Re: Cannot manually provision new slave if one already exists
{quote}it is another hoop to jump through{quote}Perhaps the cleanest option from a user experience would be that manually provisioning a slave via the UI or cli would always provision new instance always , regardless of stop vs terminate idle configuration. For users with stop on idle, the automatic codepath based on queue demand could restart stopped nodes. The stopping and starting is done automagically based on demand. You idle stop and you restart based on demand. The cli has _disconnect-node_ and _reconnect-node_ commands, so that seems covered too.If Jenkins is configured with stop on idle and you want to _hide_ an ec2 instance it from Jenkins, manually updating ec2 tags doesn't seem too onerous. You simply revert back to the original tags to put it back under management. Wanting to temporarily assert control over the node and have Jenkins leave it alone is akin to temporarily detaching a running EC2 instance from an ELB or and an ASG. It is a managed machine, and you need to take explicit action to remove it from management. With the above, the in-context help is pretty easy to explain.
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] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker commented on JENKINS-32690 Re: Cannot manually provision new slave if one already exists it is another hoop to jump through Perhaps the cleanest option from a user experience would be that manually provisioning a slave via the UI or cli would always provision new instance always, regardless of stop vs terminate idle configuration. For users with stop on idle, the automatic codepath based on queue demand could restart stopped nodes. The stopping and starting is done automagically based on demand. You idle stop and you restart based on demand. The cli has disconnect-node and reconnect-node commands, so that seems covered too. If Jenkins is configured with stop on idle and you want to hide an ec2 instance it from Jenkins, manually updating ec2 tags doesn't seem too onerous. You simply revert back to the original tags to put it back under management. Wanting to temporarily assert control over the node and have Jenkins leave it alone is akin to temporarily detaching a running EC2 instance from an ELB or and ASG. It is a managed machine, and you need to take explicit action to remove it from management. With the above, the in-context help is pretty easy to explain. 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] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker commented on JENKINS-32690 Re: Cannot manually provision new slave if one already exists I have to either start the existing stopped slaves or delete them. Couldn't you modify the ec2 tags on your stopped instance, then the master wouldn't see nor start it? At least I think this would work from reading the code. 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] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker commented on JENKINS-32690 Re: Cannot manually provision new slave if one already exists If I changed the code to ignore offline nodes when manually provisioning nodes would this be acceptable? Similar to what was done in https://github.com/jenkinsci/ec2-plugin/pull/187, but only in the case of a manual provision. If a node was unknown to the current jenkins (but was previously started by Jenkins) and is stopped, it would be used to satisfy a manual provision request (this is the current behavior which would be kept). Would this work for everyone? Yes, I think that would work fine. In this manual provisioning use case, check to see if there is a stopped node of the same config, and if so, start it. If there is none, provision a new one. This path should not check idle capacity and should always add node capacity to the pool. 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] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title
Trevor Baker edited a comment on JENKINS-32690
Re: Cannot manually provision new slave if one already exists
{quote}starting 1 node at a time is much too slow.{quote}I agree. We've been toying with the idea of creating a cli script using create-node and or some groovy snippet to loop over to create nodes so we don't have to click through the UI repeatedly.
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] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker commented on JENKINS-32690 Re: Cannot manually provision new slave if one already exists starting 1 node at a time is much too slow. I agree. We've been toying with the idea of creating a cli script using create-node and some groovy snippet to loop over to create nodes so we don't have to click through the UI repeatedly. 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] [ec2-plugin] (JENKINS-33945) can't provision new nodes when a matching node is marked offline
Title: Message Title Trevor Baker reopened an issue Jenkins / JENKINS-33945 can't provision new nodes when a matching node is marked offline Change By: Trevor Baker Resolution: Fixed Status: Resolved Reopened 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] [ec2-plugin] (JENKINS-33945) can't provision new nodes when a matching node is marked offline
Title: Message Title
Trevor Baker commented on JENKINS-33945
Re: can't provision new nodes when a matching node is marked offline
It is also a problem for nodes provisioned automatically via StandardStrategyImpl
Create a 3x3 axis Multi-configuration job. Launch a single slave with the label that can run the job, then mark if offline. It won't start any new nodes and the job will be stuck.
Mar 31, 2016 6:46:45 PM FINER hudson.slaves.NodeProvisioner
Consulting hudson.slaves.NodeProvisioner$StandardStrategyImpl@6437ee5a provisioning strategy with state StrategyState{label=deployer, snapshot=LoadStatisticsSnapshot{definedExecutors=1, _onlineExecutors_=0, connectingExecutors=0, busyExecutors=0, idleExecutors=0, availableExecutors=0, queueLength=9}, plannedCapacitySnapshot=0, additionalPlannedCapacity=0}
Mar 31, 2016 6:46:45 PM FINE hudson.slaves.NodeProvisioner
Excess workload 7.906 detected. (planned capacity=0,connecting capacity=0,Qlen=7.906,available=0.174&0,_online_=0,m=0.5)
Mar 31, 2016 6:46:45 PM FINE hudson.plugins.ec2.EC2Cloud
Attempting provision, excess workload: 8
Mar 31, 2016 6:46:45 PM FINE hudson.plugins.ec2.EC2Cloud
Counting current slaves: All AMIS
Mar 31, 2016 6:46:45 PM FINE hudson.plugins.ec2.EC2Cloud
Existing instance found: i-3a616ebe AMI: ami-ce2d26a4 Template: null
Mar 31, 2016 6:46:45 PM FINE hudson.plugins.ec2.EC2Cloud
Counting current slaves: AMI: ami-ce2d26a4
Mar 31, 2016 6:46:45 PM FINE hudson.plugins.ec2.EC2Cloud
Existing instance found: i-3a616ebe AMI: ami-ce2d26a4 Template: Jenkins - Deployer Slave
Mar 31, 2016 6:46:45 PM FINE hudson.plugins.ec2.EC2Cloud
Available Total Slaves: 2147483646 Available AMI slaves: 2147483646 AMI: ami-ce2d26a4 TemplateDesc: Jenkins - Deployer Slave
Mar 31, 2016 6:46:45 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfo
Launching ami-ce2d26a4 for template Jenkins - Deployer Slave
Mar 31, 2016 6:46:46 PM FINE hudson.plugins.ec2.SlaveTemplate
Looking for existing instances with describe-instance: {InstanceIds: [],Filters: [{Name: image-id,Values: [ami-ce2d26a4]}, {Name: availability-zone,Values: [us-east-1a]}, {Name: subnet-id,Values: [subnet-xxx]}, {Name: instance.group-id,Values: [sg-xxx]}, {Name: key-name,Values: [dev]}, {Name: instance-type,Values: [t2.small]}, {Name: tag:Name,Values: [DEV-JENKINSSLAVE]}, {Name: tag:ENV,Values: [DEV]}],}
Mar 31, 2016 6:46:46 PM FINE hudson.plugins.ec2.SlaveTemplate
checkInstance: {InstanceId: i-3a616ebe,ImageId: snip}
Mar 31, 2016 6:46:46 PM FINE hudson.plugins.ec2.SlaveTemplate
Found existing corresponding Jenkins slave: i-3a616ebe
Mar 31, 2016 6:46:46 PM FINE hudson.plugins.ec2.SlaveTemplate
true - Node has capacity - can use it
Mar 31, 2016 6:46:46 PM FINE hudson.plugins.ec2.SlaveTemplate
Found existing instance: {InstanceId: i-3a616ebe,snip}
node: i-3a616ebe
Mar 31, 2016 6:46:46 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfo
Found existing pending or running: running instance: {InstanceId: i-3a616ebe,snip}
Mar 31, 2016 6:46:46 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfo
Using existing slave: i-3a616ebe
Instance i-3a616ebe in the above example is the temporarily offline node.
[JIRA] [ec2-plugin] (JENKINS-32690) Cannot manually provision new slave if one already exists
Title: Message Title Trevor Baker commented on JENKINS-32690 Re: Cannot manually provision new slave if one already exists Another behavior introduced with the commits addressing JENKINS-23787 is that you can not provision an new node while one is pending. In the use case where you are provisioning multiple nodes intentionally in anticipation of demand, you shouldn't have to wait for each newly provisioned node to be fully online before you can create another. I've rolled back to commit ad614dbbe2866a9b5ba9674d88b07184cbafd2a3 which is just before the stopped node additions but also includes the instance cap changes that I need. 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] [ec2-plugin] (JENKINS-33945) can't provision new nodes when a matching node is marked offline
Title: Message Title Trevor Baker commented on JENKINS-33945 Re: can't provision new nodes when a matching node is marked offline I provided PR 187 https://github.com/jenkinsci/ec2-plugin/pull/187 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] [ec2-plugin] (JENKINS-33945) can't provision new nodes when a matching node is marked offline
Title: Message Title Trevor Baker created an issue Jenkins / JENKINS-33945 can't provision new nodes when a matching node is marked offline Issue Type: Bug Assignee: Francis Upton Components: ec2-plugin Created: 2016/Mar/31 3:43 PM Environment: ec2 1.31 Priority: Critical Reporter: Trevor Baker You can not provision a new node if there is an existing node from the same SlaveTemplate which is marked offline. Offline nodes instance id will be returned and no new node will be provisioned. Add Comment
[JIRA] [ec2-plugin] (JENKINS-33879) can't proactively scale up ec2 slaves in anticipation demand
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33879
can't proactively scale up ec2 slaves in anticipation demand
Change By:
Trevor Baker
Most of our nodes idle timeout overnight. We run a large Multi-configuration job early in the morning. We know we need a certain number of nodes online and used to be able to proactively provision instances via the /computer UI. In recent jenkins and ec2 plugin versions I observe the following:1. attempt to start a new slave of a given ami2. plugin finds there is an idle node of that particular type and returns its id, rather than creating a new one.{noformat}Mar 29, 2016 4:45:31 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoLaunching ami-9fe6d8f5 for template Jenkins - Deployer Slave...snip...Mar 29, 2016 4:45:32 PM FINE hudson.plugins.ec2.SlaveTemplate true - Node has capacity - can use it...snip...Mar 29, 2016 4:45:32 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoUsing existing slave: i-b0614034{noformat}In the above, i-b0614034 was an existing instance.This used to work just fine. Now it refuses to create a new node. The change in behavior seems to have been introduced in relation to commit 6b286b185ba41efc33ab8558a6c43969975e6238 for issues JENKINS-23787 EC2 not spooling up stopped nodeshttps://github.com/jenkinsci/ec2-plugin/commit/6b286b185ba41efc33ab8558a6c43969975e6238#diff-f2115e33148d3db7c133fe014ad9dfddR569I blame _blame_ this code and a subsequent commit that added the additonal logging of " true - Node has capacity - can use it" where it returns the idle instance id rather than provisioning a new one as I explicity asked for.Exacerbating this is extremely slow instance provisioning in StandardStrategyImpl, which I intend to log as a separate story and cross reference.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ec2-plugin] (JENKINS-33879) can't proactively scale up ec2 slaves in anticipation demand
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33879
can't proactively scale up ec2 slaves in anticipation demand
Change By:
Trevor Baker
Most of our nodes idle timeout overnight. We run a large Multi-configuration job early in the morning. We know we need a certain number of nodes online and used to be able to proactively provision instances via the /computer UI. In recent jenkins and ec2 plugin versions I observe the following:1. attempt to start a new slave of a given ami2. plugin finds there is an idle node of that particular type and returns its id, rather than creating a new one. { { quote} Mar 29, 2016 4:45:31 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoLaunching ami-9fe6d8f5 for template Jenkins - Deployer Slave...snip...Mar 29, 2016 4:45:32 PM FINE hudson.plugins.ec2.SlaveTemplate true - Node has capacity - can use it...snip...Mar 29, 2016 4:45:32 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoUsing existing slave: i-b0614034 {quote } } This used to work just fine. Now it refuses to create a new node. The change in behavior seems to have been introduced in relation to commit 6b286b185ba41efc33ab8558a6c43969975e6238 for issues JENKINS-23787 EC2 not spooling up stopped nodeshttps://github.com/jenkinsci/ec2-plugin/commit/6b286b185ba41efc33ab8558a6c43969975e6238#diff-f2115e33148d3db7c133fe014ad9dfddR569I blame this code and a subsequent commit that added the additonal logging of " true - Node has capacity - can use it" where it returns the idle instance id rather than provisioning a new one as I explicity asked for.Exacerbating this is extremely slow instance provisioning in StandardStrategyImpl, which I intend to log as a separate story and cross reference.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ec2-plugin] (JENKINS-33879) can't proactively scale up ec2 slaves in anticipation demand
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33879
can't proactively scale up ec2 slaves in anticipation demand
Change By:
Trevor Baker
Most of our nodes idle timeout overnight. We run a large Multi-configuration job early in the morning. We know we need a certain number of nodes online and used to be able to proactively provision instances via the /computer UI. In recent jenkins and ec2 plugin versions I observe the following:1. attempt to start a new slave of a given ami2. plugin finds there is an idle node of that particular type and returns its id, rather than creating a new one. { quote noformat }Mar 29, 2016 4:45:31 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoLaunching ami-9fe6d8f5 for template Jenkins - Deployer Slave...snip...Mar 29, 2016 4:45:32 PM FINE hudson.plugins.ec2.SlaveTemplate true - Node has capacity - can use it...snip...Mar 29, 2016 4:45:32 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoUsing existing slave: i-b0614034 { quote noformat }In the above, i-b0614034 was an existing instance.This used to work just fine. Now it refuses to create a new node. The change in behavior seems to have been introduced in relation to commit 6b286b185ba41efc33ab8558a6c43969975e6238 for issues JENKINS-23787 EC2 not spooling up stopped nodeshttps://github.com/jenkinsci/ec2-plugin/commit/6b286b185ba41efc33ab8558a6c43969975e6238#diff-f2115e33148d3db7c133fe014ad9dfddR569I blame this code and a subsequent commit that added the additonal logging of " true - Node has capacity - can use it" where it returns the idle instance id rather than provisioning a new one as I explicity asked for.Exacerbating this is extremely slow instance provisioning in StandardStrategyImpl, which I intend to log as a separate story and cross reference.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ec2-plugin] (JENKINS-33879) can't proactively scale up ec2 slaves in anticipation demand
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33879
can't proactively scale up ec2 slaves in anticipation demand
Change By:
Trevor Baker
Most of our nodes idle timeout overnight. We run a large Multi-configuration job early in the morning. We know we need a certain number of nodes online and used to be able to proactively provision instances via the /computer UI. In recent jenkins and ec2 plugin versions I observe the following:1. attempt to start a new slave of a given ami2. plugin finds there is an idle node of that particular type and returns its id, rather than creating a new one.{quote}Mar 29, 2016 4:45:31 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoLaunching ami-9fe6d8f5 for template Jenkins - Deployer Slave...snip...Mar 29, 2016 4:45:32 PM FINE hudson.plugins.ec2.SlaveTemplate true - Node has capacity - can use it...snip...Mar 29, 2016 4:45:32 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoUsing existing slave: i-b0614034{quote} In the above, i-b0614034 was an existing instance. This used to work just fine. Now it refuses to create a new node. The change in behavior seems to have been introduced in relation to commit 6b286b185ba41efc33ab8558a6c43969975e6238 for issues JENKINS-23787 EC2 not spooling up stopped nodeshttps://github.com/jenkinsci/ec2-plugin/commit/6b286b185ba41efc33ab8558a6c43969975e6238#diff-f2115e33148d3db7c133fe014ad9dfddR569I blame this code and a subsequent commit that added the additonal logging of " true - Node has capacity - can use it" where it returns the idle instance id rather than provisioning a new one as I explicity asked for.Exacerbating this is extremely slow instance provisioning in StandardStrategyImpl, which I intend to log as a separate story and cross reference.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ec2-plugin] (JENKINS-33879) can't proactively scale up ec2 slaves in anticipation demand
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33879
can't proactively scale up ec2 slaves in anticipation demand
Change By:
Trevor Baker
Most of our nodes idle timeout overnight. We run a large Multi-configuration job early in the morning. We know we need a certain number of nodes online and used to be able to proactively provision instances via the /computer UI. In recent jenkins and ec2 plugin versions I observe the following:1. attempt to start a new slave of a given ami2. plugin finds there is an idle node of that particular type and returns its id, rather than creating a new one.{{ Mar 29, 2016 4:45:31 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoLaunching ami-9fe6d8f5 for template Jenkins - Deployer Slave...snip...Mar 29, 2016 4:45:32 PM FINE hudson.plugins.ec2.SlaveTemplate true - Node has capacity - can use it...snip...Mar 29, 2016 4:45:32 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoUsing existing slave: i-b0614034 }} This used to work just fine. Now it refuses to create a new node. The change in behavior seems to have been introduced in relation to commit 6b286b185ba41efc33ab8558a6c43969975e6238 for issues JENKINS-23787 EC2 not spooling up stopped nodeshttps://github.com/jenkinsci/ec2-plugin/commit/6b286b185ba41efc33ab8558a6c43969975e6238#diff-f2115e33148d3db7c133fe014ad9dfddR569I blame this code and a subsequent commit that added the additonal logging of " true - Node has capacity - can use it" where it returns the idle instance id rather than provisioning a new one as I explicity asked for.Exacerbating this is extremely slow instance provisioning in StandardStrategyImpl, which I intend to log as a separate story and cross reference.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ec2-plugin] (JENKINS-33879) can't proactively scale up ec2 slaves in anticipation demand
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33879
can't proactively scale up ec2 slaves in anticipation demand
Change By:
Trevor Baker
Most of our nodes idle timeout overnight. We run a large Multi-configuration job early in the morning. We know we need a certain number of nodes online and used to be able to proactively provision instances via the /computer UI. In recent jenkins and ec2 plugin versions I observe the following:1. attempt to start a new slave of a given ami2. plugin finds there is an idle node of that particular type and returns its id, rather than creating a new one.{{Mar 29, 2016 4:45:31 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoLaunching ami-9fe6d8f5 for template Jenkins - Deployer Slave <<< ... snip >>> ... Mar 29, 2016 4:45:32 PM FINE hudson.plugins.ec2.SlaveTemplate true - Node has capacity - can use it <<< ... snip >>> ... Mar 29, 2016 4:45:32 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfoUsing existing slave: i-b0614034 }}This used to work just fine. Now it refuses to create a new node. The change in behavior seems to have been introduced in relation to commit 6b286b185ba41efc33ab8558a6c43969975e6238 for issues JENKINS-23787 EC2 not spooling up stopped nodeshttps://github.com/jenkinsci/ec2-plugin/commit/6b286b185ba41efc33ab8558a6c43969975e6238#diff-f2115e33148d3db7c133fe014ad9dfddR569I blame this code and a subsequent commit that added the additonal logging of " true - Node has capacity - can use it" where it returns the idle instance id rather than provisioning a new one as I explicity asked for.Exacerbating this is extremely slow instance provisioning in StandardStrategyImpl, which I intend to log as a separate story and cross reference.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [ec2-plugin] (JENKINS-33879) can't proactively scale up ec2 slaves in anticipation demand
Title: Message Title
Trevor Baker created an issue
Jenkins / JENKINS-33879
can't proactively scale up ec2 slaves in anticipation demand
Issue Type:
Bug
Assignee:
Francis Upton
Components:
ec2-plugin
Created:
2016/Mar/29 5:06 PM
Environment:
ec2 plugin 1.31 jenkins 1.644
Priority:
Critical
Reporter:
Trevor Baker
Most of our nodes idle timeout overnight. We run a large Multi-configuration job early in the morning. We know we need a certain number of nodes online and used to be able to proactively provision instances via the /computer UI. In recent jenkins and ec2 plugin versions I observe the following:
1. attempt to start a new slave of a given ami 2. plugin finds there is an idle node of that particular type and returns its id, rather than creating a new one.
{{ Mar 29, 2016 4:45:31 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfo Launching ami-9fe6d8f5 for template Jenkins - Deployer Slave <<>> Mar 29, 2016 4:45:32 PM FINE hudson.plugins.ec2.SlaveTemplate true - Node has capacity - can use it <<>> Mar 29, 2016 4:45:32 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfo Using existing slave: i-b0614034}}
This used to work just fine. Now it refuses to create a new node. The change in behavior seems to have been introduced in relation
[JIRA] [clover-plugin] (JENKINS-33610) IOException with Clover 4.6 plugin
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33610
IOException with Clover 4.6 plugin
Change By:
Trevor Baker
I am seeing a new IOException since upgrading to v4.60 of the clover plugin in a job running on a linux ec2 slave{ { quote} Archiving artifactsPublishing Clover coverage report...Publishing Clover HTML report...Publishing Clover XML report...IOException when checking workspace path:remote file operation failed: /home/ec2-user/jenkins/workspace/the-job at hudson.remoting.Channel@69b58179:: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@4836f4e9Publishing Clover coverage results... {quote } }
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] [clover-plugin] (JENKINS-33610) IOException with Clover 4.6 plugin
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33610
IOException with Clover 4.6 plugin
Change By:
Trevor Baker
I am seeing a new IOException since upgrading to v4.60 of the clover plugin in a job running on a linux ec2 slave{ quote} { Archiving artifactsPublishing Clover coverage report...Publishing Clover HTML report...Publishing Clover XML report...IOException when checking workspace path:remote file operation failed: < /home/ec2-user/jenkins/workspace/ the path> -job at hudson.remoting.Channel@69b58179:: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@4836f4e9Publishing Clover coverage results... {quote } }
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] [clover-plugin] (JENKINS-33610) IOException with Clover 4.6 plugin
Title: Message Title Trevor Baker created an issue Jenkins / JENKINS-33610 IOException with Clover 4.6 plugin Issue Type: Bug Assignee: stephenconnolly Components: clover-plugin Created: 2016/Mar/17 9:05 AM Environment: clover plugin 4.6 jenkins 1.648 Priority: Minor Reporter: Trevor Baker I am seeing a new IOException since upgrading to v4.60 of the clover plugin in a job running on a linux ec2 slave ``` Archiving artifacts Publishing Clover coverage report... Publishing Clover HTML report... Publishing Clover XML report... IOException when checking workspace path:remote file operation failed: at hudson.remoting.Channel@69b58179:: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@4836f4e9 Publishing Clover coverage results... ```
[JIRA] [clover-plugin] (JENKINS-33610) IOException with Clover 4.6 plugin
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33610
IOException with Clover 4.6 plugin
Change By:
Trevor Baker
I am seeing a new IOException since upgrading to v4.60 of the clover plugin in a job running on a linux ec2 slave{quote}Archiving artifactsPublishing Clover coverage report...Publishing Clover HTML report...Publishing Clover XML report...IOException when checking workspace path:remote file operation failed: /home/ec2-user/jenkins/workspace/the-job at hudson.remoting.Channel@69b58179:: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@4836f4e9Publishing Clover coverage results...{quote} The coverage reports seem to be published back to the master correctly despite the IOException.
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] [clover-plugin] (JENKINS-33610) IOException with Clover 4.6 plugin
Title: Message Title
Trevor Baker updated an issue
Jenkins / JENKINS-33610
IOException with Clover 4.6 plugin
Change By:
Trevor Baker
I am seeing a new IOException since upgrading to v4.60 of the clover plugin in a job running on a linux ec2 slave ``` {quote} Archiving artifactsPublishing Clover coverage report...Publishing Clover HTML report...Publishing Clover XML report...IOException when checking workspace path:remote file operation failed: at hudson.remoting.Channel@69b58179:: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@4836f4e9Publishing Clover coverage results... ``` {quote}
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] [core] (JENKINS-33048) add ability to archive artifacts only on FAILURE
Title: Message Title Trevor Baker created an issue Jenkins / JENKINS-33048 add ability to archive artifacts only on FAILURE Issue Type: Improvement Assignee: Unassigned Components: core Created: 19/Feb/16 8:47 PM Priority: Major Reporter: Trevor Baker Jenkins has the ability to "Archive artifacts only if build is successful" I would like the ability to save artifacts only on FAILURE. For pull request builds I only want to save the logs on failure. I imagine there are other usecases for keeping artifacts on each build status. Perhaps the single " on success" boolean could be extended for each build status or some combination thereof. Add Comment
[JIRA] [scm-sync-configuration-plugin] (JENKINS-25786) Renaming Job Causes a poisoned commitQueue
Title: Message Title Trevor Baker reopened an issue Jenkins / JENKINS-25786 Renaming Job Causes a poisoned commitQueue Change By: Trevor Baker Resolution: Fixed Status: Resolved Reopened 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] [scm-sync-configuration-plugin] (JENKINS-25786) Renaming Job Causes a poisoned commitQueue
Title: Message Title Trevor Baker commented on JENKINS-25786 Re: Renaming Job Causes a poisoned commitQueue We're still having issues though the job to be renamed contains a space in the name, which is issue JENKINS-24686. JENKINS-24686 is marked fixed, though I am still seeing that same stacktrace on 0.0.9 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] [scm-sync-configuration-plugin] (JENKINS-16112) Provide option to either suppress commit or collapse changes into a single commit
Title: Message Title Trevor Baker commented on JENKINS-16112 Re: Provide option to either suppress commit or collapse changes into a single commit Why "won't fix"? 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] [scm-sync-configuration-plugin] (JENKINS-15128) Renaming job doesn't work with Git
Title: Message Title
Trevor Baker edited a comment on JENKINS-15128
Re: Renaming job doesn't work with Git
I see the following in checkoutConfiguration/ { { code} # git statusOn branch masterYour branch is ahead of 'origin/master' by 10 commits. (use "git push" to publish your local commits)Changes to be committed: (use "git reset HEAD ..." to unstage) renamed:jobs/SQS Mertics/config.xml -> jobs/SQS Metrics/config.xmlChanges not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: config.xml {code } } I don't know which config.xml failed to add. I see the following repeating in the logs{ { code} Dec 17, 2015 1:37:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy[deleteHierarchy] Problem during remove : The git command failed.Dec 17, 2015 1:38:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy[deleteHierarchy] Problem during remove : The git command failed.Dec 17, 2015 1:38:01 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy[deleteHierarchy] Problem during remove : The git command failed. {code } } I manually fixed by:{ { code} ssh jenkinssudo su jenkins -s /bin/bashcd ~/scm-sync-configuration/checkoutConfiguration/git status # see untracked filesgit add -agit commit -a -m "manual commit due to failed rename"git push origin master# all good {code } } Then restarting jenkins.
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] [scm-sync-configuration-plugin] (JENKINS-24686) scm-sync-configuration fails if job name contains whitespace
Title: Message Title Trevor Baker reopened an issue I am still seeing this issue with 0.0.9 Dec 17, 2015 1:52:57 PM FINE hudson.plugins.scm_sync_configuration.SCMManipulator Checking in SCM files ... Dec 17, 2015 1:52:57 PM FINER org.apache.maven.scm.manager.ScmManager checkIn THROW org.apache.maven.scm.ScmException: Exception while executing SCM command. at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:63) at org.apache.maven.scm.provider.git.AbstractGitScmProvider.executeCommand(AbstractGitScmProvider.java:291) at org.apache.maven.scm.provider.git.AbstractGitScmProvider.checkin(AbstractGitScmProvider.java:217) at org.apache.maven.scm.provider.AbstractScmProvider.checkIn(AbstractScmProvider.java:415) at org.apache.maven.scm.provider.AbstractScmProvider.checkIn(AbstractScmProvider.java:397) at org.apache.maven.scm.manager.AbstractScmManager.checkIn(AbstractScmManager.java:423) at hudson.plugins.scm_sync_configuration.SCMManipulator.checkinFiles(SCMManipulator.java:241) at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness.processCommitsQueue(ScmSyncConfigurationBusiness.java:223) at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness.access$000(ScmSyncConfigurationBusiness.java:32) at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness$1.call(ScmSyncConfigurationBusiness.java:148) at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness$1.call(ScmSyncConfigurationBusiness.java:145) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.maven.scm.ScmException: Error while executing command. at org.apache.maven.scm.provider.git.gitexe.command.GitCommandLineUtils.execute(GitCommandLineUtils.java:122) at org.apache.maven.scm.provider.git.gitexe.command.checkin.GitCheckInCommand.executeCheckInCommand(GitCheckInCommand.java:129) at org.apache.maven.scm.command.checkin.AbstractCheckInCommand.executeCommand(AbstractCheckInCommand.java:54) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) ... 14 more Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error inside systemOut parser at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:188) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:107) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:74) at org.apache.maven.scm.provider.git.gitexe.command.GitCommandLineUtils.execute(GitCommandLineUtils.java:118) ... 17 more Caused by: java.lang.IllegalArgumentException: Illegal character in path at index 0: "jobs/SQS%20Metrics/config.xml" at java.net.URI.create(URI.java:852) at org.apache.maven.scm.provider.git.gitexe.command.status.GitStatusConsumer.resolveURI(GitStatusConsumer.java:251) at org.apache.maven.scm.provider.git.gitexe.command.status.GitStatusConsumer.resolvePath(GitStatusConsumer.java:232) at org.apache.maven.scm.provider.git.gitexe.command.status.GitStatusConsumer.consumeLine(GitStatusConsumer.java:138) at org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:190) at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:135) Caused by: java.net.URISyntaxException: Illegal character in path at index 0: "jobs/SQS%20Metrics/config.xml" at java.net.URI$Parser.fail(URI.java:2848) at java.net.URI$Parser.checkChars(URI.java:3021) at java.net.URI$Parser.parseHierarchical(URI.java:3105) at java.net.URI$Parser.parse(URI.java:3063) at java.net.URI.(URI.java:588) at java.net.URI.create(URI.java:850) ... 5 more
[JIRA] [scm-sync-configuration-plugin] (JENKINS-15128) Renaming job doesn't work with Git
Title: Message Title Trevor Baker reopened an issue Please see my earlier comments; this is still not working for us. Jenkins / JENKINS-15128 Renaming job doesn't work with Git Change By: Trevor Baker Resolution: Fixed Status: Closed Reopened 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] [scm-sync-configuration-plugin] (JENKINS-15128) Renaming job doesn't work with Git
Title: Message Title
Trevor Baker edited a comment on JENKINS-15128
Re: Renaming job doesn't work with Git
I see the following in checkoutConfiguration/{ quote} { # git statusOn branch masterYour branch is ahead of 'origin/master' by 10 commits. (use "git push" to publish your local commits)Changes to be committed: (use "git reset HEAD ..." to unstage) renamed:jobs/SQS Mertics/config.xml -> jobs/SQS Metrics/config.xmlChanges not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: config.xml {quote } } I don't know which config.xml failed to add. I see the following repeating in the logs{ quote} { Dec 17, 2015 1:37:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy[deleteHierarchy] Problem during remove : The git command failed.Dec 17, 2015 1:38:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy[deleteHierarchy] Problem during remove : The git command failed.Dec 17, 2015 1:38:01 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy[deleteHierarchy] Problem during remove : The git command failed. {quote } } I manually fixed by:{ quote} { ssh jenkinssudo su jenkins -s /bin/bashcd ~/scm-sync-configuration/checkoutConfiguration/git status # see untracked filesgit add -agit commit -a -m "manual commit due to failed rename"git push origin master# all good {quote } } Then restarting jenkins.
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] [scm-sync-configuration-plugin] (JENKINS-15128) Renaming job doesn't work with Git
Title: Message Title Trevor Baker commented on JENKINS-15128 Re: Renaming job doesn't work with Git I see the following in checkoutConfiguration/ git status On branch master Your branch is ahead of 'origin/master' by 10 commits. (use "git push" to publish your local commits) Changes to be committed: (use "git reset HEAD ..." to unstage) renamed: jobs/SQS Mertics/config.xml -> jobs/SQS Metrics/config.xml Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout – ..." to discard changes in working directory) modified: config.xml I don't know which config.xml failed to add. I see the following repeating in the logs Dec 17, 2015 1:37:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy [deleteHierarchy] Problem during remove : The git command failed. Dec 17, 2015 1:38:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy [deleteHierarchy] Problem during remove : The git command failed. Dec 17, 2015 1:38:01 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy [deleteHierarchy] Problem during remove : The git command failed. I manually fixed by: ssh jenkins sudo su jenkins -s /bin/bash cd ~/scm-sync-configuration/checkoutConfiguration/ git status # see untracked files git add -a git commit -a -m "manual commit due to failed rename" git push origin master all good Then restarting jenkins. Add Comment
[JIRA] [scm-sync-configuration-plugin] (JENKINS-15128) Renaming job doesn't work with Git
Title: Message Title Trevor Baker commented on JENKINS-15128 Re: Renaming job doesn't work with Git Same as issue JENKINS-25786 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] [scm-sync-configuration-plugin] (JENKINS-15128) Renaming job doesn't work with Git
Title: Message Title Trevor Baker commented on JENKINS-15128 Re: Renaming job doesn't work with Git I tried a rename with 0.0.9 and it failed. Dec 17, 2015 1:16:56 PM WARNING hudson.plugins.scm_sync_configuration.SCMManipulator addFile [addFile] Error while adding file : Exception while executing SCM command. Dec 17, 2015 1:16:56 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator checkinFiles [checkinFiles] Error while checkin : Exception while executing SCM command. Dec 17, 2015 1:16:56 PM SEVERE hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness processCommitsQueue Error while processing commit queue : Error while checking in file to scm repository Dec 17, 2015 1:17:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy [deleteHierarchy] Problem during remove : The git command failed. 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] [ec2-plugin] (JENKINS-23972) EC2: support new "General Purpose" EBS storage
Title: Message Title Trevor Baker commented on JENKINS-23972 Re: EC2: support new "General Purpose" EBS storage This syntax works for me: Block device mapping: /dev/xvda=:100:true:gp2 I think the bug can be closed. 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] [github-pullrequest-plugin] (JENKINS-31707) manually trigger builds using ghprb don't add comments to the pull request
Title: Message Title Trevor Baker created an issue Jenkins / JENKINS-31707 manually trigger builds using ghprb don't add comments to the pull request Issue Type: Bug Assignee: Kanstantsin Shautsou Components: github-pullrequest-plugin Created: 23/Nov/15 1:59 PM Environment: jenkins 1.620 ghprb 1.29.4 Priority: Trivial Reporter: Trevor Baker When builds using the github pull request plugin are triggered manually by specifying the sha1 as a parameter, build results are not added to the pull request as comments. Is this expected for manually triggered builds? Add Comment
[JIRA] [scm-sync-configuration-plugin] (JENKINS-25786) Renaming Job Causes a poisoned commitQueue
Title: Message Title
Trevor Baker edited a comment on JENKINS-25786
Re: Renaming Job Causes a poisoned commitQueue
When this happens I see the old named job's config.xml committed properly though the add of the newly named file doesn't happen. You end with with the renamed file and path untracked in scm-sync-configuration/checkoutConfigurationThis is how I fix it: ``` {code:java} ssh jenkinssudo su jenkins -s /bin/bashcd ~/scm-sync-configuration/checkoutConfiguration/git status # see untracked filesgit add -agit commit -a -m “fix this busted stuff”git push origin master# all good ``` {code} Then restart Jenkins.
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] [scm-sync-configuration-plugin] (JENKINS-25786) Renaming Job Causes a poisoned commitQueue
Title: Message Title Trevor Baker commented on JENKINS-25786 Re: Renaming Job Causes a poisoned commitQueue When this happens I see the old named job's config.xml committed properly though the add of the newly named file doesn't happen. You end with with the renamed file and path untracked in scm-sync-configuration/checkoutConfiguration This is how I fix it: ``` ssh jenkins sudo su jenkins -s /bin/bash cd ~/scm-sync-configuration/checkoutConfiguration/ git status # see untracked files git add -a git commit -a -m “fix this busted stuff” git push origin master all good ``` Then restart Jenkins. 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] [ec2-plugin] (JENKINS-27601) instance caps incorrectly calculated
Title: Message Title Trevor Baker commented on JENKINS-27601 Re: instance caps incorrectly calculated It would be great to have a new release cut so we can start using this! Thanks! 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] [ec2-plugin] (JENKINS-28268) need ability to update ami in ec2 plugin config programmatically
Title: Message Title Trevor Baker updated an issue Jenkins / JENKINS-28268 need ability to update ami in ec2 plugin config programmatically Change By: Trevor Baker Summary: needabilitytoupdateamiinec2pluginconfig programatically programmatically 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] [ec2-plugin] (JENKINS-28268) need ability to update ami in ec2 plugin config programatically
Title: Message Title Trevor Baker created an issue Jenkins / JENKINS-28268 need ability to update ami in ec2 plugin config programatically Issue Type: New Feature Assignee: Francis Upton Components: ec2-plugin Created: 06/May/15 3:56 PM Priority: Major Reporter: Trevor Baker We use packer to create a base ami from a jenkins job. That ami is tagged and used as the base image for all further amis within our account. It is also referenced in the ec2 plugin as the ami id for launched nodes. We would like to programmatically update the ec2 plugin config from the job that creates the base ami. Once we have the ami id, we should be able to call some api, either via groovy or rest to update the ami referenced in the plugin config. Is there a way via the groovy post-build plugin to pass an ami id to the plugin configuration and persist it? Add Comment
[JIRA] [ec2-plugin] (JENKINS-23972) EC2: support new General Purpose EBS storage
Trevor Baker commented on JENKINS-23972 EC2: support new General Purpose EBS storage I'd really like to see this too! I tried explicitly setting the type to gp2 in the "Block device mapping" setting for the root device but it had no effect (type was still Standard) /dev/xvda=:::gp2:: 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] [ec2-plugin] (JENKINS-27601) instance caps incorrectly calculated
Trevor Baker created JENKINS-27601 instance caps incorrectly calculated Issue Type: Bug Assignee: Francis Upton Components: ec2-plugin Created: 25/Mar/15 8:19 PM Description: Instance counts towards the cap feature are incorrectly counted when you use the same AMI for multiple jenkins slave types it with differing ec2 instance types. The count is a sum of all the instances provisioned by the plugin rather than the number provisioned per discrete slave configuration. https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/EC2Cloud.java#L241 If the ami id and the tag jenkins_slave_type match, it is counted toward the cap. Scenario: slave description: small slave ami: ami-12345 instance type: t1.small cap: 5 slave description: big slave ami: ami-12345 instance type: c3.xlarge cap: 2 If there are five "small slaves" running it won't provision any "big slaves", reports the following: AMI Instance cap of 2 reached for ami ami-12345, not provisioning. Environment: ec2-plugin 1.26 jenkins 1.605 Project: Jenkins Priority: Major Reporter: Trevor Baker 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] [ghprb-plugin] (JENKINS-27545) ghprbPullLink incorrectly links to https://api.github.com/repos/.....
Trevor Baker created JENKINS-27545 ghprbPullLink incorrectly links to https://api.github.com/repos/. Issue Type: Bug Assignee: Honza Brázdil Components: ghprb-plugin Created: 23/Mar/15 1:43 PM Description: The ghprbPullLink is incorrectly linking to api.github.com is some circumstances. Incorrect: https://api.github.com/repos/org-here/repo-here/pulls/1234 The prior behavior which is correct for our usage: https://github.com/org-here/repo-here/pull/1234 Different builds show either result depending on how it was triggered. It seems when the build starts via a "retest this please" regex match we get the incorrect url. When the build is triggered by an initial pull request it is correct and can be resolved. Environment: ghprb 1.16-8 Jenkins ver. 1.605 Project: Jenkins Priority: Minor Reporter: Trevor Baker 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] [ec2-plugin] (JENKINS-26716) Jobs throttled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary
Trevor Baker updated JENKINS-26716 Jobs throttled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary Change By: Trevor Baker (25/Feb/15 4:54 PM) Description: Whenconcurrentjobsarethrottledacrosscategoriesnewec2provisionedslavesarenotlaunchedwhentheyarerequired.Theec2pluginshould not detectthateventhoughtheremaybeexecutorsavailablethattheycannotrunthejob(s)duetoconcurrentthrottling.Thesetwopluginsshouldinteropasexpected. 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] [scm-sync-configuration-plugin] (JENKINS-24993) scm-sync-configration plugin keeps on adding directory structure scm-sync-configuration/checkoutConfiguration
Trevor Baker commented on JENKINS-24993 scm-sync-configration plugin keeps on adding directory structure scm-sync-configuration/checkoutConfiguration I checked in a .gitignore with /scm-sync-configuration, but this shouldn't be necessary. 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] [scm-sync-configuration-plugin] (JENKINS-24993) scm-sync-configration plugin keeps on adding directory structure scm-sync-configuration/checkoutConfiguration
Trevor Baker commented on JENKINS-24993 scm-sync-configration plugin keeps on adding directory structure scm-sync-configuration/checkoutConfiguration This is a serious issue! There is a recursion problem and it keeps adding scm-sync-configuration/checkoutConfiguration/scm-sync-configuration/checkoutConfiguration/** this is repeating apparently unbounded. The scm-sync-configuration should not be a part of the repo at all. 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] [scm-sync-configuration-plugin] (JENKINS-24993) scm-sync-configration plugin keeps on adding directory structure scm-sync-configuration/checkoutConfiguration
Trevor Baker edited a comment on JENKINS-24993 scm-sync-configration plugin keeps on adding directory structure scm-sync-configuration/checkoutConfiguration This is a serious issue! There is a recursion problem and it keeps adding scm-sync-configuration/checkoutConfiguration/scm-sync-configuration/checkoutConfiguration/** this is repeating apparently unbounded. The scm-sync-configuration dir should not be added to the repo at all. 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] [ec2-plugin] (JENKINS-26716) Jobs thottled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary
Trevor Baker edited a comment on JENKINS-26716 Jobs thottled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary Very similar to JENKINS-25963. 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] [ec2-plugin] (JENKINS-26716) Jobs throttled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary
Trevor Baker updated JENKINS-26716 Jobs throttled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary Change By: Trevor Baker (30/Jan/15 6:11 PM) Summary: Jobs thottled throttled viatheThrottleConcurrentBuildspluginfailtolaunchnewec2provisionedslaveswhennecessary 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] [ec2-plugin] (JENKINS-26716) Jobs thottled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves
Trevor Baker created JENKINS-26716 Jobs thottled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves Issue Type: Bug Assignee: Dominik Bartholdi Components: ec2-plugin, nodelabelparameter-plugin Created: 30/Jan/15 6:00 PM Description: The EC2 plugin works great for dynamically provisioning EC2 slaves (as needed) when their label is specified under "Restrict where this project can be run," but it doesn't do anything if that label is passed in using a NodeLabel parameter. Note that this only seems to affect the EC2 provisioning step; jobs set to run on a slave via NodeLabel parameter will happily run on provisioned-by-EC2-plugin slaves that are already around. Project: Jenkins Priority: Major Reporter: Trevor Baker 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] [ec2-plugin] (JENKINS-26716) Jobs thottled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary
Trevor Baker updated JENKINS-26716 Jobs thottled via the Throttle Concurrent Builds plugin fail to launch new ec2 provisioned slaves when necessary Change By: Trevor Baker (30/Jan/15 6:03 PM) Summary: JobsthottledviatheThrottleConcurrentBuildspluginfailtolaunchnewec2provisionedslaves whennecessary Description: TheEC2pluginworksgreatfordynamicallyprovisioningEC2 Whenconcurrentjobsarethrottledacrosscategoriesnewec2provisioned slaves (asneeded) arenotlaunched when theirlabelisspecifiedunderRestrictwherethisprojectcanberun,butitdoesntdoanythingifthatlabelispassedinusingaNodeLabelparameter theyarerequired . Note Theec2pluginshouldnotdetect that thisonlyseemstoaffect eventhoughtheremaybeexecutorsavailablethattheycannotrun the EC2provisioningstep;jobsset job(s)due to runonaslaveviaNodeLabelparameterwillhappilyrunonprovisioned-by-EC2-pluginslavesthatarealreadyaround concurrentthrottling . Thesetwopluginsshouldinteropasexpected. Assignee: DominikBartholdi Component/s: throttle-concurrent-builds-plugin Component/s: nodelabelparameter-plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-25963) Jobs tied to EC2 plugin-provisioned slaves via NodeLabel parameter don't provision new slaves
Trevor Baker commented on JENKINS-25963 Jobs tied to EC2 plugin-provisioned slaves via NodeLabel parameter dont provision new slaves I see the same problem with the "Throttle Concurrent Builds" plugin when you throttle across jobs with a category. https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-26414) Add support for new C4 instance types
Trevor Baker created JENKINS-26414 Add support for new C4 instance types Issue Type: Bug Assignee: Francis Upton Components: ec2-plugin Created: 13/Jan/15 1:30 PM Description: Please add support for the new C4 instance types. https://aws.amazon.com/blogs/aws/now-available-new-c4-instances/ Project: Jenkins Priority: Major Reporter: Trevor Baker 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] [core] (JENKINS-14332) Repeated channel/timeout errors from Jenkins slave
Trevor Baker updated JENKINS-14332 Repeated channel/timeout errors from Jenkins slave The instance I run jenkins on was a 2013.09 version that was upgraded to 2014.03.x via yum updates. I presume you could add the 2013.09 yum repo into /etc/yum.repos.d/ and see the 3.4.x kernels. From experience, 3.4.83-70.111 works with everything else from 2014.03.2 at the latest revisions. I've attached a kernel param dump. Change By: Trevor Baker (18/Sep/14 12:20 PM) Attachment: 3.4.83-70.111.amzn1.x86_64_kernel_params.txt 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] [core] (JENKINS-14332) Repeated channel/timeout errors from Jenkins slave
Trevor Baker commented on JENKINS-14332 Repeated channel/timeout errors from Jenkins slave This happens consistently when the jenkins master is running amazon linux kernel 3.10.x. If you downgrade the kernel to 3.4.x on the master it goes away. It does not seem to matter which kernel the slave runs. Every time I forget about this and "yum update" the kernel it takes some head scratching before I remember to lock the master's kernel at 3.4.x in /etc/grub.conf 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] [ghprb] (JENKINS-22504) Mark Unstable build in github as value does not display correctly in UI, gets overwritten with subsequent saves
Trevor Baker created JENKINS-22504 Mark Unstable build in github as value does not display correctly in UI, gets overwritten with subsequent saves Issue Type: Bug Assignee: Honza Brázdil Components: ghprb Created: 04/Apr/14 1:40 PM Description: The "configure system" page containing the master config for the GHPRB has the setting "Mark Unstable build in github as" with a default of "Failure." Attempting to save with any other appears to persist to the xml file, but subsequent saves to the config replace it with the default "Failure" value and your intention is lost. Expect the specified value to persist and the UI to select the correct value based on user's intention. Environment: ghprb 1.11.2 jenkins 1.557 git client 1.7 github plugin 1.8 git plugin 2.1 Project: Jenkins Priority: Major Reporter: Trevor Baker 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] [url-change-trigger] (JENKINS-22258) url content not saved across cron inactive times
Trevor Baker resolved JENKINS-22258 as Not A Defect url content not saved across cron inactive times This seems to be working now. I'll reopen later if new info presents. Change By: Trevor Baker (27/Mar/14 2:11 PM) Status: Open Resolved Resolution: NotADefect 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] [envinject] (JENKINS-22372) envinject script content fails to run on slave unless another plugin in job provides buildWrapper in config
Trevor Baker created JENKINS-22372 envinject script content fails to run on slave unless another plugin in job provides buildWrapper in config Issue Type: Bug Assignee: Gregory Boissinot Attachments: thisFAILS.xml, thisFAILS_log.txt, thisPASSES.xml, thisPASSES_log.txt Components: envinject Created: 26/Mar/14 8:34 PM Description: Trivial EnvInject "script contents" throw java.io.IOException: Cannot run program "/bin/sh" (in directory "/home/slavehome/jenkins") It seems like the script is attempting to run on the master using the slaves jenkinsHome dir. The script contents run correctly if I add a build tool plugin that provides a tool to the environment. I've attached a job config that fails and its log, plus a working job and log where I added a build tool. The build tool installation apparently delays the "script content" execution until after the build tool install, which ensures the CWD is actually on the slave and not master when the "script content" is run. Environment: Jenkins 1.556 envinject 1.89 tomcat 7.x Project: Jenkins Priority: Major Reporter: Trevor Baker 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] [url-change-trigger] (JENKINS-22258) url content not saved across cron inactive times
Trevor Baker commented on JENKINS-22258 url content not saved across cron inactive times Is there a way to print out the content it is saving on the poll? The job worked as expected this AM, so need a little more info to continue debugging this. 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] [git] (JENKINS-12729) Add configurable username/password for submodules that require authentication
Trevor Baker commented on JENKINS-12729 Add configurable username/password for submodules that require authentication We have submodules with different ssh deploy keys that the top level repo. We get around the limitation by specifying the key to use in ssh/config for the submodule "Host" though in-job configuration would be preferable. 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] [url-change-trigger] (JENKINS-22258) url content not saved across cron inactive times
Trevor Baker created JENKINS-22258 url content not saved across cron inactive times Issue Type: Bug Assignee: dfabulich Components: url-change-trigger Created: 19/Mar/14 1:14 PM Description: I have a url trigger with a text context and default regex of ".*" The cron schedule is "0 08-16 * * 1-5", which is to say business hours during business days. Each morning the trigger runs at 8am to check the content and seems to have forgotten the state from the last invocation at 4pm the previous day. It prints: Inspecting TXT content for URL https://jenkins/job/myjob/lastSuccessfulBuild/buildNumber Polling started on Mar 19, 2014 8:01:19 AM Polling for the job myjob Looking nodes where the poll can be run. Looking for a node to the restricted label master. Restrict on master label. Polling on master. Polling on master. Using Basic Authentication with the user 'user' Invoking the url: https://jenkins/job/myjob/lastSuccessfulBuild/buildNumber Inspecting the content Capturing URL context. Waiting next schedule to check a change. Polling complete. Took 0.66 sec. No changes. This effectively means the earliest the job can be triggered is the second cron trigger of the day. I would expect that the URL Trigger plugin would remember the value from the previous day and calculate changes from that. Jenkins has not been restarted overnight. Environment: url-trigger 0.37 Jenkins 1.554 Tomcat 7 Linux Project: Jenkins Priority: Major Reporter: Trevor Baker 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.
