Page History

...

Note that if you are using Skara on Gitlab, there are built in commands that clash with some of the Skara commands. To enforce use of the Skara command and not the Gitlab variant, you can put some whitespace in front of the command in the comment. Test edit The commands that currently conflict with GitLab commands are /reviewer, /label and /approve.

Commands

/integrate

Syntax

/integrate [auto|delegate|deferundelegate|undefermanual|<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 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 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.

The manual parameter is used to undo the effects of the auto parameter.

If a contributor of a pull request will be unable to perform the integration at a suitable time, they may defer delegate the ability to integrate to any other committer in the project. This is done using /integrate deferdelegate. 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 undeferundelegate.

Examples

• /integrate
• /integrate 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

...

If a pull request is automatically closed due to inactivity, this command can be used to re-open it.

/backport

Syntax

/backport <repository> [<branch>]

/backport disable <repository> [<branch>] 

Description

/backport used in open pull request

When used in an open pull request, the /backport command adds a Backport=repo:branch label to the PR. After the PR is integrated, the bot will create the backport branch and provides a link for creating the backport. To cancel the backport, the user can use /backport disable command to remove the label before the PR is integrated.

Note: /backport disable can only be used in open pull requests.

/backport used in integrated pull request.

Applies the commit this pull request resulted in onto the given branch in the given repository and then shows to a link to create a pull request with the changes. The branch is optional and defaults to the master branch. If the commit does not apply then a message is shown describing the files containing conflicts. See Backports.

If the target repository is configured to support dependent pull requests, it's possible to do this with the backport command by supplying the appropriate pr/X branch.

The pull request will be created from a branch in a shared fork of the target repository. On GitHub, this repository is owned by the openjdk-bots organization. The first time you issue the /backport command for a specific target repository, you will receive an invitation to collaborate in the fork repository. This invitation needs to be accepted to be able to further update the backport pull request with more changes.

Examples

• /backport jdk16u
• /backport jfx jfx14
• /backport jdk17u-dev pr/4711

/approval

Syntax

/approval [<id>] (request|cancel) [<text>]

Description

Requests maintainer approval for a change.

The approval process actually takes place in JBS, this command is mostly for convenience. In a pull request for a repository that requires maintainer approval, the author may use this command to add both the comment with the motivation and the correct label to any associated bugs. This can be especially useful if the author does not have a JBS account. Skara also tracks the approval labels in the associated bugs and will block integration until all bugs are approved.

The 'id' argument is needed if there are multiple bugs associated with a pull request as separate requests need to be submitted for each bug.

The 'text' argument should contain the motivation for the change. The pull request author may issue the /approval command multiple times to update the text. Note that if a request is made through this command, the comment on the bug will be created (and owned by) by a bot user, so the text can only be modified by running this command again.

Canceling a request removes the label and the comment from the bug.

Examples

• /approval request My reason
• /approval request My reason line1,
My reason line2,
My reason line3.
• /approval cancel
• /approval JDK-123 request My reason
• /approval 123 request
• /approval 123 cancel

/approve

Syntax

/approve [<id>] (yes|no)

Description

Approves a request for maintainer approval by adding the appropriate labels to the associated bugs.

The /approve command is only available to repository maintainers. It can only approve existing requests.

If an 'id' is specified, then only that bug is handled, if not, all associated bugs are handled.

Examples

• /approve yes
• /approve no
• /approve JDK-123 yes
• /approve 123 no

/author

Syntax

/author [set|remove] [@user | openjdk-user | Full Name <email@address>]

Description

Sets or removes a user as author of this pull request. An author 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 authors you need to supply the full name and email address. An author that has incorrectly been set can be removed by issuing the command /author remove. The author's name will be shown in the final commit message for the pull request and the pull request creator's name will be shown as the committer.

Examples

• /author set @openjdk-bot
• /author @openjdk-bot
• /author set J. Duke <duke@openjdk.org>
• /author remove @openjdk-bot
• /author remove

/help

Syntax

/help

Description

Shows help for all pull request commands.

Examples

• /help