Skip to content

Add UnsupportedCommand: Handling unsupported additional behavior of git operations in JGit#937

Closed
rishabhBudhouliya wants to merge 39 commits intojenkinsci:masterfrom
rishabhBudhouliya:add-decorate-tool
Closed

Add UnsupportedCommand: Handling unsupported additional behavior of git operations in JGit#937
rishabhBudhouliya wants to merge 39 commits intojenkinsci:masterfrom
rishabhBudhouliya:add-decorate-tool

Conversation

@rishabhBudhouliya
Copy link
Contributor

@rishabhBudhouliya rishabhBudhouliya commented Aug 5, 2020

Enabling GitToolChooser to recommend a git implementation knowing if the implementation is compatible with certain features of git

The introduction of UnsupportedCommand allows us to solve cases where JGit might not be supported and GitToolChooser might suggest JGit because of the size rule. The GitToolChooser can use this command to know if JGit can be user or not.

This working of this command and its usage has been explained below:

Using UnsupportedCommand in Git Plugin

  • Add a method in GitSCMExtension: determineSupportForJGit
    This method acts as a way for the extensions to convey their support for JGit over certain functionalities.

  • Add implementation of determineSupportForGit for various extensions: GitLFSPull, SparseCheckoutPaths, SubmoduleOption, CheckoutOption etc.
    These implementations will put information into an unsupportedCommand object about the compatibility of a certain extension feature with JGit.

  • An example of how GitToolChooser will work within the Git Plugin
    Refer to this commit.

Checklist

  • I have read the CONTRIBUTING doc
  • I have referenced the Jira issue related to my changes in one or more commit messages
  • I have added tests that verify my changes
  • Unit tests pass locally with my changes
  • I have added documentation as necessary
  • No Javadoc warnings were introduced with my changes
  • No spotbugs warnings were introduced with my changes
  • Documentation in README has been updated as necessary
  • Online help has been added and reviewed for any new or modified fields
  • I have interactively tested my changes
  • Any dependent changes have been merged and published in upstream modules (like git-client-plugin)

Types of changes

  • New feature (non-breaking change which adds functionality)

Further comments

If this is a relatively large or complex change, start the discussion by explaining why you chose the solution you did and what alternatives you considered.

a "NONE" string
Also, size which is decided to switch implementation has been increased
to 50K because 5 MiB is experimentally an approximation where behavior
of jgit starts to change.
Note: The current test cases target only the scenario with heuristic 1,
i.e the cache determination option.
a "NONE" string
Also, size which is decided to switch implementation has been increased
to 50K because 5 MiB is experimentally an approximation where behavior
of jgit starts to change.
Note: The current test cases target only the scenario with heuristic 1,
i.e the cache determination option.
- Change in design of handling extension API results:
Add the ability to throw exceptions for `getSizeOfRepository` in the
Extension Point.
Add additional checks on receiving the results from implemented
extensions to look for a non-zero without exceptions "size" result
from other plugins implementing the extension point.
- Having no cache but available extensions from other plugins
- Having a cached directory to recommend the appropriate git implementation
- In the event of having an extension:
	- Returning size > 5 MiB
	- Returning size < 5 MiB
	- Not applicable to the provided remote URL from git plugin
	- Throwing exceptions while estimating the size of repo
… repo URL,

the plugin will get the size from the first one.

Ideally, for a particular remote URL - only one plugin should return size of the
repository.
The process of recommending an optimal git impl is in two stages:
Stage 1: Determine if the user additional behavior contains a feature which is not supported
by JGit - see UnsupportedCommand usage
Stage 2: Instantiating GitToolChooser to recommend a git tool
Here, the GitToolChooser uses the repository URL to determine a recommendation for the git
implementation.
This method can be called by an extension to convey if a certain extension
feature is supported by JGit or not.

After this information is provided by the an extenions or multiple extensions, the
command can determine if JGit is to be used or not.

Even if one extension is not supporting a feature, JGit will not be recommended.
By implementing this method, this extension is conveying that in the case a user wants to use
timeout, JGit will not be able to perform the git client operations as it is not yet supported.
…le feature

While instantiating the class using a repo url, the class will also need a decision to determine
if JGit has to be recommended in the case of a scenario where an extension is not supported by
JGit.
@MarkEWaite MarkEWaite added the enhancement Improvement or new feature label Aug 8, 2020
Copy link
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

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

Ready to use released git client plugin. Other comments are optional.

<dependency>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>git-client</artifactId>
<version>3.3.3-SNAPSHOT</version>
Copy link
Contributor

Choose a reason for hiding this comment

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

Released Aug 13, 2020.

Suggested change
<version>3.3.3-SNAPSHOT</version>
<version>3.4.0</version>

ext.determineSupportForJGit(this, unsupportedCommand);
}

listener.getLogger().println("Using Performance Improvement");
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this inferred by the next message?

Suggested change
listener.getLogger().println("Using Performance Improvement");

}

/**
* Called when support of JGit for a particular or multiple extensions is to be determined
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* Called when support of JGit for a particular or multiple extensions is to be determined
* Called when support of JGit for a particular or multiple extensions is to be determined.
* Updates the passed unsupportedCommand with the evaluation results.

/**
* Called when support of JGit for a particular or multiple extensions is to be determined
* @param scm GitSCM object
* @param unsupportedCommand UnsupportedCommand object
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* @param unsupportedCommand UnsupportedCommand object
* @param unsupportedCommand UnsupportedCommand used to report compatibility of requested extensions with the potential git implementations

@Override
public void determineSupportForJGit(GitSCM scm, UnsupportedCommand cmd) {
List<RemoteConfig> repos = scm.getRepositories();
cmd.lfsRemote(repos.get(0).getName());
Copy link
Contributor

Choose a reason for hiding this comment

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

Since repos.get() returns a list of entries, shouldn't this iterate over the list?

Suggested change
cmd.lfsRemote(repos.get(0).getName());
cmd.lfsRemote(repos.get(0).getName());

title __IMPL's Class Diagram__\n

namespace {
namespace udson.plugins.git {
Copy link
Contributor

Choose a reason for hiding this comment

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

If you're storing a UML representation like this, shouldn't the namespace match the package name?

Suggested change
namespace udson.plugins.git {
namespace hudson.plugins.git {

@omkar-dsd
Copy link

omkar-dsd commented Aug 19, 2020

Carry Forwarded to #931 . This PR can be closed.

@MarkEWaite
Copy link
Contributor

Closed in favor of #931

@MarkEWaite MarkEWaite closed this Aug 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Improvement or new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants