Pull Requests (PR) are Tuleap's built-in tool for code review. They allow a developer to propose changes on a branch, the team to review them line by line, and an integrator to validate and merge the code into the main branch.
Information
Tuleap also supports code review with Gerrit for organizations that prefer a patch-based review workflow.
Prerequisites
The "Pull Request" plugin must be installed and enabled in the project.
The Git service must be active with at least one repository.
Pull request list
The Pull Requests home page of the repository displays the list of all PRs.
A filter bar allows you to navigate efficiently through the results:
By status: open or closed (merged and abandoned).
By author, by reviewer, by labels, by branch (source or destination).
By keywords: search in the title and description.
"Related to me": shows only PRs where you are the author, reviewer, or involved.
Sorting by creation date (ascending or descending) and pagination complete the navigation options.
Create a Pull Request
To propose changes, push your development branch to the Tuleap repository, then click "Create a pull request" from the repository page. Select the source branch (your changes) and the destination branch (e.g. main).
The title is automatically extracted from the first commit message. The description takes the rest of that message. Both fields can be edited at any time via the "Edit title" button or by clicking directly on the description in the Overview tab. The description supports Markdown (CommonMark) syntax and has a "Preview" mode to visualize the rendering before saving.
You can also create a PR from a personal fork: select your fork as the source and the reference repository as the destination. Tuleap natively handles cross-repository PRs, allowing a contributor to propose changes from their fork to the project's main repository.
Create a PR from an Artifact
From an Artifact in your Trackers, you can directly create a Git branch and its associated PR via the Artifact actions. See the "Create a branch from an Artifact" section on the Git Settings page for the detailed procedure.
Pull Request content
Once created, the PR opens on the Overview tab. The page is organized into three tabs: Overview, Commits, and Changes.
Overview tab
The Overview tab is the central hub of the PR. It displays the PR description and the full chronological activity (timeline): comments, status changes, code updates. This is where the discussion between the developer and reviewers takes place.
The right side panel shows the PR metadata:
Author and creation date.
Reviewers assigned to the review.
Changes: number of lines added and deleted.
Last CI status: badge showing the result of the last CI build (Success, Failure, Running, or Unknown).
References: the commit SHA and the source → destination branches.
Labels: categorization tags.
The Overview tab also traces the lifecycle events of the PR: reviewer changes, branch updates (push of new commits), integration, abandonment, or reopening. Each event is timestamped and attributed to its author.
Commits tab
The Commits tab lists all commits included in the PR. Each commit displays its message, author, and date.
Changes tab
The Changes tab displays the diff of all modifications made by the PR.
A side panel lists the modified files, each accompanied by a status badge:
M (Modified): the file already existed and was modified.
A (Added): the file was created in this PR.
D (Deleted): the file was deleted.
Each file also displays the number of lines added and deleted, making it easy to quickly identify the scope of changes.
Two diff display modes are available:
Unified diff: classic view of added and deleted lines in a single column.
Side by side diff: deletions on the left, additions on the right. Switch between the two modes via the dedicated button in the toolbar.
Your chosen display mode is saved in your user preferences and will be automatically applied on your next visits.
Code review
Inline comments
To comment on a specific line of code, click on the line number in the Changes tab. An input field appears, allowing you to leave a contextual comment. Other users can reply, creating a discussion thread on that line.
Discussion threads are also visible from the Overview tab, grouped in the timeline.
General comments
From the comment section at the bottom of the Overview tab, you can add global comments on the PR. The input field offers two modes: "Write" and "Preview", with support for Markdown syntax.
Editing comments
You can edit your comments (global and inline) after publishing them. A last-modified indicator is then displayed next to the comment, allowing other participants to see that it has been updated.
@ mentions
In comments and the description, mention a user by typing @ followed by their name. An autocomplete dropdown appears after a few characters. The mentioned user receives an email notification.
Reviewers
The "Reviewers" field in the side panel of the Overview tab allows you to assign the people responsible for reviewing the code. Click the edit icon to search for a user by name or email (autocomplete). Multiple reviewers can be assigned.
Each added reviewer receives an email notification and their approval status is visible directly on the PR.
Labels
PRs can be categorized using labels defined at the project level. Click the edit icon next to "Labels" in the Overview tab to assign one or more. Labels can then be used as a filter criterion in the PR list.
Update and integration
Updating a Pull Request
When you push new commits to the source branch, the PR is automatically updated: the new commits appear in the timeline and the diff is recalculated.
Existing inline comments that referred to modified lines then appear greyed out. The comment remains visible, but the line of code it refers to has changed.
Integration
At the end of the review, two action buttons are available at the bottom of the side panel:
"Merge" (green): merges the changes from the source branch into the destination branch.
"Abandon" (red): rejects the PR.
Information
You can also merge manually locally and push the result. The PR will automatically be marked as merged.
Conflict detection
Before any integration, Tuleap automatically checks whether the source branch can be merged into the destination branch. If conflicts are detected, the "Merge" button is disabled and a warning message prompts you to resolve the conflicts locally before updating the PR.
Tuleap distinguishes three merge states:
Fast-forward possible: the destination branch is a direct ancestor of the source branch. The merge is done without a merge commit.
Merge with merge commit: the two branches have diverged, but no conflict is detected. A merge commit will be created automatically.
Conflicts detected: the changes overlap and require manual resolution. Check out the branch locally via the Checkout button, resolve the conflicts, then push the result to the source branch.
Warning
When the merge strategy is set to "Fast-forward only" and fast-forward is not possible, the integration is refused even if there are no conflicts. In this case, you must rebase your branch onto the destination.
Reopening a PR
An abandoned PR can be reopened provided that the source and destination branches still exist in the repository. When reopened, Tuleap automatically recalculates the merge status and takes into account any new commits pushed to the source branch in the meantime.
Merged PRs cannot be reopened.
Merge strategy
The repository administrator can configure the merge strategy in the "Pull requests" tab of the repository settings:
Default: fast-forward if possible, otherwise a merge commit is created.
Fast-forward only: only fast-forward is allowed. If the branch is not up to date, the integration is refused.
Notifications
An email notification is automatically sent to reviewers, the creator, and contributors of the PR on the following events: update (new commits), integration, abandonment, addition of a comment (global or inline). Notifications are not sent to the user who performs the action.
Mattermost
If the Bot Mattermost Git plugin is installed, Git and Pull Request events (push, creation, integration, abandonment) can be relayed to a Mattermost channel.
Information
Configuration is done from the project's Mattermost bots administration. Refer to the Slack & Mattermost documentation for more details.
Continuous integration (Jenkins)
Tuleap displays the continuous integration status directly on the PR as a badge. Four states are possible:
Success: the CI build succeeded.
Failure: the build failed.
Running: a build is currently running.
Unknown: no CI result is available.
The date of the last build is displayed next to the badge. To feed this status, configure the Jenkins integration:
Add a Jenkins webhook in the Git repository settings (Webhooks tab).
In the Jenkins job, configure the refspec
+refs/tlpr/*:refs/remotes/origin/pr/*and the branch specifier**.Install the Tuleap API plugin in Jenkins so that the build result is automatically reported back to the PR.
Information
The full configuration is described in the Pull request notification configuration documentation.
Cross-references
Pull Requests fully participate in Tuleap's cross-reference system. From the description or comments of a PR, you can reference any Tuleap element using the standard syntax (e.g. art #123). Conversely, from anywhere in Tuleap, use pr #N or pullrequest #N to create a link to a PR.
Cross-references are bidirectional: creating a reference in one direction automatically creates the reverse link.
Permissions
The actions available on a Pull Request depend on your rights on the underlying Git repository. Here are the main access rules:
View a PR: any user with read access to the Git repository can view the PR and its details.
Create a PR: any user who can push code to the repository (or a fork) can create a PR.
Comment: any user with read access can post global and inline comments.
Edit title and description: reserved for the PR author and repository administrators.
Assign reviewers: any user with read access can modify the reviewer list.
Manage labels: requires label management rights at the project level.
Merge: reserved for users with write rights on the destination branch.
Abandon: the PR author and users with write rights can abandon a PR.
Reopen: same rights as for abandonment.
Information
Project administrators and Git administrators have full permissions on Pull Requests in their repositories.