Content
View differences
Updated by Yauheni Suhakou 5 days ago
### Why? (Pain / Problem)
Issues are written in OpenProject. Code is written in GitLab. There's no visibility between the two.
What should be built is defined in work packages — but the implementation itself lives in GitLab. So whenever someone needs to understand how far along an implementation is, where to find it, or whether it's already been reviewed, they have to jump into GitLab and manually hunt improvements for the code related to the specification. version 1.1 in 17.9.
That's tedious, and it breaks the flow for everyone involved:
* A **developer** wants to review the code for a work package.
* A **developer** wants to pick up and continue existing work.
* A **project manager** wants to see the state of the code — e.g. is it merged yet?
* **QA** wants to know where it was merged, so they know what to test.
* A **project manager** wants to demo something and needs to know whether a merge request already exists (and whether they could spin up a pull preview from it).
### What?
We enable users to **link their code with work packages** — connecting the output developers produce to the project management workflow that tracks it.
Today, OpenProject's GitLab integration only shows merge requests and issues. This makes code activity visible right inside the work package, so teams can follow development without leaving OpenProject.
### How?
* Listen to GitLab push events and link branches and their commits to the work packages they mention.
* Store branches and commits with a clear relationship, so each branch shows the commits that belong to it.
* Show the new branch and commit data directly on the work package.
* Refresh the merge request and issue views with the new UI — a clean design with collapsible sections — so all GitLab activity looks consistent.
<br>
Figma designs - https://www.figma.com/design/MUkwDhlspEfdBBbockeMxt/GitLab-Integration?node-id=2001-914&p=f&t=HFkM8T4A90trUJj2-0
Issues are written in OpenProject. Code is written in GitLab. There's no visibility between the two.
What should be built is defined in work packages — but the implementation itself lives in GitLab. So whenever someone needs to understand how far along an implementation is, where to find it, or whether it's already been reviewed, they have to jump into GitLab and manually hunt
That's tedious, and it breaks the flow for everyone involved:
* A **developer** wants to review the code for a work package.
* A **developer** wants to pick up and continue existing work.
* A **project manager** wants to see the state of the code — e.g. is it merged yet?
* **QA** wants to know where it was merged, so they know what to test.
* A **project manager** wants to demo something and needs to know whether a merge request already exists (and whether they could spin up a pull preview from it).
### What?
We enable users to **link their code with work packages** — connecting the output developers produce to the project management workflow that tracks it.
Today, OpenProject's GitLab integration only shows merge requests and issues. This makes code activity visible right inside the work package, so teams can follow development without leaving OpenProject.
### How?
* Listen to GitLab push events and link branches and their commits to the work packages they mention.
* Store branches and commits with a clear relationship, so each branch shows the commits that belong to it.
* Show the new branch and commit data directly on the work package.
* Refresh the merge request and issue views with the new UI — a clean design with collapsible sections — so all GitLab activity looks consistent.
<br>
Figma designs - https://www.figma.com/design/MUkwDhlspEfdBBbockeMxt/GitLab-Integration?node-id=2001-914&p=f&t=HFkM8T4A90trUJj2-0