Skip to content
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

Merged

Conversation

davidheryanto
Copy link
Collaborator

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 the revision property, which will then substitute ${revision}placeholder in pom.xml in different modules. Reference: https://maven.apache.org/maven-ci-friendly.html

This 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 all pom.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.

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
@feast-ci-bot
Copy link
Collaborator

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@woop
Copy link
Member

woop commented Jan 4, 2020

@davidheryanto thanks for this!

Can I ask that we move these scripts to infra/scripts or something similar?

@davidheryanto
Copy link
Collaborator Author

Okay sure.
I'll move the CI script into infra folder in another pull request so it's easier to track the changes.

pom.xml Outdated Show resolved Hide resolved
@zhilingc
Copy link
Collaborator

zhilingc commented Jan 6, 2020

/retest

1 similar comment
@davidheryanto
Copy link
Collaborator Author

/retest

@zhilingc
Copy link
Collaborator

zhilingc commented Jan 7, 2020

/lgtm

@zhilingc
Copy link
Collaborator

zhilingc commented Jan 7, 2020

/retest

@feast-ci-bot feast-ci-bot merged commit ec6b26b into feast-dev:master Jan 7, 2020
@feast-ci-bot
Copy link
Collaborator

@davidheryanto: Updated the config configmap in namespace default at cluster default using the following files:

  • key config.yaml using file .prow/config.yaml

In response to this:

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 the revision property, which will then substitute ${revision}placeholder in pom.xml in different modules. Reference: https://maven.apache.org/maven-ci-friendly.html

This 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 all pom.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.

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.

@ches
Copy link
Member

ches commented Jan 7, 2020

Should this be backported for publishing v0.3 SDK?

@ches
Copy link
Member

ches commented Jan 7, 2020

Actually maybe it'd be easiest for me to bring it into #407?

@davidheryanto
Copy link
Collaborator Author

@ches yes sounds good we can backport it in #407
Thanks

feast-ci-bot pushed a commit that referenced this pull request Jan 8, 2020
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants