Create a temporary pgp key for use with signing and use it to sign your maven artifacts? I don't know if there is a way to use an agent - perhaps there is. Hoss did some work with manual artifact signing recently (and this used the agent). I never had the need for this.
Dawid On Sat, May 22, 2021 at 4:50 PM Alan Woodward <romseyg...@gmail.com> wrote: > Passing -Dversion.suffix does indeed work, thanks Uwe! The next Yak to > shave is that gradle is now complaining that it can’t sign the artefacts. > From my reading it seems that I have to set things up in my > gradle.properties file, including my password in plain text. This seems … > wrong? I don’t actually need these artefacts signed anyway, so does anyone > with more gradle-fu than me know either a) how to skip the signing step or > b) how to set things up so that they are signed correctly without having my > PGP password sitting in a plain text file. > > Thanks! > > On 20 May 2021, at 14:19, Uwe Schindler <u...@thetaphi.de> wrote: > > The default suffix in this system prop is "SNAPSHOT" and the timestamp > comes then from Maven's internal Logic, this cannot be changed. > > By overriding the suffix explicit (as said before and find by Jenkins) you > convert it to an official "release" in Maven's sense and it is no longer a > snapshot. So you are free with versioning. > > Uwe > > Am May 20, 2021 1:15:12 PM UTC schrieb Uwe Schindler <u...@thetaphi.de>: >> >> Jenkins does this already: >> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/ >> >> It uses build number! >> >> The system property "version suffix" is responsible and is set by >> Jenkins. See in command line: [Lucene-Artifacts-main] $ >> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Artifacts-main/gradlew >> -Dlucene.javadoc.url= >> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc >> -Dversion.suffix=jenkins242 assemble >> >> Uwe >> >> Am May 20, 2021 12:25:48 PM UTC schrieb Michael Sokolov < >> msoko...@gmail.com>: >>> >>> In principal it makes sense, but is there any chance the build artifact >>> could vary for the same SHA? We hope not, I think, but stranger things have >>> happened. Probably an edge case not worth worrying about though, and >>> relying on the build server's clock doesn't seem great, so +1 from me, >>> although I don't use these so my interest is mostly theoretical. >>> >>> On Thu, May 20, 2021, 8:20 AM Alan Woodward <romseyg...@gmail.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> I’m preparing a local lucene 9.0 snapshot build and I notice that the >>>> jar files generated by `./gradlew mavenToLocalFolder` are called something >>>> like `lucene-suggest-9.0.0-20210520.111833-1-javadoc.jar` - in other words, >>>> they are including a timestamp. For my setup I’d like to replace this with >>>> the git SHA of the commit the snapshot is based on. So I have two >>>> questions: >>>> >>>> 1) Is there a simple override or gradle property that I can pass on the >>>> command line that will change the output names of artefacts? >>>> 2) I think in general commit SHAs are better than timestamps for >>>> snapshot names - two identical snapshots taken from identical sources at >>>> different times shouldn’t really have different names. Should we look at >>>> changing the existing snapshot generation code to switch to using SHAs? >>>> >>>> - Alan >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>> >> -- >> Uwe Schindler >> Achterdiek 19, 28357 Bremen >> https://www.thetaphi.de > > > -- > Uwe Schindler > Achterdiek 19, 28357 Bremen > https://www.thetaphi.de > > >
