-
Notifications
You must be signed in to change notification settings - Fork 996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java SDK release script #406
Java SDK release script #406
Conversation
So user or CI system can easily override revision from external sources such as Git tag name
This plugin is useful during deployment so the final pom is resolved without parent dependency, i.e. we do not necessarily need to upload parent library
So it has newer features and more fixes
…(required for releasing library
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: davidheryanto The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@davidheryanto thanks for this! Can I ask that we move these scripts to |
Okay sure. |
/retest |
1 similar comment
/retest |
/lgtm |
/retest |
@davidheryanto: Updated the
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Should this be backported for publishing v0.3 SDK? |
Actually maybe it'd be easiest for me to bring it into #407? |
* Use Nexus staging plugin for deployment (#394) * Use Nexus staging pluging for deployment * Fix Javadoc error * Hard coded parent version as variable substitution is not supported * Introduce datatypes/java module for proto generation Rather than the Maven protobuf plugin running on the same symlinked definitions in several Java modules, localize this process into one module that the others depend on. This provides a single module that can be depended on by third-party extensions with the bare minimum of dependencies. Also removes proto files that are no longer used. * Java SDK release script (#406) * Use back revision variable in pom.xml So user or CI system can easily override revision from external sources such as Git tag name * Add flatten maven plugin This plugin is useful during deployment so the final pom is resolved without parent dependency, i.e. we do not necessarily need to upload parent library * Increase versions for maven source,javadoc,spotless plugins So it has newer features and more fixes * Add gpg-plugin needed to sign releases * Use oss configure for flatten plugin, add developers info in pom.xml (required for releasing library * Add publish-java-sdk script * Add more logs to publish-java-sdk.sh * Add ProwJob publish-java-sdk * Use GPG_KEY_IMPORT_DIR variable * Update revision in pom.xml to 0.4.2-SNAPSHOT * Publish datatypes/java along with sdk/java Co-authored-by: Khor Shu Heng <32997938+khorshuheng@users.noreply.github.com> Co-authored-by: David Heryanto <david.heryanto@hotmail.com>
This pull request adds a script and ProwJob to release Feast Java SDK to Maven Central upon creation of new release tags.
I reverted the changes in #394 where the revision value in
pom.xml
is provided explicitly. I use our previous approach where we set therevision
property, which will then substitute${revision}
placeholder inpom.xml
in different modules. Reference: https://maven.apache.org/maven-ci-friendly.htmlThis is so that the CI script can more easily override the revision from external value e.g. from latest Git tag, like so
mvn -Drevision=$GIT_TAG
. This approach ensures that Git tag is the source of truth of the released version number. Updating the<version>
tag manually on allpom.xml
upon new version release is arguably more error prone e.g. we miss one file by accident.I add flatten-maven-plugin that generates a flattened version of
pom.xml
during deployment. This is useful since our Java SDK depends on the parent module where the version is provided via${revision}
variable. This flattened pom ensures that these dependencies can be resolved.I also add maven-gpg-plugin to sign the components. This is required when releasing libraries to Maven Central.