[JIRA] (JENKINS-8213) links generated for WebSVN don't work with 2.3.1
[
https://issues.jenkins-ci.org/browse/JENKINS-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158635#comment-158635
]
andreasmandel commented on JENKINS-8213:
The problem is that the WebSVN team seems to change the API quite frequently
(at least they change it).
Actually I created the plugin because such a change broke the original WebSVN
support that comes with the SVN plugin. At that time I tried to query the
WebSVN team for some support and a documentation of the API - with no success.
Unfortunately this can not be easily fixed without risking that the the links
are broken for the elder 2.x versions of WebSVN. Since there is no documented
API, to make the plugin full functional, a whole set of different version
WebSVN installations is required. Unfortunately I do not have the time to set
this up and maintain it.
> links generated for WebSVN don't work with 2.3.1
>
>
> Key: JENKINS-8213
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8213
> Project: Jenkins
> Issue Type: Bug
> Components: websvn2
>Affects Versions: current
>Reporter: anshnd
>Assignee: andreasmandel
>Priority: Minor
> Fix For: current
>
>
> The generated links for the commits are wrong. Ex. it generates
> http://wsvn.example.com/wsvn/repos/?rev=7071&sc=1 instead of
> http://wsvn.example.com/wsvn/atlas/?rev=7071&sc=1&option=revision (notice the
> missing {{&op=revision}}).
> The links generated for diff are ok.
> The problem happens with the
> http://wiki.hudson-ci.org/display/HUDSON/WebSVN2+Plugin in version 0.9 which
> seems to have had no activity in the past 12+ months.
--
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-753) Should perform clean checkout if update fails
[ https://issues.jenkins-ci.org/browse/JENKINS-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158638#comment-158638 ] SCM/JIRA link daemon commented on JENKINS-753: -- Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/CVSSCM.java src/main/resources/hudson/scm/CVSSCM/config.jelly http://jenkins-ci.org/commit/cvs-plugin/794afd76127191e6a5174647d0c2620f0aadd915 Log: [FIXED JENKINS-753] Allows performing a clean checkout if update fails [FIXED JENKINS-12595] CVS gets passed the module name so creates lock files in the correct directory on the remote server [FIXED JENKINS-12581] CVS plugin now forces a module name in the udpate command to prevent an attempt to checkout all remote modules > Should perform clean checkout if update fails > - > > Key: JENKINS-753 > URL: https://issues.jenkins-ci.org/browse/JENKINS-753 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: jglick >Assignee: Michael Clarke > > In a project configured to use CVS update mode, and doing incremental builds > (or > faulty clean steps), it can happen that CVS updates produce conflicts. For > example, on occasion what was previously a .cvsignore'd build product becomes > checked into the repository - say, ANTLR-generated files if you no longer wish > to depend on antlr.jar for regular builds. In such cases, "cvs up" fails and > the > build breaks. There is no way to correct the build from the admin GUI, either; > you need to log in to the server and delete the workspace. > If a project is configured to use update mode, and the update command fails, I > think Hudson should automatically attempt a clean checkout, in the interests > of > robustness and zero maintenance. -- 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-753) Should perform clean checkout if update fails
[ https://issues.jenkins-ci.org/browse/JENKINS-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158639#comment-158639 ] SCM/JIRA link daemon commented on JENKINS-753: -- Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/CVSSCM.java http://jenkins-ci.org/commit/cvs-plugin/1ccef67edc26350d544b2ae5ebfebed5ed91ac8c Log: [JENKINS-12599] Changing how password is set in connections so as not to modify port numbers (as per comments #2 and #3) [JENKINS-753] Stop processing if update fails and we're not going to do a workspace clean Compare: https://github.com/jenkinsci/cvs-plugin/compare/39da798...1ccef67 > Should perform clean checkout if update fails > - > > Key: JENKINS-753 > URL: https://issues.jenkins-ci.org/browse/JENKINS-753 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: jglick >Assignee: Michael Clarke > > In a project configured to use CVS update mode, and doing incremental builds > (or > faulty clean steps), it can happen that CVS updates produce conflicts. For > example, on occasion what was previously a .cvsignore'd build product becomes > checked into the repository - say, ANTLR-generated files if you no longer wish > to depend on antlr.jar for regular builds. In such cases, "cvs up" fails and > the > build breaks. There is no way to correct the build from the admin GUI, either; > you need to log in to the server and delete the workspace. > If a project is configured to use update mode, and the update command fails, I > think Hudson should automatically attempt a clean checkout, in the interests > of > robustness and zero maintenance. -- 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-12595) Anonymous cvs update doesn't work anymore
[ https://issues.jenkins-ci.org/browse/JENKINS-12595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158637#comment-158637 ] SCM/JIRA link daemon commented on JENKINS-12595: Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/CVSSCM.java src/main/resources/hudson/scm/CVSSCM/config.jelly http://jenkins-ci.org/commit/cvs-plugin/794afd76127191e6a5174647d0c2620f0aadd915 Log: [FIXED JENKINS-753] Allows performing a clean checkout if update fails [FIXED JENKINS-12595] CVS gets passed the module name so creates lock files in the correct directory on the remote server [FIXED JENKINS-12581] CVS plugin now forces a module name in the udpate command to prevent an attempt to checkout all remote modules > Anonymous cvs update doesn't work anymore > - > > Key: JENKINS-12595 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12595 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: CentOS 5.7, cvs-1.11.22-9.el5, cvs plugin version 2.0 >Reporter: Simon Matter >Assignee: Michael Clarke >Priority: Blocker > > Since the update to the java cvs plugin, I can't do anonymous readonly cvs > update anymore. It fails with this message: > cvs update: Updating . > cvs update: failed to create lock directory for `/var/cvs' > (/var/cvs/#cvs.lock): Permission denied > cvs update: failed to obtain dir lock in repository `/var/cvs' > cvs [update aborted]: read lock failed - giving up > Note: Initial checkout after cleaning workspace works, only updates don't > work. > The is also another problem which may be a side effect: I see hanging around > cvs server processes which only terminate after jenkins is shut down. > We are running cvs pserver from xinetd like this: cvs -f > --allow-root=/var/cvs pserver > CVSROOT is ":pserver:anonymous@cvs:/var/cvs" > Anonymous readonly updates have always worked with jenkins, as well es they > do with Eclipse or Netbeans. > Did I miss something? > Regards, > Simon -- 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-12581) CVS: First CVS Update after Checkout reads whole CVS-Repository
[ https://issues.jenkins-ci.org/browse/JENKINS-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158636#comment-158636 ] SCM/JIRA link daemon commented on JENKINS-12581: Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/CVSSCM.java src/main/resources/hudson/scm/CVSSCM/config.jelly http://jenkins-ci.org/commit/cvs-plugin/794afd76127191e6a5174647d0c2620f0aadd915 Log: [FIXED JENKINS-753] Allows performing a clean checkout if update fails [FIXED JENKINS-12595] CVS gets passed the module name so creates lock files in the correct directory on the remote server [FIXED JENKINS-12581] CVS plugin now forces a module name in the udpate command to prevent an attempt to checkout all remote modules > CVS: First CVS Update after Checkout reads whole CVS-Repository > --- > > Key: JENKINS-12581 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12581 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: Tomcat6 / RHEL5 >Reporter: chrisabit >Assignee: Michael Clarke >Priority: Blocker > > When migration from old CVS-Plugin to the new Jenkins CVS-Plugin "Local Name" > isn't defined. > This leads to a HUGE problem: The first CVS-Update (not the first > CVS-Checkout! This works!) will execute: > "cvs update -d -P -r HEAD -D 2012-01-30 16:37:56CE" > Thus the whole CVS repository is read. > Simple solution: When migrating: "Remote Name" and "Local Name" must both be > set. -- 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-12599) IllegalArgumentException after Upgrade to 2.0
[ https://issues.jenkins-ci.org/browse/JENKINS-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158640#comment-158640 ] SCM/JIRA link daemon commented on JENKINS-12599: Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/CVSSCM.java http://jenkins-ci.org/commit/cvs-plugin/1ccef67edc26350d544b2ae5ebfebed5ed91ac8c Log: [JENKINS-12599] Changing how password is set in connections so as not to modify port numbers (as per comments #2 and #3) [JENKINS-753] Stop processing if update fails and we're not going to do a workspace clean Compare: https://github.com/jenkinsci/cvs-plugin/compare/39da798...1ccef67 > IllegalArgumentException after Upgrade to 2.0 > - > > Key: JENKINS-12599 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12599 > Project: Jenkins > Issue Type: Bug > Components: cvs >Reporter: Ulli Hafner >Priority: Blocker > > 12:00:14 Started by user hafner > 12:00:14 Building on master > 12:00:14 FATAL: Unrecognized CVS Root: > :ext:haf...@fipsfspm.faktorzehn.de:/projekte/cvs.com.f10.ips4fspm > 12:00:14 java.lang.IllegalArgumentException: Unrecognized CVS Root: > :ext:haf...@fipsfspm.faktorzehn.de:/projekte/cvs.com.f10.ips4fspm > 12:00:14 at > org.netbeans.lib.cvsclient.connection.ConnectionFactory.getConnection(ConnectionFactory.java:117) > 12:00:14 at hudson.scm.CVSSCM.getCvsClient(CVSSCM.java:570) > 12:00:14 at hudson.scm.CVSSCM.checkout(CVSSCM.java:702) > 12:00:14 at > hudson.model.AbstractProject.checkout(AbstractProject.java:1193) > 12:00:14 at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555) > 12:00:14 at > hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443) > 12:00:14 at hudson.model.Run.run(Run.java:1376) > 12:00:14 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > 12:00:14 at > hudson.model.ResourceController.execute(ResourceController.java:88) > 12:00:14 at hudson.model.Executor.run(Executor.java:175) -- 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-753) Should perform clean checkout if update fails
[ https://issues.jenkins-ci.org/browse/JENKINS-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158641#comment-158641 ] dogfood commented on JENKINS-753: - Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_cvs #4|http://ci.jenkins-ci.org/job/plugins_cvs/4/] [FIXED JENKINS-753] Allows performing a clean checkout if update fails (Revision 794afd76127191e6a5174647d0c2620f0aadd915) Result = SUCCESS michael.m.clarke : Files : * src/main/java/hudson/scm/CVSSCM.java * src/main/resources/hudson/scm/CVSSCM/config.jelly > Should perform clean checkout if update fails > - > > Key: JENKINS-753 > URL: https://issues.jenkins-ci.org/browse/JENKINS-753 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: jglick >Assignee: Michael Clarke > > In a project configured to use CVS update mode, and doing incremental builds > (or > faulty clean steps), it can happen that CVS updates produce conflicts. For > example, on occasion what was previously a .cvsignore'd build product becomes > checked into the repository - say, ANTLR-generated files if you no longer wish > to depend on antlr.jar for regular builds. In such cases, "cvs up" fails and > the > build breaks. There is no way to correct the build from the admin GUI, either; > you need to log in to the server and delete the workspace. > If a project is configured to use update mode, and the update command fails, I > think Hudson should automatically attempt a clean checkout, in the interests > of > robustness and zero maintenance. -- 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-12599) IllegalArgumentException after Upgrade to 2.0
[ https://issues.jenkins-ci.org/browse/JENKINS-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158642#comment-158642 ] dogfood commented on JENKINS-12599: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_cvs #4|http://ci.jenkins-ci.org/job/plugins_cvs/4/] [JENKINS-12599] Changing how password is set in connections so as not to (Revision 1ccef67edc26350d544b2ae5ebfebed5ed91ac8c) Result = SUCCESS michael.m.clarke : Files : * src/main/java/hudson/scm/CVSSCM.java > IllegalArgumentException after Upgrade to 2.0 > - > > Key: JENKINS-12599 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12599 > Project: Jenkins > Issue Type: Bug > Components: cvs >Reporter: Ulli Hafner >Priority: Blocker > > 12:00:14 Started by user hafner > 12:00:14 Building on master > 12:00:14 FATAL: Unrecognized CVS Root: > :ext:haf...@fipsfspm.faktorzehn.de:/projekte/cvs.com.f10.ips4fspm > 12:00:14 java.lang.IllegalArgumentException: Unrecognized CVS Root: > :ext:haf...@fipsfspm.faktorzehn.de:/projekte/cvs.com.f10.ips4fspm > 12:00:14 at > org.netbeans.lib.cvsclient.connection.ConnectionFactory.getConnection(ConnectionFactory.java:117) > 12:00:14 at hudson.scm.CVSSCM.getCvsClient(CVSSCM.java:570) > 12:00:14 at hudson.scm.CVSSCM.checkout(CVSSCM.java:702) > 12:00:14 at > hudson.model.AbstractProject.checkout(AbstractProject.java:1193) > 12:00:14 at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555) > 12:00:14 at > hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443) > 12:00:14 at hudson.model.Run.run(Run.java:1376) > 12:00:14 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > 12:00:14 at > hudson.model.ResourceController.execute(ResourceController.java:88) > 12:00:14 at hudson.model.Executor.run(Executor.java:175) -- 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-11420) JDK Auto install throws FATAL: org/apache/xml/utils/PrefixResolver
[
https://issues.jenkins-ci.org/browse/JENKINS-11420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158643#comment-158643
]
John Wildman commented on JENKINS-11420:
Shouldn't this be fixed in the LTS releases? We just upgraded to 1.424.2 and
it's still broken. Better yet, what if the JDK down-loader was a plugin so we
could upgrade it independently?
Thanks.
> JDK Auto install throws FATAL: org/apache/xml/utils/PrefixResolver
> --
>
> Key: JENKINS-11420
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11420
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Windows 2003 R2 SP2
>Reporter: Jim McCaskey
>
> It appears that JDK auto install has been broken since version 1.433. It
> last worked on version 1.432. Below is the error that you get when it tries
> to auto install the JDK.
> {code}
> Installing JDK jdk-6u24-oth-JPR
> Downloading JDK from
> http://download.oracle.com/otn/java/jdk/6u24-b07//jdk-6u24-windows-x64.exe
> FATAL: org/apache/xml/utils/PrefixResolver
> java.lang.NoClassDefFoundError: org/apache/xml/utils/PrefixResolver
> at
> com.gargoylesoftware.htmlunit.html.DomNamespaceNode.getLocalName(DomNamespaceNode.java:81)
> at
> com.gargoylesoftware.htmlunit.html.HtmlElement.getNodeName(HtmlElement.java:308)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.addNodeToRightParent(HTMLParser.java:636)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.startElement(HTMLParser.java:610)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.cyberneko.html.HTMLTagBalancer.callStartElement(HTMLTagBalancer.java:1126)
> at
> org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:734)
> at
> org.cyberneko.html.filters.DefaultFilter.startElement(DefaultFilter.java:136)
> at
> org.cyberneko.html.filters.NamespaceBinder.startElement(NamespaceBinder.java:278)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2697)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:2013)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:907)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:901)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:449)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:332)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:389)
> at hudson.tools.JDKInstaller.locate(JDKInstaller.java:369)
> at hudson.tools.JDKInstaller.performInstallation(JDKInstaller.java:125)
> at
> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61)
> at
> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
> at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:150)
> at hudson.model.JDK.forNode(JDK.java:112)
> at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:822)
> at
> hudson.maven.AbstractMavenBuild.getEnvironment(AbstractMavenBuild.java:59)
> at
> hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:155)
> at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:673)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1193)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:567)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:455)
> at hudson.model.Run.run(Run.java:1404)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:470)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:230)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.xml.utils.PrefixResolver
> at java.net.URLClassLoader$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(
[JIRA] (JENKINS-11833) Add a Post-build action to create AMI
[ https://issues.jenkins-ci.org/browse/JENKINS-11833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-11833 started by edovale. > Add a Post-build action to create AMI > - > > Key: JENKINS-11833 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11833 > Project: Jenkins > Issue Type: New Feature > Components: cloudformation >Reporter: jinesh varia >Assignee: edovale > > Several users would like to build an AMI and the end of the build/test > process, so that they can quickly launch AMIs in the test environment. To do > this, we need to install all the necessary dependencies and build artifacts > on the right instance type (64-bit or 32-bit) and call the create image > (EBS-backed) command. Tag the image with the right version number using > server tagging feature and output the new AmiID to the user for further > integration (with CF templates) -- 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-12571) Jenkins master spins on 2CPUs, using 1GB memory instead of starting up
[ https://issues.jenkins-ci.org/browse/JENKINS-12571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stewart Smith resolved JENKINS-12571. - Resolution: Fixed Fixed in 1.450 > Jenkins master spins on 2CPUs, using 1GB memory instead of starting up > -- > > Key: JENKINS-12571 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12571 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Ubuntu Natty. OpenJDK 6 >Reporter: Stewart Smith >Priority: Blocker > > Restarting Jenkins master on any version 1.442 to current spends some time > doing work (seen via strace) and then gets stuck for over 10 minutes and > doesn't start up at all. Web UI just says "Please wait while Jenkins is > getting ready to work..." and master spins on 2 CPUs, using about 1GB of > memory and strace only shows activity on futex() calls. > Notably, the jenkins master does not start, which isn't exactly useful. -- 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-10483) Git plugin does not handle git-flow style feature branches (e.g. feature/myfeature) correctly
[ https://issues.jenkins-ci.org/browse/JENKINS-10483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158645#comment-158645 ] Chris Rode commented on JENKINS-10483: -- "origin/release/XXX" worked for me. I had to ensure that the "Name of repository" section in advanced was origin as well though > Git plugin does not handle git-flow style feature branches (e.g. > feature/myfeature) correctly > - > > Key: JENKINS-10483 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10483 > Project: Jenkins > Issue Type: Bug > Components: git >Affects Versions: current > Environment: Running on a Debian 6.0 virtual machine (Xen), Tomcat 6 > (from tomcat6 .deb package), Sun JDK 1.6.0_26 (from sun-java6-jdk .deb > package), git 1.7.2.5 >Reporter: Lee Rosen >Assignee: abayer > > When I configure a job to use a branch in the form feature/myfeature (as > would be created by git-flow when starting a feature branch) the checkout in > the workspace ends up being from the master branch after the job runs. The > feature/myfeature branch is present on the git server pointed to by the URL > configured in the job and can be successfully checked out into the workspace > manually using the configured credentials. Further, configuring other simple > branch names, like develop, as the branch in the job configuration works > fully as expected -- only branch names beginning with 'feature/' seem to > encounter a problem. -- 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-8657) copy artifacts from last stable build of a parameterized job, by parameter
[
https://issues.jenkins-ci.org/browse/JENKINS-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Davidson reopened JENKINS-8657:
I'm having some trouble with this feature on v1.21 of the copy artifact plugin.
I have a related job that has two build parameters: SIM_COMMON_REV and
SIM_INTERFACE_REV. The name of the job is sim-interfaces-linux64. When I
attempt to "copy artifacts" by providing both parameters in the project name
text box like so:
sim-interfaces-linux64/SIM_COMMON_REV=${SIM_COMMON_REV}&SIM_INTERFACE_REV=${SIM_INTERFACE_REV}
I receive the following build error: Unable to find a build for artifact copy
from: sim-interfaces-linux64/SIM_COMMON_REV=default&SIM_INTERFACE_REV=default
However, those values are completely valid, and I have a number of builds that
satisfy those conditions. If I only specify a single parameter (striking the
ampersand obviously) each works on it's own. It's only when combined that it
has problems.
Perhaps my syntax is incorrect, otherwise I think there is probably an issue.
> copy artifacts from last stable build of a parameterized job, by parameter
> --
>
> Key: JENKINS-8657
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8657
> Project: Jenkins
> Issue Type: New Feature
> Components: copyartifact
>Affects Versions: current
>Reporter: evilchili
>Assignee: Alan Harder
>
> I'd like to be able to copy artifacts from the last stable build of a job
> that was run with a given set of parameters. That is, for JOB1 with
> parameters PARAM1 and PARAM2, I'd like to be able to tell JOB2 to copy
> artifacts from the last build of JOB1 that had PARAM1=Bob,PARAM2=Alice. The
> existing syntax for specifying matrix jobs might be reusable, thus:
> Project Name: JOB1/PARAM1=Bob,PARAM2=Alice
> Bonus points for parameter expansion, so that JOB2's parameters could be used
> to make the selection:
> Project Name: JOB1/PARAM1=$THISPARAM,PARAM2=$THATPARAM
--
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-8657) copy artifacts from last stable build of a parameterized job, by parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Davidson resolved JENKINS-8657. Resolution: Fixed My syntax was indeed incorrect. The following comments: https://issues.jenkins-ci.org/browse/JENKINS-8657?focusedCommentId=145502&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-145502 seems to indicate that the parameters need to be separated by ampersands. It turns out it's commas (as stated in the help). > copy artifacts from last stable build of a parameterized job, by parameter > -- > > Key: JENKINS-8657 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8657 > Project: Jenkins > Issue Type: New Feature > Components: copyartifact >Affects Versions: current >Reporter: evilchili >Assignee: Alan Harder > > I'd like to be able to copy artifacts from the last stable build of a job > that was run with a given set of parameters. That is, for JOB1 with > parameters PARAM1 and PARAM2, I'd like to be able to tell JOB2 to copy > artifacts from the last build of JOB1 that had PARAM1=Bob,PARAM2=Alice. The > existing syntax for specifying matrix jobs might be reusable, thus: > Project Name: JOB1/PARAM1=Bob,PARAM2=Alice > Bonus points for parameter expansion, so that JOB2's parameters could be used > to make the selection: > Project Name: JOB1/PARAM1=$THISPARAM,PARAM2=$THATPARAM -- 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
