Skip to content

Latest commit

 

History

History
91 lines (59 loc) · 4.8 KB

CONTRIBUTING.adoc

File metadata and controls

91 lines (59 loc) · 4.8 KB
Raw

Contributing to the Git Client Plugin

The git client plugin implements the Jenkins SCM API. Refer to the SCM API documentation for plugin naming conventions and for the preferred locations of new functionality.

Preparing a pull request

Plugin source code is hosted on GitHub. New feature proposals and bug fix proposals should be submitted as GitHub pull requests. Your pull request will be evaluated by the Jenkins job.

Before submitting your change, please assure that you’ve added tests which verify your change. There have been many developers involved in the git client plugin and there are many, many users who depend on the git client plugin. Tests help us assure that we’re delivering a reliable plugin, and that we’ve communicated our intent to other developers as executable descriptions of plugin behavior.

Compiling and testing the plugin

Compile and run the plugin automated tests on Java 11 or Java 17 with:

  • mvn clean verify

Run the plugin inside a Jenkins environment with the maven hpi plugin:

  • mvn -Djetty.port=8080 hpi:run

Code coverage reporting

Code coverage reporting is available as a maven target. Please improve code coverage with tests when you submit.

  • mvn -P enable-jacoco clean install jacoco:report to report code coverage

Spotbugs checks

Please don’t introduce new spotbugs output.

  • mvn spotbugs:check to analyze project using Spotbugs.

  • mvn spotbugs:gui to review Spotbugs report using GUI

Code formatting

Source code and pom file formatting is maintained by the spotless maven plugin. Before submitting a pull request, confirm the formatting is correct with:

  • mvn spotless:apply

Reviewing Pull Requests

Maintainers triage pull requests by reviewing them and by assigning labels. Release drafter uses the labels to automate release notes.

Others are encouraged to review pull requests, test pull request builds, and report their results in the pull request.

Testing a Pull Request Build

Pull request builds merge the most recent changes from their target branch with the change proposed in the pull request. They can be downloaded from ci.jenkins.io and used to test the pull request. Steps to test a pull request build are:

  1. Find the pull request on GitHub - for example, pull request 467

  2. Find the ci.jenkins.io artifacts for that pull request from the link to the artifacts in the Jenkins job in "Show all checks"

  3. Download the hpi file (like git-client-3.0.1-rc3444.b3d767e3d46a.hpi) to your computer

  4. Upload the hpi file to Jenkins from the Jenkins Plugin Manager

  5. Restart your Jenkins and you’re ready to test

Reviewing Bug Reports

Git client plugin bug reports are assigned to one of the maintainers by default. Open bug reports assigned to a maintainer are assumed to have not been reviewed. When a maintainer completes review of an issue, they include a comment on the bug report and set the 'Assignee' to 'Unassigned'.

Others are welcome to review bug reports, comment on the results of the review, and set the 'Assignee' to 'Unassigned'. Typical bug review tasks include:

  • Review summary and description

  • Attempt to duplicate the issue

  • Add a comment with results of the attempt to duplicate the issue

Java Microbenchmark Harness

Git client plugin includes Java Microbenchmark Harness (JMH) benchmark tests to compare the performance of command line git and JGit. Run the benchmarks with the command:

  • mvn -P jmh-benchmark -Dbenchmark.run=true test

The results can be reviewed visiually by pasting the resulting jmh-report.json file into the online JMH visualizer.