Re: Announcing copyartifact-git-plugin
I didn't see a great way to implement what I want, so this is the simplest stopgap to fill my need. It is a separate plugin for the reason Jesse mentioned--to not add a git dependency to a generic plugin. Long-term, it seems like it would be nice if builds had a method to return the branch(es) associated with a build without needing any SCM dependencies. I'm not sure that a generic interface is possible across all SCM systems, though. In lieu of that, I think it would be helpful to write a plugin that has optional dependencies on several SCM plugins and provides the branch information for a build based on the SCM plugins it finds at runtime. Would such a plugin be possible? If so, then copyartifact could come to depend on it, or another plugin similar to copyartifact-git could expose a selector based on it. On Wed, Feb 19, 2014 at 5:25 PM, Richard Bywater wrote: > Woops my bad - the way I read the description was that the plugin was a > "clone" of the copy artifact plugin rather than just an additional selector > for the copy artifact plugin. > > Apologies for the noise :) > Richard. > > > On Thu, Feb 20, 2014 at 1:18 PM, Jesse Glick wrote: > >> On Wed, Feb 19, 2014 at 7:11 PM, Richard Bywater >> wrote: >> > better to update the existing "copy artifact" plugin with your new >> functionality >> >> No, adding a Git dependency to this generic plugin would not be a good >> idea. >> >> -- >> >> 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. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > 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/lHF6peILIFA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > jenkinsci-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Announcing copyartifact-git-plugin
I just created https://github.com/patrick-higgins/copyartifact-git-plugin. This plugin extends the Copy Artifact plugin by adding a build selector for the latest build from a named git branch. I would like to host this plugin at github.com/jenkinsci. I believe I already have commit privilege but don't seem to be able to create new repos. Can someone fork my existing project into the jenkinsci organization? Regards, Patrick -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Call for starteam-plugin interest
Hi Paul, I'm glad to hear that Borland is planning to work on the Jenkins plugin for StarTeam. I've been thinking about updating the plugin to the newest Jenkins SCM plugin interface, as I've received some internal bug reports about build change sets being incomplete/incorrect and I am hoping that using the new interface will help, though I have done very little research at this point. I started a branch to update to SDK 13.0 last May. You can see my progress at https://github.com/patrick-higgins/starteam-plugin/tree/sdk13.0. It has been long enough that I don't recall the state of that branch. It may or may not be functioning. I've been thinking about the best way to handle the SDK upgrade. Do you have any internal metrics about how many StarTeam installations can use the new SDK? The options I have thought of are: 1. Requiring a new SDK for 0.7.0 (or whatever the next major version bump will be). 2. Forking the plugin to allow parallel development for the old and new SDK. 3. Support both new and old SDK within a single plugin code base. Option #1 seems like the most straightforward, but without usage numbers I'm not sure how realistic it is. Glad to have you! --Patrick On Thu, Feb 6, 2014 at 8:56 AM, Paul Adamson wrote: > Hi Folks, > > I work on starteam at Borland and my team has been given some time (and > code) to contribute to the jenkins starteam-plugin. > > I've been talking to the plugin lead Jan Ruzicka and he's really > enthusiastic about having us on board - so I want to put out a call for > anyone else on the list who has an interest in the development of this > plugin as we get it flying again. > > I noticed Patrick Higgins made a rare contribution to the starteam plugin > recently - so a special 'Hi' to you! > > Regards, > Paul > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
