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

Set Maven build requirements and some project POM metadata #267

Merged
merged 2 commits into from
Oct 24, 2019
Merged

Set Maven build requirements and some project POM metadata #267

merged 2 commits into from
Oct 24, 2019

Conversation

ches
Copy link
Member

@ches ches commented Oct 23, 2019

A goal of #262 was to standardize versions of dependencies used across modules in the project. If everyone is on board with that, then we want to avoid re-declaring versions outside of <dependencyManagement>.

If you're not used to <dependencyManagement> it may help to think of it this way: it defines dependencies, while <dependency> references in modules "instantiate" them.

Maven's Enforcer plugin provides a rule that detects duplicate dependency definitions and fails the build early. This adds a bit of friction nudging developers to understand this way of working. My feeling is this friction is more than worth the sum frustration of dependency hell that it can relieve over time.

I'll have some additions to CONTRIBUTING.md coming sooner or later, if you think this warrants a note there I can make that sooner.

(Enforcer has another useful dependencyConvergence rule, but it's going to take a good bit of work to determine if all the divergences it currently reports can be safely resolved, and integration tests will help).

The PR enables a couple of other build sanity checks with rationale in the commit message, and some project metadata that you may want to tweak but I started as placeholders at least.

@feast-ci-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ches
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: thirteen37

If they are not already assigned, you can assign the PR to them by writing /assign @thirteen37 in a comment when ready.

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

@feast-ci-bot
Copy link
Collaborator

Hi @ches. Thanks for your PR.

I'm waiting for a gojek member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

@woop
Copy link
Member

woop commented Oct 23, 2019

Thanks @ches

This definitely seems like something we want our tooling to do for us, especially if we want to accept contributions from the community. So thanks for adding it. We are simultaneously shifting our focus to updating our automated testing as well. Once that is done we will be able to guard ourselves from bad builds when new PRs are submitted.

@woop
Copy link
Member

woop commented Oct 23, 2019

On a related note, we are still pushing code directly to this branch at the moment. Once the release is out we will all revert to using PRs for any new code submissions.

Urge the use of <dependencyManagement> by disallowing duplicate
dependency declarations. See #262.

Making final releases with SNAPSHOT dependencies in use is a really bad
idea that can happen by accidental oversight. Enforcer helps ensure it
doesn't.

For build reproducibility it's good to specify what Maven versions are
supported for the project's build to work. 3.0.5 is the minimum required
version by all our plugins currently, according to:

    $ mvn versions:display-plugin-updates
@woop woop merged commit aacb264 into feast-dev:0.3-dev Oct 24, 2019
@feast-ci-bot
Copy link
Collaborator

@ches: The following tests failed, say /retest to rerun them all:

Test name Commit Details Rerun command
test-core-and-ingestion 2ff6d32 link /test test-core-and-ingestion
test-serving 2ff6d32 link /test test-serving
test-python-sdk 2ff6d32 link /test test-python-sdk
test-java-sdk 2ff6d32 link /test test-java-sdk
test-golang-sdk 2ff6d32 link /test test-golang-sdk
test-end-to-end 2ff6d32 link /test test-end-to-end

Full PR test history

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. I understand the commands that are listed here.

@ches ches deleted the build-reqs branch October 25, 2019 07:50
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.

3 participants