Hi Jesse Thanks for your feedback. Some comment of mine is inline.
Am Donnerstag, 15. Mai 2014 17:34:29 UTC+2 schrieb Jesse Glick: > > On Thu, May 15, 2014 at 3:24 AM, Niklaus Giger > <[email protected]<javascript:>> > wrote: > > Runs a fetch each time the user enters the "Build with parameter". > > Why would you not just use ‘git ls-remote -t’ and avoid the need for > any local clone? > There are two ways to use git-parameter. One using tags and one using commit-ids. git ls-remote works only with tags and is currently not supported by git-plugin. It is on my TODO list. > > Added MIT-LICENSE.txt to use the same license as Jenkins-CI. > > BTW it suffices to specify <licenses> in the POM. > Thanks for the hint. I was unsure about it. I will remove the MIT-LICENSE for the next release. > > Also your POM has a lot of redundant info that you get for free from > the plugin parent POM. No <distributionManagement> is necessary, for > example. Nor do you need to declare the dependency on jenkins-core, or > the source level, or the encoding. I have improved the plugin > archetype POM to show the minimal recommended stuff: > > > https://github.com/jenkinsci/maven-hpi-plugin/blob/master/hpi-archetype/pom.xml > > Thanks. Will be fixed in the next relase > > using git/ssh in developerConnection did not work. scm:git:https works > fine > > for me > > mvn release:prepare release:perform did not work. Finally I used mvn > deploy; > > mvn release:clean + adding -SNAPSHOT to version in pom.xml. > > Yuck. When your local settings are configured properly, normal > release:{prepare,perform} with SSH developerConnection should work > fine. So you were probably missing an SSH private key, or were using a > version of Git unsupported by the default version of the Release > plugin, etc. Yeah, but a newbie like me can get very confused about it! > IMO we need to stop making (or even letting!) developers run plugin > releases locally. Better to use Jenkins for this. I do not really > trust the M2Release plugin but perhaps there can be a parallel set of > plugin release jobs that use a plain Maven build step. The main issue > is how to give broad enough access to let these jobs be triggered by > anyone able to push to the GH repo, without letting anonymous users do > it. (Maybe a special parameter type which redirects you in an iframe > to github.com to log in, grabs a temporary API token, then passes this > to the build long enough to authenticate the release?) > That would be fine for me and would certainly lower the barrier for newcomers, if triggering such a build would be easy, e.g. by pushing a version tag to the git repository. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
