[JSDK-9] Public releases and CI changes#79
Conversation
| task sourcesJar(type: Jar) { | ||
| from sourceSets.main.allJava | ||
| archiveClassifier = 'sources' | ||
| } | ||
|
|
||
| task javadocJar(type: Jar) { | ||
| from javadoc | ||
| archiveClassifier = 'javadoc' | ||
| } | ||
|
|
There was a problem hiding this comment.
required to publish to maven central
| signing { | ||
| def signingKey = System.getenv('SONATYPE_GPG_KEY') | ||
| def signingPassword = System.getenv('SONATYPE_GPG_PASSPHRASE') | ||
| useInMemoryPgpKeys(signingKey, signingPassword) | ||
| sign publishing.publications.mavenJava | ||
| } |
There was a problem hiding this comment.
required by maven central
|
Generally speaking LGTM, just a couple of notes reg unstable releases:
|
I think this is a valid point, but AFAIK this is the direction we want to take with unstable releases going forward: we don't want to keep them secret, as long as they're auto consistent and all the tests (unit, integration and acceptance) gave us green lights. A developer using a SNAPSHOT release, by definition, should be aware of the fact that what he/she is using is not final, but we can definitely make it clearer on our README.
This can indeed happen. Do you have any suggestion already to avoid such scenario ? This would lead to something like |
I think this would work fine, good idea 👍 I'd probably stick with the |
Implemented, this is the outcome on the snapshot repo!
Finally, there's also another advantage in using a version like |
2 participants
Disclaimer
Contents
com.truelayerRelease process changes proposal
Current problems
Proposed changes
General changes
versionkey contained in the gradle.properties file as version-to-be-deployedUnstable releases
https://s01.oss.sonatype.org/content/repositories/snapshots/) amongst the repositories and a dependency to our lib following the SNAPSHOT format, i.e.com.truelayer:trulayer-java:0.0.2-SNAPSHOT. With this approach we can release to external devs new artifacts without the need of explicit releases/tagsgradle.propertiesfile will have to contain a version in the$major.$minor.$buildformat, ie without-SNAPSHOTsuffixes. This is meant to ease the merge to the main branch later: we don't have to change the version right before or after merging to the main branchThe declared version should not be already released as final version on Maven Central. For instance: if we already released awill see if it makes sense in futurecom.truelayer:trulayer-java:0.0.3a workflow with versioncom.truelayer:trulayer-java:0.0.3in the gradle.properties will fail - the following HTTP request has to return 404:https://repo1.maven.org/maven2/com/truelayer/truelayer-java/$version/truelayer-java-$version.pomgradle.propertiesfile ) will be released on every push on non main branches. Our CI will add a-SNAPSHOTsuffix to the declared version and display on the GH WF what snapshot version we're packaging and publishing exactly. Gradle will automatically replace theSNAPSHOTlabel with the current timestamp at artifact packaging time. The same tooling will make sure that the latest timestamp available will be used when declaring aSNAPSHOTdependency in a project.Final releases
The first step after the usual checkout and gradle wrapper validation will be to verify the project version against the Maven Central repository. If a final release already exists with the same version the WF will fail. the following HTTP request has to return 404:will see if it makes sense in futurehttps://repo1.maven.org/maven2/com/truelayer/truelayer-java/$version/truelayer-java-$version.pomBe careful
❗ Before making our repo public we should triple check that external collaborators can only contribute by creating a fork and a PR originating from that. Moreover, we should make sure that external collaborator can't access our repo secrets nor execute GH workflow without our explicit approval. See this chapter for more details.