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

Allow tests with shallow clone of source repository #1365

Merged

Conversation

MarkEWaite
Copy link
Contributor

Allow tests with shallow clone of source repository

One test class uses the history of the git plugin to test various conditions in the GitRepositoryBrowser class. Accept that those cases are not tested when the tests are running from a shallow clone.

Allow the plugin compatibility tests and other automated test environments to use a shallow clone of the repository for tests. The test conditions that are skipped as a result of this change are much less important than keeping test environments simple and consistent.

Checklist

  • I have read the CONTRIBUTING doc
  • 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
  • Any dependent changes have been merged and published in upstream modules (like git-client-plugin)

Types of changes

  • Test improvement

One test class uses the history of the git plugin to test various
conditions in the GitRepositoryBrowser class.  Accept that those cases
are not tested when the tests are running from a shallow clone.
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

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

OK for a hotfix. In general if you want to have some predefined Git repository available for tests to work on, it would be better to either

  • Set up the repo from scratch (assuming dates, commit hashes, etc. are irrelevant).
  • Use git bundle create …-plugin/src/test/resources/xxx.bundle master to archive an example repo, and then have a test setup method run git clone -b master …-plugin/src/test/resources/xxx.bundle.

GitClient git = Git.with(TaskListener.NULL, new EnvVars()).getClient();
headCommit = git.revParse("HEAD");
} catch (IOException | InterruptedException e) {
headCommit = ObjectId.fromString("016407404eeda093385ba2ebe9557068b519b669"); // simple commit
Copy link
Member

Choose a reason for hiding this comment

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

MarkEWaite added a commit to MarkEWaite/git-client-plugin that referenced this pull request Dec 5, 2022
Do not attempt to use the local repository as a reference repository
when the local repository is a shallow clone.  A shallow clone
repository has no content to offer as a reference.

Fixes 64 test failures when the test repository is a shallow clone.

jenkinsci/bom#1613 describes the experiment to
run the plugin compatibility tests with shallow clones.

jenkinsci/git-plugin#1365 implemented a similar
change in the git plugin so that shallow cloned repositories will not
fail the tests in that plugin.

Will make a few tests in a shallow repository a little slower because
they will require a full clone of the git client plugin repository
rather than reusing the existing clone in the test workspace.  Doubtful
that the performance difference will be detectable within the general
variability of CI test jobs.
MarkEWaite added a commit to jenkinsci/git-client-plugin that referenced this pull request Dec 5, 2022
Do not attempt to use the local repository as a reference repository
when the local repository is a shallow clone.  A shallow clone
repository has no content to offer as a reference.

Fixes 64 test failures when the test repository is a shallow clone.

jenkinsci/bom#1613 describes the experiment to
run the plugin compatibility tests with shallow clones.

jenkinsci/git-plugin#1365 implemented a similar
change in the git plugin so that shallow cloned repositories will not
fail the tests in that plugin.

Will make a few tests in a shallow repository a little slower because
they will require a full clone of the git client plugin repository
rather than reusing the existing clone in the test workspace.  Doubtful
that the performance difference will be detectable within the general
variability of CI test jobs.
MarkEWaite added a commit to jenkinsci/git-client-plugin that referenced this pull request Dec 13, 2022
Do not attempt to use the local repository as a reference repository
when the local repository is a shallow clone.  A shallow clone
repository has no content to offer as a reference.

Fixes 64 test failures when the test repository is a shallow clone.

jenkinsci/bom#1613 describes the experiment to
run the plugin compatibility tests with shallow clones.

jenkinsci/git-plugin#1365 implemented a similar
change in the git plugin so that shallow cloned repositories will not
fail the tests in that plugin.

Will make a few tests in a shallow repository a little slower because
they will require a full clone of the git client plugin repository
rather than reusing the existing clone in the test workspace.  Doubtful
that the performance difference will be detectable within the general
variability of CI test jobs.

(cherry picked from commit 5c98434)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants