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
niklau...@gmail.comjavascript:
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 jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
