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

feat(gradle-lite): JS-based Gradle manager #7521

Merged
merged 38 commits into from
Dec 8, 2020

Conversation

zharinov
Copy link
Collaborator

@zharinov zharinov commented Oct 22, 2020

Closes #3608, #7300, #7112

@zharinov
Copy link
Collaborator Author

Ready for test runs, more thorough testing is required currently

@rarkins
Copy link
Collaborator

rarkins commented Oct 25, 2020

Challenge: could we rewrite this to be like a normal manager that takes one file instead of all files? so e.g. fileMatch will be for build.gradle. I know that each file would need to check for a "parent" etc but is there anything stopping us doing it that way?

@zharinov
Copy link
Collaborator Author

Technically, it's possible at the cost of missing upgrades for external variables.

But later, I think these upgrades can be handled too, if (1) we provide some way to sort packageFile in the same order Gradle would parse them and if (2) we can manage some per-repo and per-manager internal state between two extractDependencies() calls (i.e. variable registry). For autoreplace, we additionally would need (3) some way to point to the right file for replace.

@zharinov
Copy link
Collaborator Author

Actually, I tried to rely on autoreplace feature here, but then realized it won't work without per-file extraction.

@viceice
Copy link
Member

viceice commented Oct 25, 2020

Maybe we need to allow to return an additional optional target file string to support this. If I remember correctly we could use that in gitlab-include manager too.

@zharinov zharinov marked this pull request as ready for review October 25, 2020 10:43
fileReplacePosition: variable.fileReplacePosition,
packageFile: variable.packageFile,
};
dep.groupName = variable.key;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ref: #6474

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The potential problem here: same variable names in different files.
Possible solution: use packageFile in group name.

Comment on lines +25 to +39
export function isDependencyString(input: string): boolean {
const split = input?.split(':');
if (split?.length !== 3) {
return false;
}
const [groupId, artifactId, versionPart] = split;
return (
groupId &&
artifactId &&
versionPart &&
artifactRegex.test(groupId) &&
artifactRegex.test(artifactId) &&
versionPart === versionLikeSubstring(versionPart)
);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't match the alternative form of group: "com.example", name: "my.dependency", version: "1.2.3"

Copy link
Collaborator Author

@zharinov zharinov Oct 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

group: "com.example", name: "my.dependency", version: "1.2.3"

Can these named parameters go in any order?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, i think so. If i remember correctly it's like a hashtable, so order doesn't matter

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I think it's out of scope for now

@rarkins
Copy link
Collaborator

rarkins commented Nov 30, 2020

Let's aim to merge this disabled by default, so it's lowest risk. Then hopefully we get some feedback and can decide how to handle the two managers simultaneously.

@viceice
Copy link
Member

viceice commented Nov 30, 2020

yeah, I can enable it on my gradle repo's to validate, currently only one major update awaiting approval. But have soma basic test repos on github too

@rarkins
Copy link
Collaborator

rarkins commented Nov 30, 2020

Another alternative: let gradle-lite "replace" gradle on a per-dependency basis. e.g. if name/version/etc match then essentially delete the extracted dep from gradle and update it using gradle-lite instead. That way we can easily see which dependencies are found by gradle but missed by gradle-lite.

@zharinov
Copy link
Collaborator Author

Two points that potentially may complicate "wrapping" solution:

  • Gradle report contains lots of transitive dependencies, it may be hard to filter them from deps missed by gradle-lite
  • Recent gradle bugs are related to wrong update function, i.e. packages are detected but not updated correctly

@rarkins
Copy link
Collaborator

rarkins commented Nov 30, 2020

  • Gradle report contains lots of transitive dependencies, it may be hard to filter them from deps missed by gradle-lite

We can't update transitive dependencies, so how does the logic flow work today? e.g. do we still do a lookup and then attempt to update them but fail to update? Or is there a way that the existing manager filters them prior to update?

  • Recent gradle bugs are related to wrong update function, i.e. packages are detected but not updated correctly

So we should see some updates working correctly now rather than before, assuming the new manager detects them?

Copy link
Member

@viceice viceice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some suggestions, otherwise LGTM. I've not checked every line, as this is very big pr. Best is to merge it as disabled / beta feature. I'm happy to test it on my gradle repo to see it in action. 🙃

lib/manager/common.ts Show resolved Hide resolved
lib/manager/gradle-lite/index.ts Show resolved Hide resolved
@@ -0,0 +1 @@
This is an alternate manager for Gradle, written completely in JavaScript.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add some more description, so users are welcome to disable default gradle and test this new manager, as we plan to replace to old in future.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My additions are not ideal, but at least someone can correct me instead of writing from scratch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe @HonkingGoose has some time to review this 🙃

Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
@rarkins
Copy link
Collaborator

rarkins commented Dec 4, 2020

@zharinov what's the expected result when both gradle managers are enabled at the same time? e.g is there a predictable order of which manager updates first? Is it handled gracefully? Are the updates de-duplicated in the PR description?

viceice
viceice previously approved these changes Dec 7, 2020
Copy link
Member

@viceice viceice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM to me

@@ -0,0 +1 @@
This is an alternate manager for Gradle, written completely in JavaScript.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe @HonkingGoose has some time to review this 🙃

@zharinov
Copy link
Collaborator Author

zharinov commented Dec 7, 2020

I guess, it's a good time to release it. From this point, all bugs can be handled as separate issues.

Co-authored-by: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Copy link
Member

@viceice viceice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Time to merge this 🙃

@JamieMagee
Copy link
Contributor

I'm very interested to see how this goes! 🎉

@rarkins rarkins merged commit c43a4dc into renovatebot:master Dec 8, 2020
@rarkins rarkins deleted the feat/gradle-lite branch December 8, 2020 12:56
@renovate-release
Copy link
Collaborator

🎉 This PR is included in version 23.97.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement JS-based Gradle manager
6 participants