获取文件夹内容时发生错误.
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]
代码所有者
将用户和群组指定为特定文件更改的核准人。 了解更多。
名称 | 最后提交 | 最后更新 |
---|---|---|
.. |