Change a build from a text file
I am a new baby to Jenkins and I could not go all the old posts to look for what I need help ! I have a Jenkins setup and my Jenkins monitors a specific file such as the lastbuildfound.txt in builds folder. This text file contains the last successful build no. Whenever this text file is updated with a new build number, my Jenkins will trigger by the FSTrigger Plugin https://wiki.jenkins-ci.org/display/JENKINS/FSTrigger+Plugin . However, Jenkins generates a build number in sequence such as 1, 2, or etc. The reason I created this setup to run an automation on new build which I don't want to involve with a build person. The problem is that my Jenkins is not triggering by a source control, so I want to be able to get the build number from a text build and update the build number in Jenkins to match it. I know that there is the EnvInject https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin plugin but I don't know how to use it or any methods. Please help me to achieve this issue and give me a clear instruction / steps. Thanks in advance. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6bee6d75-d46d-4c95-9117-2432d062e1bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal : Jenkins to require Java 8
On 25 March 2015 at 07:49, Nigel Magnay nigel.mag...@gmail.com wrote: I think there's confusion over 'support' and 'develop'. Going JDK8 should not imply dropping non-JDK6 versions: Take Tomcat as an example. Tomcat 9 requires a newer JDK than Tomcat 8. That does not mean that Tomcat 8 isn't receiving 'support', or that it's stopped working - it's getting fixes, it's not EOL - it's probably what most people are actually building products on. Indeed Tomcat 6 still gets fixes. But 'new development' is happening elsewhere. In the context of 'LTS', I don't think it's acceptable to simply bump a heap of external requirements; if I were on a maintenance contract, I'd yell too! A Jenkins 1.xxx line should continue to receive fixes (e.g security, critical bugs, whatever else the community finds). A Jenkins 2.xxx line should take the opportunity to upgrade to JDK8 (and perhaps bump up some libraries like guava while it's at it). I think for build tools, such as Jenkins/Maven/Ant/Gradle/etc, there are basically two JDK requirement modes that make sense: * one and one back * all the JDKs currently supported by Oracle Right now the first says JDK7 JDK8 and the second says JDK7 and JDK8. JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8 but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL. The advantage of the second model is that the July LTS will be JDK8 The argument I hear, and I think it's possibly a straw man, is a demographic of users who are 'stuck on slow coach platform' who go beyond demanding *support *(which I think they deserve), but also want *all the new features as well*. If they truly exist (perhaps they do, but it seems an odd combination of being unable to change anything about their environment *except* the version of Jenkins they run), then I find that position phenomenally presumptuous. What they are demanding is what I develop (for free! and give away to them!) must forever be tied to their lowest-common-denominator platform, representing an utterly tiny minority. Now that Java itself is also OSS (and virtualisation is a thing, and hardware is cheap, etc etc), this is never a we can't change, it's simply a we don't want to. Put simply, new features available on a new product version usually builds the business case for making an environmental change. But why bother doing that, when you can transfer the burden of doing that back to the unpaid, OSS developers giving me product for free? On the technical, Java8 brings some useful stuff, and is a more pleasant and modern place for a developer: - No more permgen space! - Default methods in interfaces (useful when you're trying to extend an API throughout the life of a product) - Lambda Expressions - OptionalT - Method parameter names in metadata (I believe Jenkins needs a plugin to extract this. Certainly that's the approach I needed pre-JDK8, which often failed when my IDE decided to recompile - good riddance to that). In the context of recruiting (OSS) developers, I think Java moves slowly enough (especially cf. C#) to damage its mindshare without additionally making it all less fun by making everyone act like a corporate IT developer stuck on an obsolete platform. That just drives people to work on CI systems that don't have that constraint. On Tue, Mar 24, 2015 at 11:35 PM, nicolas de loof nicolas.del...@gmail.com wrote: Proposal is not to maintain parallel branches, but to make next release to require Java 8 and start using it for new development / step by step enhance existing APIs to benefit Java 8 What would change in 3/ 6 months ? Lot's of people will still run RHEL 5 and build legacy Java 1.3 applications. Ok, maybe 10 LTS's then. We need to have a plan for supporting the past and the future. If we do have so many people wanting the java6 branch, then they should be able to support it. It sounds like we have a large number of people interested in java8 and I don't think such a transition will be ready for quite some time. I imagine we will also have people using both and maintaining both. I still have RHEL5 and a SPARC and I will do what I have to with those as long as I need to. But I also have bleeding edge items and I'd like to see Jenkins continue to push that envelope. This is a community, I can't imagine that if the mainline moved on to Java8 we wouldn't still help those who are still using the current mainline. - Thomas -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D13733B8.11501%25thomas.suckow%40pnnl.gov
Re: Proposal : Jenkins to require Java 8
I think there's confusion over 'support' and 'develop'. Going JDK8 should not imply dropping non-JDK6 versions: Take Tomcat as an example. Tomcat 9 requires a newer JDK than Tomcat 8. That does not mean that Tomcat 8 isn't receiving 'support', or that it's stopped working - it's getting fixes, it's not EOL - it's probably what most people are actually building products on. Indeed Tomcat 6 still gets fixes. But 'new development' is happening elsewhere. In the context of 'LTS', I don't think it's acceptable to simply bump a heap of external requirements; if I were on a maintenance contract, I'd yell too! A Jenkins 1.xxx line should continue to receive fixes (e.g security, critical bugs, whatever else the community finds). A Jenkins 2.xxx line should take the opportunity to upgrade to JDK8 (and perhaps bump up some libraries like guava while it's at it). The argument I hear, and I think it's possibly a straw man, is a demographic of users who are 'stuck on slow coach platform' who go beyond demanding *support *(which I think they deserve), but also want *all the new features as well*. If they truly exist (perhaps they do, but it seems an odd combination of being unable to change anything about their environment *except* the version of Jenkins they run), then I find that position phenomenally presumptuous. What they are demanding is what I develop (for free! and give away to them!) must forever be tied to their lowest-common-denominator platform, representing an utterly tiny minority. Now that Java itself is also OSS (and virtualisation is a thing, and hardware is cheap, etc etc), this is never a we can't change, it's simply a we don't want to. Put simply, new features available on a new product version usually builds the business case for making an environmental change. But why bother doing that, when you can transfer the burden of doing that back to the unpaid, OSS developers giving me product for free? On the technical, Java8 brings some useful stuff, and is a more pleasant and modern place for a developer: - No more permgen space! - Default methods in interfaces (useful when you're trying to extend an API throughout the life of a product) - Lambda Expressions - OptionalT - Method parameter names in metadata (I believe Jenkins needs a plugin to extract this. Certainly that's the approach I needed pre-JDK8, which often failed when my IDE decided to recompile - good riddance to that). In the context of recruiting (OSS) developers, I think Java moves slowly enough (especially cf. C#) to damage its mindshare without additionally making it all less fun by making everyone act like a corporate IT developer stuck on an obsolete platform. That just drives people to work on CI systems that don't have that constraint. On Tue, Mar 24, 2015 at 11:35 PM, nicolas de loof nicolas.del...@gmail.com wrote: Proposal is not to maintain parallel branches, but to make next release to require Java 8 and start using it for new development / step by step enhance existing APIs to benefit Java 8 What would change in 3/ 6 months ? Lot's of people will still run RHEL 5 and build legacy Java 1.3 applications. Ok, maybe 10 LTS's then. We need to have a plan for supporting the past and the future. If we do have so many people wanting the java6 branch, then they should be able to support it. It sounds like we have a large number of people interested in java8 and I don't think such a transition will be ready for quite some time. I imagine we will also have people using both and maintaining both. I still have RHEL5 and a SPARC and I will do what I have to with those as long as I need to. But I also have bleeding edge items and I'd like to see Jenkins continue to push that envelope. This is a community, I can't imagine that if the mainline moved on to Java8 we wouldn't still help those who are still using the current mainline. - Thomas -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D13733B8.11501%25thomas.suckow%40pnnl.gov https://groups.google.com/d/msgid/jenkinsci-dev/D13733B8.11501%25thomas.suckow%40pnnl.gov?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznBdm3DmnZ_GO0viCawUek0yXj3jnSiZR%3DoDpHObR%2BSvQ%40mail.gmail.com
Re: FilePath act fails with an exception
I have added checkRoles within my FileCallable implementation, but it still
fails. Though this time with a different message.
remote file operation failed: /home/build/jenkins/workspace/myMatrixProject at
hudson.remoting.Channel@54e95cec:Development-opensuse-x86_64:
java.io.IOException: Unable to serialize
hudson.FilePath$FileCallableWrapper@5a17f7bd
import hudson.FilePath.FileCallable
import hudson.remoting.VirtualChannel
import org.jenkinsci.remoting.RoleChecker
def jenkinsInstance = jenkins.model.Jenkins.getInstance()
def project = jenkinsInstance.getItem(myMatrixProject)
def rootProject = project.getRootProject()
def someWorkspace = rootProject.getSomeWorkspace()
try {
def test = someWorkspace.act(new FileCallableString() {
private static final long serialVersionUID = 1;
@Override
public String invoke(File file, VirtualChannel channel) {
return Testing Testing;
}
@Override
public void checkRoles(RoleChecker checker) throws
SecurityException {
}
});
println test
} catch (IOException e) {
println e.getMessage()
} catch (InterruptedException e) {
println e.getMessage()
}
Could you ellaborate on use the provided abstract base classes as parent ?
tirsdag 24. mars 2015 18.29.12 UTC+1 skrev Ullrich Hafner følgende:
You need to implement the new method checkRoles. See JavaDoc of latest
FileCallable
version. (Or you can use the provided abstract base classes as parent).
Am 24.03.2015 um 18:03 schrieb Sverre Moe sverr...@gmail.com
javascript::
Trying the following in Jenkins Script Console:
import hudson.FilePath.FileCallable
import hudson.remoting.VirtualChannel
def jenkinsInstance = jenkins.model.Jenkins.getInstance()
def project = jenkinsInstance.getItem(myMatrixProject)
def rootProject = project.getRootProject()
def someWorkspace = rootProject.getSomeWorkspace()
try {
def test = someWorkspace.act(new FileCallableString() {
private static final long serialVersionUID = 1;
@Override
public String invoke(File file, VirtualChannel channel) {
return Testing Testing;
}
});
} catch (IOException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
It throws an exception:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
failed:
Script1.groovy: 10: Can't have an abstract method in a non-abstract class.
The class 'Script1$1' must be declared abstract or the method 'void
checkRoles(org.jenkinsci.remoting.RoleChecker)' must be implemented.
@ line 10, column 61.
ct(new FileCallableString() {
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-de...@googlegroups.com javascript:.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/b2502c2c-8a02-46df-8bce-90ee10724090%40googlegroups.com
https://groups.google.com/d/msgid/jenkinsci-dev/b2502c2c-8a02-46df-8bce-90ee10724090%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/71b59eab-5381-4cf4-becd-2fe7389ad074%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Proposal : Jenkins to require Java 8
JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8 but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL. The advantage of the second model is that the July LTS will be JDK8 So it could be there's some confusion around LTS, as the wiki says it follows the ubuntu model, but is it really the same? I.E: If I use Ubuntu 14.10, I'll basically get updates for 9 months, after which if I want a fix, I'll have to flip to 15.04 (There's an overlap). If I want stability, I pick an LTS version (released every 2 years) - 14.04 LTS - which is supported for *5 years. *It gets no new features in that time, but it does receive updates (indeed we're up to 14.04.2 already). So ubuntu is a release every 6 months, an LTS release every 2 years, with LTS 'support' for 5 years. Jenkins is a release ~every week, an LTS release every 12 weeks, with LTS 'support' for 12 weeks. 12 weeks seems like a very short period of 'support'. Trying to put myself in the shoes of 'corporate IT world', isn't that saying that if I build my infra (and JDK) around Jenkins 1.xxx.1 - I'll get only 12 weeks grace before the possibility that a security fix might mean I need to change my JDK ? Now - I am perfectly comfortable with that (indeed we step our environment to match the Jenkins LTS editions), but I can see that a side-effect might be those with conservative environments trying hard to make sure that when the 'version with the fix' comes around, basically trying torpedo JDK8 or anything else. I'm also perfectly comfortable with the possibility that if you need Jenkins 1.xxx.(n3), then you obtain those by either contributing the backporting effort yourself, or having a maintenance contract with Cloudbees|A.N.Other that does it for you. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Different versions of the referenced plugin produce InvalidCastException
Hi all, In the plugin I'm currently writing, I reference promoted-builds(-plugin) v2.20. I'm pretty satisfied with this version of the plugin. On the test environment I decided to add also parametrized-trigger(-plugin). Which depends on promoted-builds(-plugin) v2.10. During the execution of my plugin, I get an exception like Caused by: java.lang.ClassCastException: hudson.plugins.promoted_builds.JobPropertyImpl cannot be cast to hudson.plugins.promoted_builds.JobPropertyImpl I suppose this is related to the version of the plugin. Is there a way to control the (version of the) class being used? Is this due to a change in the interface of the called class? (Comparing the two tags https://github.com/jenkinsci/promoted-builds-plugin/compare/promoted-builds-2.10...promoted-builds-2.20, I see that the signature of some methods in the JobPropertyImpl class has changed -- the synchronized keyword has been added) Thanks in advance, Ivo -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPc4eF9Srz_WjLZYQUHYgrcJXxOEB4%2BFjJ4fQp%2BbCdVa%3De7tug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Plugin hosting request: Vncviewer plugin
Dear Team, vncviewer plugin lets you start JavaScript based VNC viewer via HTML link directly from 'Console output' of the job. Subversion path pf plugin: https://svn.jenkins-ci.org/trunk/hudson/plugins/vncviewer Regards Dimitri Tenenbaum -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e07a2e43-dbe5-4d22-880f-57c947f3b100%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugin hosting request: AdvancedInstaller Plugin
I agree with Daniel and Oleg, I also think it is misleading - maybe not to he ones how know this tool - but to everyone else and I would say thats about 90% ..my 2cents /Domi On 25 Mar 2015, at 14:42, advinst caphyon advinst.caph...@gmail.com wrote: Hi, Advanced Installer is a recognized name in the packaging solutions market. The id will not be misleading to our users which requested this plugin. Also we would like to use the same naming scheme as similar products (wix, InstallShield). So if it is not inconvenient we would like to keep this artifactId. Thanks On Wednesday, March 25, 2015 at 3:25:41 PM UTC+2, Oleg Nenashev wrote: Do you consider changing the artifactId? The current one is quite confusing. I think that Daniel's proposal could be a right choice for your plugin 2015-03-25 16:01 GMT+03:00 advinst caphyon advinst...@gmail.com: Hi, Here is the plugin repo: https://github.com/advinst/advinst-jenkins-plugin Any update o this? Thanks. On Tuesday, March 24, 2015 at 8:48:57 AM UTC+2, Oleg Nenashev wrote: As I see, the plugin does not exist in your repo. Could you clarify the purpose of the plugin (e.g. describe the use-case in details)? There're many plugins, which may address your use-case. As example, Custom Tools allows to setup an environment for builds. вторник, 24 марта 2015 г., 9:27:51 UTC+3 пользователь advinst caphyon написал: Hello I would like to request to host a Jenkins CI plugin for building setups using Advanced Installer Characteristics of plugin: - Plugin will add a build step allowing setup builds using Advanced Installer. INFORMATION REQUESTED GitHub plugin name : advancedinstaller-plugin Personal GitHub ID : advinst Thanks! -- You received this message because you are subscribed to a topic in the Google Groups Jenkins Developers group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/e93hBJE6vDM/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3755ca11-a32d-47d3-bfdc-34535065b275%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/cf627c04-2223-4c30-a645-5abbdd40a67b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/24FB7954-4373-4ABA-9802-2A26603BB43C%40fortysix.ch. For more options, visit https://groups.google.com/d/optout.
Re: Plugin hosting request: AdvancedInstaller Plugin
Hi, Here is the plugin repo: https://github.com/advinst/advinst-jenkins-plugin Any update o this? Thanks. On Tuesday, March 24, 2015 at 8:48:57 AM UTC+2, Oleg Nenashev wrote: As I see, the plugin does not exist in your repo. Could you clarify the purpose of the plugin (e.g. describe the use-case in details)? There're many plugins, which may address your use-case. As example, Custom Tools allows to setup an environment for builds. вторник, 24 марта 2015 г., 9:27:51 UTC+3 пользователь advinst caphyon написал: Hello I would like to request to host a Jenkins CI plugin for building setups using Advanced Installer Characteristics of plugin: - Plugin will add a build step allowing setup builds using Advanced Installer. INFORMATION REQUESTED *GitHub plugin name* : advancedinstaller-plugin *Personal GitHub ID* : advinst Thanks! -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3755ca11-a32d-47d3-bfdc-34535065b275%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugin hosting request: AdvancedInstaller Plugin
Hi, Advanced Installer is a recognized name in the packaging solutions market. The id will not be misleading to our users which requested this plugin. Also we would like to use the same naming scheme as similar products (wix, InstallShield). So if it is not inconvenient we would like to keep this artifactId. Thanks On Wednesday, March 25, 2015 at 3:25:41 PM UTC+2, Oleg Nenashev wrote: Do you consider changing the artifactId? The current one is quite confusing. I think that Daniel's proposal could be a right choice for your plugin 2015-03-25 16:01 GMT+03:00 advinst caphyon advinst...@gmail.com javascript:: Hi, Here is the plugin repo: https://github.com/advinst/advinst-jenkins-plugin Any update o this? Thanks. On Tuesday, March 24, 2015 at 8:48:57 AM UTC+2, Oleg Nenashev wrote: As I see, the plugin does not exist in your repo. Could you clarify the purpose of the plugin (e.g. describe the use-case in details)? There're many plugins, which may address your use-case. As example, Custom Tools allows to setup an environment for builds. вторник, 24 марта 2015 г., 9:27:51 UTC+3 пользователь advinst caphyon написал: Hello I would like to request to host a Jenkins CI plugin for building setups using Advanced Installer Characteristics of plugin: - Plugin will add a build step allowing setup builds using Advanced Installer. INFORMATION REQUESTED *GitHub plugin name* : advancedinstaller-plugin *Personal GitHub ID* : advinst Thanks! -- You received this message because you are subscribed to a topic in the Google Groups Jenkins Developers group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/e93hBJE6vDM/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3755ca11-a32d-47d3-bfdc-34535065b275%40googlegroups.com https://groups.google.com/d/msgid/jenkinsci-dev/3755ca11-a32d-47d3-bfdc-34535065b275%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/cf627c04-2223-4c30-a645-5abbdd40a67b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugin hosting request
Dear group, i followed the instructions layed out in https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Workingaroundcommonissues. Am i still on track? Thanks Jochen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3028c8b8-a602-4ac7-988c-aaecb6caed2f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal : Jenkins to require Java 8
• Is this something for the governance board to decide at the next meeting? Next meeting's agenda is already more than full. People have their opinions but we need to move forward to reach a decision of which there is not one solution that meets everyone's requirements. We should know what the side effects are though (including JDK availability on the systems our users use), and communicate accordingly. Right now, I don't even know how availability of JDK 8 is for various common platforms Jenkins runs on. If increasing the JDK requirement means we need to discontinue some of the native installers, then that's fine with me in principle, if we know in advance and can plan accordingly (e.g. provide extensive 'manual installation' instructions). But increasing the system requirements such that the installers simply become useless would hurt users who rely an them and rightfully expect them to work*. They exist and are essentially the recommended way to install Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins), so we should support them, and fix their shortcomings, rather than ignore them. Jenkins is difficult enough to start using as it is. Let's not make it worse. Why don't we start by setting up a configuration survey, asking the users list, and putting banners up on the wiki, Jira, jenkins-ci.org? Then we'd at least have some data to base any decisions on. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/560A0115-C06F-409C-B10D-ED639698AF04%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
Re: Plugin hosting request: AdvancedInstaller Plugin
Do you consider changing the artifactId? The current one is quite confusing. I think that Daniel's proposal could be a right choice for your plugin 2015-03-25 16:01 GMT+03:00 advinst caphyon advinst.caph...@gmail.com: Hi, Here is the plugin repo: https://github.com/advinst/advinst-jenkins-plugin Any update o this? Thanks. On Tuesday, March 24, 2015 at 8:48:57 AM UTC+2, Oleg Nenashev wrote: As I see, the plugin does not exist in your repo. Could you clarify the purpose of the plugin (e.g. describe the use-case in details)? There're many plugins, which may address your use-case. As example, Custom Tools allows to setup an environment for builds. вторник, 24 марта 2015 г., 9:27:51 UTC+3 пользователь advinst caphyon написал: Hello I would like to request to host a Jenkins CI plugin for building setups using Advanced Installer Characteristics of plugin: - Plugin will add a build step allowing setup builds using Advanced Installer. INFORMATION REQUESTED *GitHub plugin name* : advancedinstaller-plugin *Personal GitHub ID* : advinst Thanks! -- You received this message because you are subscribed to a topic in the Google Groups Jenkins Developers group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/e93hBJE6vDM/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3755ca11-a32d-47d3-bfdc-34535065b275%40googlegroups.com https://groups.google.com/d/msgid/jenkinsci-dev/3755ca11-a32d-47d3-bfdc-34535065b275%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDFc%3DR8xp%3D69xyM4cubqCDbwDRyCq0Wtd5oUz1oPE2Ztg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Different versions of the referenced plugin produce InvalidCastException
On Wed, Mar 25, 2015 at 5:31 AM, Ivo Bellin Salarin ivo.bellinsala...@gmail.com wrote: I suppose this is related to the version of the plugin. Perhaps. Is there a way to control the (version of the) class being used? Is this due to a change in the interface of the called class? No, you can get such a CCE even if the bytecode is identical. I suspect that you are either not declaring your dependency on promoted-builds and/or parameterized-trigger correctly, or there is some subtle bug in the way maven-hpi-plugin sets up the test environment. Normally Maven’s dependency resolution should force one or the other version to be added to the test classpath (the “closer”, 2.20 in this case) and that is that. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr30R6KFx78HMg64_gba7WMkDdQfUimHAND5n9igoF6gug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Different versions of the referenced plugin produce InvalidCastException
I must admit that the parametrized trigger is not a dependency of my plugin. I've copied it in the plugins folder of my dev environment because it is present in our production environment. Fearing a similar crash in the production environment, I preferred ask the question to confirmed Java/Jenkins devs. Il giorno mer 25 mar 2015 17:09 Jesse Glick jgl...@cloudbees.com ha scritto: On Wed, Mar 25, 2015 at 5:31 AM, Ivo Bellin Salarin ivo.bellinsala...@gmail.com wrote: I suppose this is related to the version of the plugin. Perhaps. Is there a way to control the (version of the) class being used? Is this due to a change in the interface of the called class? No, you can get such a CCE even if the bytecode is identical. I suspect that you are either not declaring your dependency on promoted-builds and/or parameterized-trigger correctly, or there is some subtle bug in the way maven-hpi-plugin sets up the test environment. Normally Maven’s dependency resolution should force one or the other version to be added to the test classpath (the “closer”, 2.20 in this case) and that is that. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/jenkinsci-dev/CANfRfr30R6KFx78HMg64_gba7WMkDdQfUimHAND5n9igoF6gug% 40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPc4eF8KCgJOHCW9N%3DxtCHA45Qg-%3DhPyZPjoB%2BuGaf0r6DL7fQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal : Jenkins to require Java 8
On Wed, Mar 25, 2015 at 6:53 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Which is why I think going for JDK7 now is a better plan than trying to jump all the way to JDK8 Painful as it is, I tend to agree. To be clear, by current LTS policy, switching the baseline to Java 8 means that someone whose corporate IT supports installation of only Java 7 will not receive even security fixes in about three months. (CloudBees customers get an extra nine months’ reprieve.) Otherwise they are left to backport for themselves. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr11BV%2B2m2Y%2BiX%3Dz-wFbjD6Di1L7TjEhpfMF4ETkBtqw8g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Different versions of the referenced plugin produce InvalidCastException
Thanks so much. Il giorno mer 25 mar 2015 17:47 Jesse Glick jgl...@cloudbees.com ha scritto: On Wed, Mar 25, 2015 at 12:38 PM, Ivo Bellin Salarin ivo.bellinsala...@gmail.com wrote: I must admit that the parametrized trigger is not a dependency of my plugin. I've copied it in the plugins folder of my dev environment because it is present in our production environment. If you feel there is some possible or actual relationship to the code your plugin is running, add it as a scopetest/scope dependency. Then it will be loaded during functional tests as well as mvn hpi:run. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/jenkinsci-dev/CANfRfr2Sb2A8n-qoZHTxVUsO3WHDx5aHh49aJdtCAy8p zzYrug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPc4eF_4nWYYGCzSY6GXEgnysk9eZqrRhdLW4GgK0FAGLVvCjg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal : Jenkins to require Java 8
On Wed, Mar 25, 2015 at 7:55 AM, nicolas de loof nicolas.del...@gmail.com wrote: new programmation options, not just new filesystem API (that we use via XMLFile anyway) To be clear, there is code scattered all over Jenkins core (and some plugins) which would benefit significantly from java.nio.file. (In a few such cases we are actually already using Java 7 APIs via reflection when available. In most cases we are not because it is too painful.) BTW a much more conservative proposal was made (by me?) a few months ago: that the Jenkins (core + plugin) _build requirement_ be switched to JDK 7+. src/main/java/ would remain compiled with -source 6 (so no , try-with-resources, etc.) but could use Java 7-only APIs without reflection, only guarded by Animal Sniffer (isolated in methods marked @IgnoreJRERequirements). Doing that for JDK 8 is not terribly useful since so many of the new APIs require -target 8. It was also proposed that src/test/java/ could switch to -source 8 and use Java 8 APIs, to make writing tests more pleasant even when the main sources are stuck on 6, though it has since been pointed out that while Maven supports this style without issue, IntelliJ cannot handle it. (NetBeans handles it; not sure about Eclipse.) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1QwEFNwWAUb72CaoFj99WHi%2BjyVdr%3DCs3UMAW1Uzib6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Different versions of the referenced plugin produce InvalidCastException
On Wed, Mar 25, 2015 at 12:38 PM, Ivo Bellin Salarin ivo.bellinsala...@gmail.com wrote: I must admit that the parametrized trigger is not a dependency of my plugin. I've copied it in the plugins folder of my dev environment because it is present in our production environment. If you feel there is some possible or actual relationship to the code your plugin is running, add it as a scopetest/scope dependency. Then it will be loaded during functional tests as well as mvn hpi:run. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Sb2A8n-qoZHTxVUsO3WHDx5aHh49aJdtCAy8pzzYrug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugin hosting request: Vncviewer plugin
Very nice, Just what I need! +1 2015-03-25 6:54 GMT-03:00 Dimitri Tenenbaum dim.tb...@gmail.com: Dear Team, vncviewer plugin lets you start JavaScript based VNC viewer via HTML link directly from 'Console output' of the job. Subversion path pf plugin: https://svn.jenkins-ci.org/trunk/hudson/plugins/vncviewer Regards Dimitri Tenenbaum -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e07a2e43-dbe5-4d22-880f-57c947f3b100%40googlegroups.com https://groups.google.com/d/msgid/jenkinsci-dev/e07a2e43-dbe5-4d22-880f-57c947f3b100%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAF6Bs4ytwjO9phVDkbh%3DfmMxTb-MY18OdPULMaG1S8eszGbPxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
radioBlock is not hiding
f:radioBlock is not hiding child object by default. I have to select
another radio in the same group to make the items hidden.
f:entry field=method
f:section title=Deployment method
f:entry
f:radioBlock checked=TRUE
name=Deploy Method title=Deploy new servers value=Deploy new Servers/
/f:entry
f:entry
f:radioBlock checked=FALSE
name=Deploy Method title=Script Deploy value=Script deploy
f:entry
j:forEach var=script
items=${account.scripts}
f:entry
f:checkbox
name=${script.scriptName} value=${script.scriptName}
title=${script.scriptName}/
/f:entry
/j:forEach
/f:entry
/f:radioBlock
/f:entry
/f:section
/f:entry
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/bcd4f03f-2f19-466e-844c-c0874855965a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Proposal : Jenkins to require Java 8
I didn't mean to kick up this much of a shit storm! People have their opinions but we need to move forward to reach a decision of which there is not one solution that meets everyone's requirements. What is the next steps here? - Do we vote on the following options: 1. Support the current and previous verions of the Oracle JDK 2. Support the JDKs that Oracle support 3. do nothing and stick with Java6. - Is this something for the governance board to decide at the next meeting? /James On Wednesday, 25 March 2015 10:53:31 UTC, Stephen Connolly wrote: On 25 March 2015 at 09:20, Nigel Magnay nigel@gmail.com javascript: wrote: JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8 but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL. The advantage of the second model is that the July LTS will be JDK8 So it could be there's some confusion around LTS, as the wiki says it follows the ubuntu model, but is it really the same? No I don't think it is even close to the same I.E: If I use Ubuntu 14.10, I'll basically get updates for 9 months, after which if I want a fix, I'll have to flip to 15.04 (There's an overlap). If I want stability, I pick an LTS version (released every 2 years) - 14.04 LTS - which is supported for *5 years. *It gets no new features in that time, but it does receive updates (indeed we're up to 14.04.2 already). So ubuntu is a release every 6 months, an LTS release every 2 years, with LTS 'support' for 5 years. Jenkins is a release ~every week, an LTS release every 12 weeks, with LTS 'support' for 12 weeks. That is all that the community has stepped up to deliver. I have no issue if the community wants to put effort into maintaining older LTS lines in addition to the current LTS, but that is something that the community needs to decide. 12 weeks seems like a very short period of 'support'. Trying to put myself in the shoes of 'corporate IT world', isn't that saying that if I build my infra (and JDK) around Jenkins 1.xxx.1 - I'll get only 12 weeks grace before the possibility that a security fix might mean I need to change my JDK ? The 'corporate IT world' would really want a 10 year cycle if it could get it ;-) Now - I am perfectly comfortable with that (indeed we step our environment to match the Jenkins LTS editions), but I can see that a side-effect might be those with conservative environments trying hard to make sure that when the 'version with the fix' comes around, basically trying torpedo JDK8 or anything else. Which is why I think going for JDK7 now is a better plan than trying to jump all the way to JDK8 I'm also perfectly comfortable with the possibility that if you need Jenkins 1.xxx.(n3), then you obtain those by either contributing the backporting effort yourself, or having a maintenance contract with Cloudbees|A.N.Other that does it for you. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%40mail.gmail.com https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/308a1894-e1df-4c3f-b43e-19c2e5133399%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal : Jenkins to require Java 8
The underlying question is indeed to determine project rules considering supported runtime 1. Support the current and previous verions of the Oracle JDK 2. Support the JDKs that Oracle support 3. do nothing and stick with Java6 until 2020. We already decide to move from 1.5 to 6, and this had some impacts on existing installation, but afaik there's not so much people stuck on jenkins 1.519 ! About upgrade warning, we had Can offer a page comparable to https://wiki.jenkins-ci.org/display/JENKINS/Java+5+Compatibility Requirement to run Java 7 will force some users to upgrade infra, so we already can prepare for complains. As I don't like to receive complains, I'd prefer to upgrade to a JDK which offer actual new programmation options, not just new filesystem API (that we use via XMLFile anyway) so I vote for option 2 2015-03-25 12:45 GMT+01:00 James Nord jamestn...@gmail.com: I didn't mean to kick up this much of a shit storm! People have their opinions but we need to move forward to reach a decision of which there is not one solution that meets everyone's requirements. What is the next steps here? - Do we vote on the following options: 1. Support the current and previous verions of the Oracle JDK 2. Support the JDKs that Oracle support 3. do nothing and stick with Java6. - Is this something for the governance board to decide at the next meeting? /James On Wednesday, 25 March 2015 10:53:31 UTC, Stephen Connolly wrote: On 25 March 2015 at 09:20, Nigel Magnay nigel@gmail.com wrote: JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8 but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL. The advantage of the second model is that the July LTS will be JDK8 So it could be there's some confusion around LTS, as the wiki says it follows the ubuntu model, but is it really the same? No I don't think it is even close to the same I.E: If I use Ubuntu 14.10, I'll basically get updates for 9 months, after which if I want a fix, I'll have to flip to 15.04 (There's an overlap). If I want stability, I pick an LTS version (released every 2 years) - 14.04 LTS - which is supported for *5 years. *It gets no new features in that time, but it does receive updates (indeed we're up to 14.04.2 already). So ubuntu is a release every 6 months, an LTS release every 2 years, with LTS 'support' for 5 years. Jenkins is a release ~every week, an LTS release every 12 weeks, with LTS 'support' for 12 weeks. That is all that the community has stepped up to deliver. I have no issue if the community wants to put effort into maintaining older LTS lines in addition to the current LTS, but that is something that the community needs to decide. 12 weeks seems like a very short period of 'support'. Trying to put myself in the shoes of 'corporate IT world', isn't that saying that if I build my infra (and JDK) around Jenkins 1.xxx.1 - I'll get only 12 weeks grace before the possibility that a security fix might mean I need to change my JDK ? The 'corporate IT world' would really want a 10 year cycle if it could get it ;-) Now - I am perfectly comfortable with that (indeed we step our environment to match the Jenkins LTS editions), but I can see that a side-effect might be those with conservative environments trying hard to make sure that when the 'version with the fix' comes around, basically trying torpedo JDK8 or anything else. Which is why I think going for JDK7 now is a better plan than trying to jump all the way to JDK8 I'm also perfectly comfortable with the possibility that if you need Jenkins 1.xxx.(n3), then you obtain those by either contributing the backporting effort yourself, or having a maintenance contract with Cloudbees|A.N.Other that does it for you. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLW QtqxkdvjiWzaJPp28u0bg%40mail.gmail.com https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/308a1894-e1df-4c3f-b43e-19c2e5133399%40googlegroups.com
Re: Proposal : Jenkins to require Java 8
On 25 March 2015 at 09:20, Nigel Magnay nigel.mag...@gmail.com wrote: JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8 but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL. The advantage of the second model is that the July LTS will be JDK8 So it could be there's some confusion around LTS, as the wiki says it follows the ubuntu model, but is it really the same? No I don't think it is even close to the same I.E: If I use Ubuntu 14.10, I'll basically get updates for 9 months, after which if I want a fix, I'll have to flip to 15.04 (There's an overlap). If I want stability, I pick an LTS version (released every 2 years) - 14.04 LTS - which is supported for *5 years. *It gets no new features in that time, but it does receive updates (indeed we're up to 14.04.2 already). So ubuntu is a release every 6 months, an LTS release every 2 years, with LTS 'support' for 5 years. Jenkins is a release ~every week, an LTS release every 12 weeks, with LTS 'support' for 12 weeks. That is all that the community has stepped up to deliver. I have no issue if the community wants to put effort into maintaining older LTS lines in addition to the current LTS, but that is something that the community needs to decide. 12 weeks seems like a very short period of 'support'. Trying to put myself in the shoes of 'corporate IT world', isn't that saying that if I build my infra (and JDK) around Jenkins 1.xxx.1 - I'll get only 12 weeks grace before the possibility that a security fix might mean I need to change my JDK ? The 'corporate IT world' would really want a 10 year cycle if it could get it ;-) Now - I am perfectly comfortable with that (indeed we step our environment to match the Jenkins LTS editions), but I can see that a side-effect might be those with conservative environments trying hard to make sure that when the 'version with the fix' comes around, basically trying torpedo JDK8 or anything else. Which is why I think going for JDK7 now is a better plan than trying to jump all the way to JDK8 I'm also perfectly comfortable with the possibility that if you need Jenkins 1.xxx.(n3), then you obtain those by either contributing the backporting effort yourself, or having a maintenance contract with Cloudbees|A.N.Other that does it for you. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%40mail.gmail.com https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx0g9xt0tPFMA3djgMU5orra-K16QqFotJFSsMH-bM1NA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: FilePath act fails with an exception
Tried the following that got rid of Unable to serialize, but still does
not work. Most of the examples I find online for FilePath.act does not work
in Script Console.
import hudson.FilePath.FileCallable
import hudson.remoting.VirtualChannel
import org.jenkinsci.remoting.RoleChecker
def jenkinsInstance = jenkins.model.Jenkins.getInstance()
def project = jenkinsInstance.getItem(myMatrixProject)
def rootProject = project.getRootProject()
def someWorkspace = rootProject.getSomeWorkspace()
private class MyFileCallable implements FileCallableString {
private static final long serialVersionUID = 1L;
@Override
public String invoke(File file, VirtualChannel channel) throws
IOException, InterruptedException {
return Testing Testing;
}
@Override
public void checkRoles(RoleChecker checker) throws SecurityException {
}
}
try {
def test = someWorkspace.act(new MyFileCallable());
println test
} catch (IOException e) {
println e.getMessage()
} catch (InterruptedException e) {
println e.getMessage()
}
remote file operation failed: /home/build/jenkins/workspace/myMatrixProject at
hudson.remoting.Channel@54e95cec:Development-opensuse-x86_64:
java.io.IOException: Remote call on Development-opensuse-x86_64 failed
onsdag 25. mars 2015 10.03.35 UTC+1 skrev Sverre Moe følgende:
I have added checkRoles within my FileCallable implementation, but it
still fails. Though this time with a different message.
remote file operation failed: /home/build/jenkins/workspace/myMatrixProject
at hudson.remoting.Channel@54e95cec:Development-opensuse-x86_64:
java.io.IOException: Unable to serialize
hudson.FilePath$FileCallableWrapper@5a17f7bd
import hudson.FilePath.FileCallable
import hudson.remoting.VirtualChannel
import org.jenkinsci.remoting.RoleChecker
def jenkinsInstance = jenkins.model.Jenkins.getInstance()
def project = jenkinsInstance.getItem(myMatrixProject)
def rootProject = project.getRootProject()
def someWorkspace = rootProject.getSomeWorkspace()
try {
def test = someWorkspace.act(new FileCallableString() {
private static final long serialVersionUID = 1;
@Override
public String invoke(File file, VirtualChannel channel) {
return Testing Testing;
}
@Override
public void checkRoles(RoleChecker checker) throws
SecurityException {
}
});
println test
} catch (IOException e) {
println e.getMessage()
} catch (InterruptedException e) {
println e.getMessage()
}
Could you ellaborate on use the provided abstract base classes as
parent ?
tirsdag 24. mars 2015 18.29.12 UTC+1 skrev Ullrich Hafner følgende:
You need to implement the new method checkRoles. See JavaDoc of latest
FileCallable
version. (Or you can use the provided abstract base classes as parent).
Am 24.03.2015 um 18:03 schrieb Sverre Moe sverr...@gmail.com:
Trying the following in Jenkins Script Console:
import hudson.FilePath.FileCallable
import hudson.remoting.VirtualChannel
def jenkinsInstance = jenkins.model.Jenkins.getInstance()
def project = jenkinsInstance.getItem(myMatrixProject)
def rootProject = project.getRootProject()
def someWorkspace = rootProject.getSomeWorkspace()
try {
def test = someWorkspace.act(new FileCallableString() {
private static final long serialVersionUID = 1;
@Override
public String invoke(File file, VirtualChannel channel) {
return Testing Testing;
}
});
} catch (IOException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
It throws an exception:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
failed:
Script1.groovy: 10: Can't have an abstract method in a non-abstract class.
The class 'Script1$1' must be declared abstract or the method 'void
checkRoles(org.jenkinsci.remoting.RoleChecker)' must be implemented.
@ line 10, column 61.
ct(new FileCallableString() {
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/b2502c2c-8a02-46df-8bce-90ee10724090%40googlegroups.com
https://groups.google.com/d/msgid/jenkinsci-dev/b2502c2c-8a02-46df-8bce-90ee10724090%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
Plugin Hosting Request: almasw-modbuilder-plugin
Dear Jenkins Here is the needed info to host a plugin - your GitHub plugin name: *almasw-modbuilder-plugin* - your personal GitHub ID: *atejeda* - The existing GitHub repository to fork: *https://github.com/atejeda/almasw-modbuilder-plugin.git* thanks in advance. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8e2da432-cce6-478b-8683-9dc77416f612%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
