Page History

...

If a contributor of a pull request will be unable to perform the integration at a suitable time, they may delegate the ability to integrate to any other committer in the project. This is done using /integrate delegate. Issuing this command will not immediately integrate a pull request, instead any committer in the project will be able to issue the /integrate command to perform the integration. This can be undone by the original contributor running /integrate undelegate.

...

Examples

• /integrate
• /integrate 38d3c3d937675ac5d550659825b7e99ed1eb3921

...

Marks you as the sponsor of the pull request and integrates the pull request. A contributor who is not a Committer must first issues the /integrate pull request command to mark a pull request as ready for integration. Once the pull request author has issued the /integrate pull request command, a Committer must then issue the /sponsor pull request command to integrate the pull request. The /sponsor pull request take an optional hash for atomic integrations, just like the /integrate pull request command.

Examples

• /sponsor
• /sponsor 38d3c3d937675ac5d550659825b7e99ed1eb3921

...

Mark or clear one or more issues, in addition to the one specified in the pull request title, as solved by this pull request. The default action is to mark an issue as being solved. All issues solved by the pull request will be part of the resulting commit message. An issue that has wrongly been marked as solved by this pull request can be removed by the command /issue remove <id>. It is allowed to prefix the issue numeric id with the JBS project name, but it is not necessary. This command can only be used to modify the list the additional issues, not the main issue defined in the pull request title.

Examples

• /issue JDK-4567890
• /solves JDK-456789
• /issue add JDK-4567890
• /issue add 4567890
• /issue add 1234567,4567890
• /issue remove JDK-4567890

...

Add a summary section to the resulting commit message of the pull request. For details on the commit message syntax, see JEP 357. A summary command alone without any text will remove an existing summary. Only use this command to add an additional summary message to a commit. It should not be used to add issues or reviewer attributions as those are handled separately and automatically.

Examples

• /summary This is a one-line summary
• /summary
This is a multi-line summary.
You can add as many lines as you like.
• /summary
This is a multi-line, multi-paragraph summary.
You can have as many lines and as many paragraphs as you like.

This is the first line second paragraph,
and this is the second line in the second paragraph.
• /summary

...

Adds or removes a user as a contributor to this pull request. A contributor can be specified either by their GitHub username (e.g. @openjdk-bot), their OpenJDK username (e.g. duke) or via a full name and email combination (e.g. J. Duke <duke@openjdk.org>). Github and OpenJDK usernames can only be used for users in the OpenJDK census. For other contributors you need to supply the full name and email address. A contributor that has incorrectly been listed as a contributor can be unlisted by issuing the command /contributor remove <id>. The contributors will be included in the final commit message for the pull request. For full details on the commit message syntax see JEP 357.

Examples

• /contributor add ehelin
• /contributor add @edvbld
• /contributor add J. Duke <duke@openjdk.org>
• /contributor remove @edvbld
• /contributor remove rwestberg
• /contributor remove J. Duke <duke@openjdk.org>

...

Requires that the pull requested has a JBS issue associated and that the JBS issue has a CSR request associated with it and that the CSR request is approved before the pull request can be integrated.

Examples

• /csr needed
• /csr unneeded
• /csr

...

Declares that this pull request is part of a JDK Enhancement Proposal. The linked JEP needs to be targeted before the pull request can be integrated. The command can be issued by the pull request author or a reviewer.

Examples

• /jep JDK-1234567
• /jep JEP-123
• /jep unneeded

...

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

...

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. Any additional invocations of this command completely supersedes any previous invocations.

Examples

• /reviewers 2
• /reviewers 3 reviewer

...

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. Note that only labels associated with mailing lists can be controlled with this command and not Skara specific labels which are controlled by the bots or other specific commands (e.g. clean, rfr).

Examples

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

...

Shows help for all pull request commands.

Examples

• /help