Page History

...

/integrate

Syntax

/integrate [auto|defer|undefer|<hash>]

Description

The pull request command that all contributors will use is the /integrate command that integrates an approved pull request into a repository. This is a an example where the Skara workflow differs slightly from the workflow offered by most external Git source code hosting providers - almost all external Git source code hosting providers require that a reviewer/maintainer integrates a pull request into a repository. Skara instead enables the contributor to integrate the pull request with the /integrate command, but the contributor can only issue the /integrate command once the pull request passes all pre-integration checks (e.g. jcheck).

The /integrate command will by default squash all commits in the pull request into one, rebase the resulting commit on top of the target branch and automatically create an appropriate commit message. The squashing of all commits in the pull request enables contributors to update a pull request by simply pushing to the branch in the contributor's personal fork the pull request was created from. The rebasing of the resulting commit enables contributors to simply merge the target branch into the source branch for the pull request whenever changes from the target branch needs to be incorporated (instead of doing complicated rebases and force pushes). The automatic formatting of the commit message frees contributors from having to consider the details of the commit message format.

An A hash can be supplied to /integrate and in that case an atomic integration is performed. An atomic integration squashes and rebases on the commits on top of the given hash, and then tries to push the result. An atomic integration will fail if the supplied hash is not the head of the target branch at the moment of the push. This mean means that you can be sure that if you supply a hash to /integrate, then your pull request will only be squashed and rebased on top of the given commit, nothing else. This can be useful for large and complicated changes when you are unsure about potential conflicts with other commits.

The auto parameter is used to label a pull request to be automatically integrated as soon as all pre-integration checks are passing. This can be a good idea to save time when a change is comparatively benign and only the minimum amount of review is needed.

If a contributor of a pull request will be unable to perform the integration at a suitable time, they may defer the ability to integrate to any other committer in the project. This is done using /integrate defer. Once performed, any committer in the project is able to issue the /integrate command in the affected pull request. This can be undone by the contributor running /integrate undefer.

Examples

• /integrate
• /integrate 38d3c3d937675ac5d550659825b7e99ed1eb3921

...

• /csr needed
• /csr unneeded
• /csr

/test

Syntax

/test [builds|tier1]

Description

A request for a continuous integration system to build the pull request and test the produced build. Note that there is no specification nor any guarantee regarding which platforms the pull request might be built on, nor which tests are run on which platforms.

Examples

• /test builds
• /test tier1
• /test

/reviewer

Syntax

/reviewer (credit|remove) <username>[,<username>,...]

Description

Give additional users credit for reviewing a pull request. The usernames can either be a username of the source code hosting provider (e.g. a GitHub username) or an OpenJDK username. Note that not all OpenJDK projects allows the pull request author to credit additional reviewers. A reviewer credited via /reviewer credit will not count as a verified reviewer and some OpenJDK projects do not count unverified reviewers as enough for integration. A reviewer can be removed by issuing the /reviewer remove command.

Examples

• /reviewer credit @edvbld
• /reviewer credit ehelin
• /reviewer remove ehelin

/reviewers

Syntax

/reviewers N [role]


Description

Require that at least N users with given role (defaults to Author) review the pull request before it can be integrated. The requirements are in addition to the ones specified by the .jcheck/conf file. For example, if the .jcheck/conf file requires 1 Reviewer, then issuing the command "/reviewers 2" means that 1 Reviewer and 1 Author is required to integrate the pull request.

Examples

• /reviewers 2
• /reviewers 3 reviewer

/label

Syntax

/label [add|remove] <label>[,<label>,...]


Alias

/cc


Description

Adds or removes labels on the pull request. If no action is specified, then the action defaults to "add". Labels have the same name as the development mailing lists without the -dev suffix, e.g. the label "hotspot" corresponds to the "hotspot-dev" mailing list. The mailing list bridge will send the RFR e-mail according to the labels on the pull request.

Examples

• /label add hotspot
• /label remove build,core-libs
• /label client
• /cc hotspot-gc hotspot-runtime
• /cc core-libs

/help

Syntax

/help

Description

Shows help for all pull request commands.

Examples

• /help