[JIRA] [build-pipeline] (JENKINS-18759) Build Pipeline Plugin no longer maintaining parameters on Retry
Brian Freed updated JENKINS-18759 Build Pipeline Plugin no longer maintaining parameters on Retry Change By: Brian Freed (15/Jul/13 5:13 PM) Affects Version/s: current This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [build-pipeline] (JENKINS-18759) Build Pipeline Plugin no longer maintaining parameters on Retry
Brian Freed created JENKINS-18759 Build Pipeline Plugin no longer maintaining parameters on Retry Issue Type: Bug Assignee: Unassigned Components: build-pipeline Created: 15/Jul/13 5:11 PM Description: When using the Build Pipeline plugin up to 1.3.3 and retrying a job that had failed, the parameters that the job was originally triggered with would be applied again on the retry With version 1.3.4.1 and 1.3.5, when doing a retry, the parameters do not carry over This is a critical problem as we need this retry functionality in our pipeline Project: Jenkins Priority: Critical Reporter: Brian Freed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16152) Jobs failing to load due to NPE
Brian Freed created JENKINS-16152 Jobs failing to load due to NPE Issue Type: Bug Assignee: Unassigned Attachments: config.xml Components: core Created: 17/Dec/12 6:11 PM Description: When I upgrade to the latest version of Jenkins, many of my jobs disappear. The error in the logs is only a NPE and isn't that helpful Dec 17, 2012 9:52:03 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Loading job processor-build java.lang.NullPointerException I am attaching the config.xml for this job Project: Jenkins Priority: Major Reporter: Brian Freed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Brian Freed commented on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 Unfortunately my jobs are still disappearing with 1.489 with the CVS plugin disabled This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Brian Freed updated JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 Change By: Brian Freed (05/Nov/12 9:49 PM) Priority: Major Critical This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Brian Freed commented on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 Can I get some traction on this issue? I am still not able to upgrade to anything above 1.484 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Brian Freed updated JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 Change By: Brian Freed (17/Oct/12 5:10 PM) Component/s: core This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Brian Freed updated JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 Change By: Brian Freed (15/Oct/12 11:35 PM) Description: When we upgraded our Jenkins to 1.485, some of our jobs did not show up on start-up even though their configuration files were still present. When we rolled Jenkins back to 1.484, the jobs reappeared.This problem continued with 1.486One common theme between the jobs that didn't show up is they use the parameterized-trigger plugin, which we are using 1 2 . 24 14 . We have not upgraded this plugin because it removes the ability to specify triggering with multiple properties filesIn the Jenkins error logs, I see this NPE:Oct 15, 2012 3:34:56 PM jenkins.InitReactorRunner$1 onAttainedINFO: Augmented all extensionsjava.lang.NullPointerException at hudson.model.Run.getRootDir(Run.java:900) at org.jenkinsci.lib.envinject.EnvInjectAction.readResolve(EnvInjectAction.java:86) at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callReadResolve(SerializationMethodInvoker.java:46) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:222) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:332) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:274) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:221) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137) at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33) at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:926) at hudson.util.XStream2.unmarshal(XStream2.java:103) at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:912) at hudson.XmlFile.unmarshal(XmlFile.java:160) at hudson.model.Run.reload(Run.java:291) at hudson.model.Run.(Run.java:280) at hudson.model.AbstractBuild.(AbstractBuild.java:182) at hudson.model.Build.(Build.java:103) at hudson.model.FreeStyleBuild.(FreeStyleBuild.java:41) at sun.reflect.GeneratedConstructorAccessor49.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at hudson.model.AbstractProject.loadBuild(AbstractProject.java:1061) at hudson.model.AbstractProject$1.create(AbstractProject.java:275) at hudson.model.AbstractProject$1.create(AbstractProject.java:273) at hudson.model.RunMap.retrieve(RunMap.java:220) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Brian Freed created JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 Issue Type: Bug Affects Versions: current Assignee: huybrechts Components: parameterized-trigger Created: 15/Oct/12 10:59 PM Description: When we upgraded our Jenkins to 1.485, some of our jobs did not show up on start-up even though their configuration files were still present. When we rolled Jenkins back to 1.484, the jobs reappeared. This problem continued with 1.486 One common theme between the jobs that didn't show up is they use the parameterized-trigger plugin, which we are using 1.24. We have not upgraded this plugin because it removes the ability to specify triggering with multiple properties files In the Jenkins error logs, I see this NPE: Oct 15, 2012 3:34:56 PM jenkins.InitReactorRunner$1 onAttained INFO: Augmented all extensions java.lang.NullPointerException at hudson.model.Run.getRootDir(Run.java:900) at org.jenkinsci.lib.envinject.EnvInjectAction.readResolve(EnvInjectAction.java:86) at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callReadResolve(SerializationMethodInvoker.java:46) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:222) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:332) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:274) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:221) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137) at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33) at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:926) at hudson.util.XStream2.unmarshal(XStream2.java:103) at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:912) at hudson.XmlFile.unmarshal(XmlFile.java:160) at hudson.model.Run.reload(Run.java:291) at hudson.model.Run.(Run.java:280) at hudson.model.AbstractBuild.(AbstractBuild.java:182) at hudson.model.Build.(Build.java:103) at hudson.model.FreeStyleBuild.(FreeStyleBuild.java:41) at sun.reflect.GeneratedConstructorAccessor49.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at hudson.model
[JIRA] (JENKINS-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159353#comment-159353
]
Brian Freed commented on JENKINS-12837:
---
Thanks for getting this fixed so quickly.
Do you have a timeline for when this change will be released for us to download?
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159319#comment-159319
]
Brian Freed commented on JENKINS-12837:
---
I have been able to verify that the Perforce Plugin can use global environment
variables such as PATH, but is unable to find the local environment variables
that were injected.
Can the Perforce Plugin be updated to be able to use these local environment
variables for property substitution?
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Freed updated JENKINS-12837:
--
Priority: Blocker (was: Minor)
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
Brian Freed created JENKINS-12837:
-
Summary: Using a variable injected during "Prepare envrionment"
stage doesn't work for Perforce Label during SCM
Key: JENKINS-12837
URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
Project: Jenkins
Issue Type: Bug
Components: envinject, perforce
Affects Versions: current
Environment: Windows
Reporter: Brian Freed
Assignee: gbois
Priority: Minor
I am trying to inject a variable from a file which will tell a Jenkins test job
what perforce label it should use during SCM
My file is named change.properties and looks like this:
p4.changelist=386494
In the test job, I have clicked the 'Prepare an environment for the job'
section and then added the file location in the 'Properties File Path' box
In the Perforce section, I am setting the perforce Label to be
GPTCDTEST${p4.changelist}
However when I run the job, I get this error:
Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
which makes me think that it wasn't able to pick up the p4.changelist variable
I injected.
I have been able to do this by having an upstream job trigger the test job with
parameters from the file, and this works fine, but I want to be able to have
the job run on it own without requiring the upstream job.
I also tried just inserting this variable in the 'Properties Content' section,
but Perforce still can't find it:
[EnvInject] - Injecting as environment variables the properties content
p4.changelist=322332
[EnvInject] - Variables injected successfully.
...
com.tek42.perforce.PerforceException: Errors encountered while force syncing:
error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
Is there an issue with linking up a variable from the Prepare Environment
section to the perforce SCM section?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
