Skip to content
代码片段 群组 项目
用户头像
Michael Becker 编辑于
Context
-----------

We have a feature, ["Resolve vulnerability"][0], that currently
generates a merge request to resolve a vulnerability. The only
existing ingress into this workflow Is through the vulnerability
detail page.

We are building out a new ingress to the "Resolve vulnerability"
workflow from the security widget on an existing MR.

When the resolution MR is generated from a vulnerable MR's security
widget, we attach a note to the vulnerable MR that provides a link to
the resolution MR.[^1]

This change
-----------

Right now, the note is just attached on the MR without being tied to a
specific line. We want to attach the note at the line the
vulnerability finding is being detected.

There are complications[^2] with attaching a `DiffNote` to a line that
isn't a part of the MR's diff. It is described more in this
[issue][2].

For this initial implementation, we just fall back to using an
un-attached note for situations where the finding's detected line is
not in the diff.

[0]:https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#resolve-a-vulnerability-with-a-merge-request
[1]:https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172185
[2]:https://gitlab.com/gitlab-org/gitlab/-/issues/325161
[3]:https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173238#note_2223845037

---

MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173238
Related to: https://gitlab.com/gitlab-org/gitlab/-/issues/503403
Changelog: changed
EE: true

[^1]: Originally, this new workflow was implemented using code change
      suggestions on the vulnerable MR. There was no secondary resolution
      MR created. We had to pivot the workflow to use a separate resolution
      MR. This change is a follow-up refinement from that pivot MR. To get
      more context on why we had to pivot you can see that MR [here][1]

[^2]: There is a lot more context in this [MR thread][3]
bcedcc05
历史
用户头像 bcedcc05
代码所有者
将用户和群组指定为特定文件更改的核准人。 了解更多。
名称 最后提交 最后更新
..