Project Skara provides contributors and reviewers with additional pull request commands that enable additional functionality. A pull request command is a comment made to a pull request that starts with a slash ("/"), for example "/integrate", "/csr" or "/sponsor".
Commands
/integrate
Syntax
/integrate [<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 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 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 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.
Examples
/integrate/integrate 38d3c3d937675ac5d550659825b7e99ed1eb3921
/sponsor
Syntax
/sponsor
Description
Marks you as the sponsor of the pull request. A pull request made by a contributor who is not a Committer can not issue the /integrate command until a Committer in the project has issued the /sponsor command.
Examples
/sponsor
/issue
Syntax
/issue [add|remove] <id>[,<id>,...]
Description
Marks one or more issues as solved by this pull request. 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.
Examples
/issue add JDK-4567890/issue add 4567890/issue add 1234567,4567890/issue remove JDK-4567890
/summary
Syntax
/summary .*
Description
Add a summary section to the resulting commit message of the pull request. For details on the commit message syntax, see JEP 357.
Examples
/summary This is a one-line summary/summaryThis is a multi-line summary.You can add as many lines as you like./summaryThis 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.
/contributor
Syntax
/contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]
Description
Marks another 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>). 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 @edvbld/contributor add rwestberg/contributor add J. Duke <duke@openjdk.org>/contributor remove @edvbld/contributor remove rwestberg/contributor remove J. Duke <duke@openjdk.org>
/csr
Syntax
/csr
Description
Requires that the pull requested has a JBS issue associated and that the JBS issue has CSR request associated with it and that the CSR request is approved before the pull request can be integrated.
Examples
/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 [add|remove] <username>[,<username>,...]
Description
Marks one or more users as reviewers of the 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 project allows the pull request author to add additional reviewers to the pull request. A reviewer can also be removed by issuing the /reviewer remove command.
Examples
/reviewer add @edvbld/reviewer add ehelin/reviewer remove ehelin
/cc
Syntax
/cc <list>[,<list>,...]
Description
Adds one or more allowed labels to the pull requeset. Labels have the same name as 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
/cc hotspot-gc hotspot-runtime/cc core-libs
Overview
Content Tools
ThemeBuilder