GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2024-03-29T12:10:36Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/16352Allow skipping artifact downloads on some builds2024-03-29T12:10:36ZJacob Vosmaerjacob@gitlab.comAllow skipping artifact downloads on some buildsUser feedback from World Tour Amsterdam event.
When creating artifacts early in a complex CI pipeline they get downloaded in a lot of subsequent builds even when not needed. This makes the pipeline slower. Consider some way of specifyin...User feedback from World Tour Amsterdam event.
When creating artifacts early in a complex CI pipeline they get downloaded in a lot of subsequent builds even when not needed. This makes the pipeline slower. Consider some way of specifying in gitlab-ci.yml that a build does not need artifacts?Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/16185Support Docker for Windows Server2024-03-29T12:10:36ZMark PundsackSupport Docker for Windows Server### Description
Docker for Windows Server is out. Let's support it!
### Proposal
### Links / references
* [Docker blog post](https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/)### Description
Docker for Windows Server is out. Let's support it!
### Proposal
### Links / references
* [Docker blog post](https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/16038Pass command line arguments to services2024-03-29T12:10:36ZPanagiotis AtmatzidisPass command line arguments to services### Description
I need to start MySQL with `--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci` options. The docker image supports `my.cnf` options:
```
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-p...### Description
I need to start MySQL with `--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci` options. The docker image supports `my.cnf` options:
```
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
```
I didn't find any documentation on command line arguments for services, so I'm deducing that passing arguments to services is not supported at this time. Is there any way to pass `my.cnf` options, except building a custom image, in `gitlab-ci.yml` ?
### Proposal
We have the [command](https://docs.docker.com/compose/compose-file/#command) option in `docker-compose` for this purpose. It would be nice to add a similar option under `services` for `gitlab-ci.yml`.
### Links / references
* _Commandline arguments in docker-compose_ - StackOveflow, [link](http://stackoverflow.com/questions/36640750/commandline-arguments-in-docker-compose)
* _Docker compose file reference_ - docker.com, [link](https://docs.docker.com/compose/compose-file/)
* _MySQL docker hub_ - docker.com, [link](https://hub.docker.com/_/mysql/)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/15564Provide GitLab CI YAML linting tool as standalone native app2024-03-29T12:10:35ZSander MaijersProvide GitLab CI YAML linting tool as standalone native appI've been searching for it today, but haven't found a native app variant of the GitLab CI YAML (in brief, the YAML) file linter as available over the web.
This is a pressing requirement, since it allows one to use the tool from e.g. repo...I've been searching for it today, but haven't found a native app variant of the GitLab CI YAML (in brief, the YAML) file linter as available over the web.
This is a pressing requirement, since it allows one to use the tool from e.g. repos' pre-commit configs (e.g., via [Yelp pre-commit](http://pre-commit.com)) and thereby actively prevent commits that result in invalid YAML.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/14579CI Lint button should prefill page with existing `.gitlab-ci.yml` content2024-03-29T12:10:35ZMark PundsackCI Lint button should prefill page with existing `.gitlab-ci.yml` contentPressing the CI Lint button from a project's Pipelines page brings up a blank text area. GitLab has the contents of the repo, it should populate that text area with `master`'s `.gitlab-ci.yml`.Pressing the CI Lint button from a project's Pipelines page brings up a blank text area. GitLab has the contents of the repo, it should populate that text area with `master`'s `.gitlab-ci.yml`.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/15261Allow usage of several key for cache2024-03-29T12:10:34ZGuillaume PerrinAllow usage of several key for cacheHello,
I have a problem with key of cache, and I didn't find a workaround to do it.
My problem is that I would like to cache a directory for the entire repository (aka .m2 for maven) and cache some files only for the current branch. I t...Hello,
I have a problem with key of cache, and I didn't find a workaround to do it.
My problem is that I would like to cache a directory for the entire repository (aka .m2 for maven) and cache some files only for the current branch. I tried to do the following thing, but it didn't work because it replaces the cache value (keeping only the second):
cache:
paths:
- test.zip
cache:
key: "$CI_BUILD_REPO"
paths:
- .m2/
It would be nice if we can have several key for different paths in cache, because for now I have to cache .m2 for each branch which wasting disk space.
We could do that using the following YAML:
cache:
- key: "$CI_BUILD_REF"
- paths:
- test.zip
-key: "$CI_BUILD_REPO"
-paths:
- .m2/
Thanks.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/15629Wrong issue link when external issue tracker settings were changed2024-03-29T08:10:10ZKovács VinceWrong issue link when external issue tracker settings were changedAfter chenging external issue tracker setting between services then links on **Commits** page did not updated for the project. When viewing details for a concrete commit message then issue link in commit message points to correct locatio...After chenging external issue tracker setting between services then links on **Commits** page did not updated for the project. When viewing details for a concrete commit message then issue link in commit message points to correct location.
Changed from:
![Screenshot_11](/uploads/ffab17d56476e757901f8eb1aaf22151/Screenshot_11.png)
To:
![Screenshot_12](/uploads/b7b93e770ff36b735569977c8119d311/Screenshot_12.png)
And the result:
Wrong on Repository / Commits page
![Screenshot_13](/uploads/881247d567b4e3abc42ab624eee7d71c/Screenshot_13.png)
Good on Repository / Concrete commit page
![Screenshot_15](/uploads/0a361bb8bb5a1a76f5de876c8271b37e/Screenshot_15.png)
Commit messages pushed after link change will points to new location correctly. This issue will affect only old commit messages.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/363819[Discussion] Editing visual content blocks2024-03-28T23:38:51ZMichael Le[Discussion] Editing visual content blocks<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
Allow content editors to edit visual content directly from GitLab.
## Ideal solution
The ideal solution is...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
Allow content editors to edit visual content directly from GitLab.
## Ideal solution
The ideal solution is to allow the editor to create/edit the drawing while in editing mode.
![image](/uploads/837a4e5faa6daa2981373fee174d2a9a/image.png)
1. `Insert diagram` command from toolbar
2. Editing screen for diagram opens
3. When saved the diagram is inserted to the page with the path of the svg going to `/uploads/autogenfilename.drawio.svg`
- Popover toolbar has actions to `edit drawing`, `copy drawing`, and `delete drawing`.
### Avoiding the case of editing while in view mode
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86206+ introduced the ability to edit draw.io content directly in GitLab.
![video](https://gitlab.com/gitlab-org/gitlab/uploads/6a61247e1253daf86e8c64dc03bde35f/2022-04-29_18.15.16.mp4)
![image](/uploads/9928a45902b4f876bc1a1034e215350a/image.png)
Initially this approach enables the content editor, [Eddie](https://about.gitlab.com/handbook/product/personas/#eddie-content-editor), to create the diagram when the content is in reading mode. There is precedent of having content editable while in view mode with todo lists and reordering lists. However we want to allow the user to create the diagram while in editing mode.
### How would this work in context of the source Markdown editor?
The proposed approach in !86206 uses a similar approach to [Redmine draw.io approach as mentioned this comment](https://github.com/mikitex70/redmine_drawio). This approach that leverages the integration to render `![NewDiagram.drawio.svg](NewDiagram.drawio.svg)` into a button to start the file editing. An advantage of this approach is that it would work without any extra additional work needed with new toolbar actions.
The long term vision on this is that this would be an action that would have a toolbar action associated with it. Using that assumption, we would add this new command under `+` button.
![image](/uploads/d96d2a7a2896fc4b1a8abd3abcac46be/image.png)
### Full screen editor vs inline editor
The draw.io editor is capable of being rendered inline of content. With inspiration from other draw.io plugins the editing experience is full screen. We believe that editing the drawing in full screen would give the ideal space for the drawing canvas with the toolbar visible. The full screen drawing editing experience would be consistent whether you are adding a drawing from source view via toolbar or Content Editor.
| Inline drawing editing | Full screen drawing editing |
| ------ | ------ |
| ![image](/uploads/2247598d0109502cbc81cdc1cf49f57e/image.png) | ![image](/uploads/0fedb20999b04d440f58756516f14bb8/image.png) |
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-->
<!-- Label reminders
Use the following resources to find the appropriate labels:
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/361446Wiki editor and display: allow crosslink shortcut and display2024-03-28T18:38:25ZCherry HanWiki editor and display: allow crosslink shortcut and display## Problem to solve
There is no crosslink shortcut available when authoring the wiki pages. It will be a great feature and provide feature parity comparing to other wiki like tools.
## Proposal
- Group wiki and project wiki page defau...## Problem to solve
There is no crosslink shortcut available when authoring the wiki pages. It will be a great feature and provide feature parity comparing to other wiki like tools.
## Proposal
- Group wiki and project wiki page default and rich editor to enable the crosslink short cut for epic, issue, MR, snippet, group and mention (all GitLab allowed crosslink)
- Display the link when crosslink is entered
- Allow the additional operation added such as + after to display the title of the crosslink item
- Display the crosslink properly on the page (title and URL etc)
### Current behavior
- You can use URL links directly but not shortcut like `# ! @`
- You cannot mention users
## Documentation (remove if not applicable)
Update crosslink doc for wiki usage
### Success Criteria
* [ ] On group and project wiki default and rich editor, allow crosslink shortcut for all crosslink items from epic, issue, MR, snippet, to mentions (group and users)
* [ ] Display crosslink properly on the wiki page
### Links / references
[crosslink list example](https://gitlab.com/gitlab-org/gitlab/uploads/7756793536c133e41fd199d78115bce0/Screen_Shot_2022-05-05_at_7.54.34_AM.png)https://gitlab.com/gitlab-org/gitlab/-/issues/371038Problem Validation: Report Source Lines of Code (SLoC) per Developer or per R...2024-03-28T17:25:59ZTorsten LinzProblem Validation: Report Source Lines of Code (SLoC) per Developer or per Repo/Group# Recommendation as a result of the research
- Do NOT implement Lines of Code Contributed _per Developer_. There has a potential negative impact.
- For details refer to the opportunity canvas or details section below.
- Analytics for...# Recommendation as a result of the research
- Do NOT implement Lines of Code Contributed _per Developer_. There has a potential negative impact.
- For details refer to the opportunity canvas or details section below.
- Analytics for Lines of Code _per directory, repo, or group_.
- While there are strong hints in this research that suggest this could be of value to users. It seems mostly a nice-to-have feature.
- For details refer to the opportunity canvas or details section below.
- The [tentative effort estimation to implement SLoC count on the repo level](https://gitlab.com/groups/gitlab-org/-/epics/9692#tentative-effort-estimation-base-on-first-technical-approach-above) suggests the amount of work is roughly 1.5 dev months. To then offer this on the group level is probably also not expensive. The effort to implement this on the directory level needs to be investigated.
### Links
The full [Opportunity Canvas "Contribution Metrics based on Lines of Code (SLoC) Contributed per Developer"](https://docs.google.com/document/d/1lV4GB1tE9e52sotyHj61CAjTXwowCq1IyXBUS5P8xS8/edit?usp=sharing). Internal only.
The full [Opportunity Canvas "Expose Lines of Code (SLoC) per Language in Repository Analytics to improve understanding of repo"](https://docs.google.com/document/d/1wQ8-WbcE5HmYiwWhZFwASWCqAOp-CcUEeeSIJO1ox3M/edit#). Internal only.
The full [research on Source Lines of Code Q3F23](https://docs.google.com/presentation/d/1xm1eVhwHIMEHA851jIqfhQEHRgAA7PFJ4i2LNdkolp0/edit?usp=sharing). Internal only.
# Details: What we learned researching this space
<div>
<table>
<tr>
<td>
<span dir="">Assumption</span>
</td>
<td>
<span dir="">What we thought</span>
</td>
<td>
<span dir="">What we learned</span>
</td>
<td>
<span dir="">What we think now</span>
</td>
</tr>
<tr>
<td>
<span dir="">{What we assumed}</span>
</td>
<td>
<span dir="">{What we thought this meant for the solution to this problem}</span>
</td>
<td>
<span dir="">{What we learned when we tested this assumption}</span>
</td>
<td>
<span dir="">{How these learnings relate to our approach/solution}</span>
</td>
</tr>
<tr>
<td>
<span dir="">We assumed that following three issues are about related/partly identical needs and are highly important due to their popularity:</span>
[<span dir="">Report number of lines per language in repository charts</span>](https://gitlab.com/gitlab-org/gitlab/-/issues/17800)<span dir=""> 568 upvotes; 18 individual commenters + 15 customer asks; also third highest </span>[<span dir="">priority score</span>](https://app.periscopedata.com/app/gitlab:safe-intermediate-dashboard/970771/User-Request-Issue-Prioritization---Product)<span dir=""> for user requested issues in SCM.</span>
<span dir=""> </span>
[<span dir="">New contributors graph (lines of code)</span>](https://gitlab.com/gitlab-org/gitlab/-/issues/14875)<span dir=""> 161 upvotes; 25 individual commenters; no customer asks</span>
[<span dir="">Visualize Language Trends over Time</span>](https://gitlab.com/gitlab-org/gitlab/-/issues/12104)<span dir=""> 11 upvotes; 5 customer asks </span>
</td>
<td>
<span dir="">Due to the high popularity, we thought the community agrees that GitLab should implement ‘LoC’ and that it would be clear what to implement. </span>
<span dir="">The popularity (both among users and among paying customers) was the reason to pick this topic up. </span>
</td>
<td>
[<span dir="">Reviewing all comments and customer asks on all issues I learned</span>](https://docs.google.com/presentation/d/1xm1eVhwHIMEHA851jIqfhQEHRgAA7PFJ4i2LNdkolp0/edit#slide=id.g191e02223c5_0_2)<span dir="">:</span>
<span dir="">There are **many dimensions** for which SLoC are requested: per **instance**, per **group**, per **project**, per **user**</span>
**<span dir="">Paying customers</span>**<span dir=""> care more about the **group level**, i.e. counting SLoC across all their repos</span>
<span dir="">In some cases, it seems unclear if there is a need for reporting SLoC **per language** or **just SLoC**</span>
<span dir="">There is **little** **detail** to **why** this is helpful nor **how** **often** such metrics would be consulted</span>
[<span dir="">Additional insights from other sources</span>](https://docs.google.com/presentation/d/1xm1eVhwHIMEHA851jIqfhQEHRgAA7PFJ4i2LNdkolp0/edit#slide=id.g17f2129743e_1_0)<span dir="">:</span>
**<span dir="">Some customers do NOT want to see data about individuals</span>**<span dir=""> as their workscouncil would object that and would turn off such a feature. </span>
</td>
<td>
<span dir="">It seems that there are two fundamental use cases: </span>
<span dir="">a) report LoC per user (i.e per each contributor to a project)</span>
<span dir="">b) report LoC per ‘location’ (i.e. per repo, per group or per instance)</span>
<span dir="">It is not very clear how important the topic is to the users/customers. </span>
<span dir="">- Conclusion: we should run a survey to assess importance.</span>
<span dir="">It is not clear what they are trying to achieve. </span>
<span dir="">- Conclusion: run interviews to understand the why.</span>
</td>
</tr>
<tr>
<td>
<span dir="">The ask is highly popular AND GitHub has offered this for a long time. It should therefore be a good thing to implement ‘LoC’.</span>
</td>
<td>
<span dir="">I thought GH addresses all asks vocalized in our issues.</span>
</td>
<td>
<span dir="">Assessing </span>[**<span dir="">GitHub</span>**<span dir="">’s offering</span>](https://gitlab.com/gitlab-org/gitlab/-/issues/371465#competition)<span dir=""> I found:</span>
<span dir="">GH does **NOT** show **LoC per repo**. (GL also doesn’t.)</span>
<span dir="">GH shows **languages per repo**</span>
<span dir="">- in **percent** in the UI (just like GL)</span>
<span dir="">- in **bytes** in the API (unlike GL which also provides percent)</span>
<span dir="">GH also offers the above for the **org-level**, i.e. is across all repos. (GL doesn’t.)</span>
<span dir="">GH shows </span>[**<span dir="">LoC</span>**<span dir=""> (added/removed) </span>**<span dir="">per contributor</span>**](https://github.com/mrdoob/three.js/graphs/contributors?from=2010-03-21&to=2022-11-22&type=a)<span dir=""> (but **NOT language**).</span>
<span dir="">A </span>[<span dir="">popular tool lets users post their </span>**<span dir="">personal stats</span>**](https://github.com/anuraghazra/github-readme-stats)<span dir=""> on their </span>[<span dir="">profile page</span>](https://github.com/mrdoob)<span dir="">.</span>
</td>
<td>
<span dir="">GitHub also does not offer everything that users seem to be asking on our issues.</span>
<span dir="">A reason may be that when they implemented this there was no handy library to report SLoC per language per repo/org.</span>
<span dir="">GH seems to be considering </span>[<span dir="">extensive visualizations of source code</span>](https://githubnext.com/projects/repo-visualization)<span dir="">. The feedback on twitter is positive. </span>
<span dir="">If we were to offer _LoC per user_, this would be a me-too feature. The </span>[<span dir="">comments</span>](https://gitlab.com/gitlab-org/gitlab/-/issues/17800#note_293348432)<span dir=""> on the issue suggest that the need is largely driven by the fact that GitHub has had this for a long time and developers consider it as something a source code management platform would normally have.</span>
</td>
</tr>
<tr>
<td>
<span dir="">We should survey a broad spectrum of users as the issues suggested that commenters also came from different backgrounds but still all seemed to care about the topic ‘LoC’. </span>
<span dir="">We asked a total of </span>[<span dir="">118 users: 64 sw dev; 15 dev team leads; 10 DevOps; etc.</span>](https://docs.google.com/presentation/d/1xm1eVhwHIMEHA851jIqfhQEHRgAA7PFJ4i2LNdkolp0/edit#slide=id.g139bca1b89a_0_1059)
</td>
<td>
<span dir="">We thought ‘LoC’ would be highly popular, given that the issues are so popular.</span>
</td>
<td>
[<span dir="">The </span>**<span dir="">survey</span>**<span dir=""> showed</span>](https://docs.google.com/presentation/d/1xm1eVhwHIMEHA851jIqfhQEHRgAA7PFJ4i2LNdkolp0/edit#slide=id.g18dae5a6a9c_0_0)<span dir="">:</span>
<span dir="">Compared to users of other tools, users of GitLab seem to care less about seeing the number of lines contributed </span>
<span dir="">GitLab users also care less about the breakdown of languages within a project compared to their peers</span>
<span dir="">In most cases, those newer to their role thought the features were more important</span>
<span dir=""> </span>
</td>
<td>
<span dir="">The survey suggests, ‘LoC’ seems to be of medium importance (or medium un-importance) for Source Code management. </span>
<span dir="">We will need to run interviews to understand more. </span>
</td>
</tr>
<tr>
<td>
<span dir="">The survey suggested that there do not seem to be significant differences in the views of managers vs. individual contributors. </span>
<span dir="">Therefore, we interviewed software developers and also asked them about their manager's perspective. </span>
<span dir="">8 interviews (7 sw devs, 1 of which is also DevOps engineer / evangelist; 1 prj. mngr (former sw dev)) </span>
</td>
<td>
<span dir="">We would learn in the interviews what the value of ‘LoC’ would be. </span>
</td>
<td>
<span dir="">In the </span>[**<span dir="">interviews</span>**<span dir=""> we learned</span>](https://docs.google.com/presentation/d/1xm1eVhwHIMEHA851jIqfhQEHRgAA7PFJ4i2LNdkolp0/edit#slide=id.g17117578ef8_2_21)<span dir="">:</span>
**<span dir="">SLoC</span>**<span dir=""> **_per user_** is **NOT** seen as a **good measure for contribution**.</span>
<span dir="">Some have had **negative experiences** with **metrics to assess performance** (incl. SLoC)</span>
**<span dir="">SLoC _per directory_</span>**<span dir=""> would be **valuable**. Interviewees see this mostly as **nice to have** though.</span>
**<span dir="">Comparing</span>**<span dir=""> growth of SLoC in **_different directories_** that serve different purposes (application vs. test) is **more interesting than** **comparing growth** in SLoC **_per languages_**.</span>
<span dir="">Potentially interesting sub-feature: Using SLoC to **filter by language**: commit lists or repo lists. </span>
</td>
<td>
<span dir="">One use case seems to be around SLoC _per user:_</span>
<span dir="">_I want an easy way to know who has contributed how many LoC to a project_</span>
<span dir="">_so that I can compare their contributions_</span>
<span dir="">_a) to feel proud of my own work or_</span>
<span dir="">_b) to track my team members work_</span>
**<span dir="">We should NOT implement this use case: SLoC _per user_</span>**<span dir=""> as it is NOT a good metric. </span>
<span dir="">It might be a nice graph to look at for some, but it will have **negative consequences for a few** as their performance would be evaluated based on their contributed SLoC. </span>
<span dir="">Do literature research to find further evidence of this outcome. </span>
<span dir="">Consider a blog post that reflects our decision. A good timing would be at the same time when we potentially release something else related to SLoC (see below).</span>
<span dir="">-> Take this result and create an **opportunity canvas on SLoC _per user _**as a contribution metric **with the recommendation NOT to do it**.</span>
<span dir="">—--</span>
**<span dir="">SLoC _per directory_ or _per language per repo_</span>**<span dir=""> seems to be valuable to help users get a quick understanding of a repo or the health of different modules. The use case seems to be:</span>
<span dir="">_For a given repo or a module (i.e. directory) , that I see for the first time, I want to know lines of code per language,_</span>
<span dir="">_a) so that I can get a quick sense if it will be easy for me to contribute to it given my skill set_</span>
<span dir="">_b) so that I can understand if the module is bloated_</span>
<span dir="">This addresses the needs of individual contributors so it would be part of the **free tier**.</span>
<span dir="">-> Understand the effort to implement this.</span>
<span dir="">—---</span>
**<span dir="">SLoC _per group_</span>**<span dir=""> was not assessed in this series of interviews with developers as this is likely more relevant for administrators, CIO’s, directors, etc. </span>
<span dir="">-> reach out to 2 or 3 customers that requested this in one of the original issues to understand what they are trying to achieve and to understand how this could be tiered. </span>
</td>
</tr>
<tr>
<td>
</td>
<td>
</td>
<td>
<span dir="">The </span>[**<span dir="">literature research</span>**](https://gitlab.com/gitlab-org/gitlab/-/issues/371465#literature)<span dir=""> showed:</span>
<span dir="">Literature supports the interviewee’s perspective that SLoC is NOT a good metric for measuring contribution. </span>
</td>
<td>
</td>
</tr>
</table>
</div>
## Definition of Done
- [x] The problem is well understood by the PM to have an understanding summarized in a RICE score (see [Opportunity Canvas "Contribution Metrics based on Lines of Code (SLoC) Contributed per Developer"](https://docs.google.com/document/d/1lV4GB1tE9e52sotyHj61CAjTXwowCq1IyXBUS5P8xS8/edit?usp=sharing)).
- [x] The problem is well understood by the PM to decide if they want to move forward with this idea or drop it.
- Recommendation is not to go ahead with Lines of Code _per developer_
- Recommendation is to do follow-up research on Lines of Code _per directory, per repo, and per group_
- [x] N/A: The problem is well described and detailed with necessary requirements for product design to understand the problem
- [x] N/A: The problem is well described and detailed with necessary requirements for engineering to understand the problem
## Research Issue
_This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->BacklogTorsten LinzTorsten Linzhttps://gitlab.com/gitlab-org/gitlab/-/issues/17800Report number of lines per language in repository charts2024-03-28T17:25:57ZDmytro Bogatovdmytro@dbogatov.orgReport number of lines per language in repository charts### Description
As of now, repository charts report percentage of language in the repo.
First, it is not obvious how this percentage is computed (number of files? number of lines? bytes? what about comments? libraries?). Second, I would...### Description
As of now, repository charts report percentage of language in the repo.
First, it is not obvious how this percentage is computed (number of files? number of lines? bytes? what about comments? libraries?). Second, I would love to see some *absolute* data (number of files, lines, bytes).
### Proposal
As a user I would like to see the number of lines of code per language.
Ideally, excluding blank lines and comments, but that is optional.
### Documentation blurb
As for use cases:
* better understand the repo structure
* if this is your repo, being able to report the number of lines of your main language
* this is one of the metric employers would like to know (I personally was surprised by this question on interview and could not clearly respond)
* all those use cases for general repo graphs (like pie chart of languages)
### Details
[A useful comment from ZJ](https://gitlab.com/gitlab-org/gitlab/issues/17800#note_214979038):
> Just so its stated explicitly, the language bar on the projects overview page is based on bytes. Iteration over each blob to count the number of lines will be quite expensive and to make it performant on gitlab.com scale will be quite the challenge :smile: Bytes are chosen as Git stores the size of each blob with its name. So if a blob has the path `path/to/file.rb` it can take the extension and detect it's Ruby. It already has the number of bytes, so it can move on.
> Lines however is harder, as now you'd have to either iterate each blob each time, or be clever with caching combined with diffing, which in turn might lead to race conditions.
> That all being said, this would require a new RPC to Gitaly, and gitaly-proto changes. Happy to review MRs there! :cat:
### Potential Workarounds
- Run `scc` in a GitLab CI pipeline: https://github.com/boyter/scc to generate SLOC/etc. reports
- If API use is acceptable (instead of UI), parts of its output stats can be stored as custom attributes on the project: https://docs.gitlab.com/ee/api/custom_attributes.html#set-custom-attributeBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/15170Backend: Make it possible to identify a new/empty branch with workflow:rules2024-03-28T14:22:43ZZeger-Jan van de WegBackend: Make it possible to identify a new/empty branch with workflow:rules
### :warning: Solution
After implementing https://gitlab.com/gitlab-org/gitlab/-/issues/293645 it appears like we have a working solution using this config
```yaml
workflow:
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
...
### :warning: Solution
After implementing https://gitlab.com/gitlab-org/gitlab/-/issues/293645 it appears like we have a working solution using this config
```yaml
workflow:
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: always
- if: $CI_COMMIT_BRANCH
changes:
paths: ['*']
compare_to: refs/heads/master
when: always
test:
script: exit 0
```
### Problem to Solve
Whenever a user creates a new branch it will be picked up by GitLab and will be post-processed. In turn, a pipeline will be created.
The pipeline could be useless in cases where there is nothing different from the origin, even considering `.gitlab-ci.yml` conditions.
### Proposed solution
```yaml
test:
script: ./run tests
rules:
- if: $CI_COMMIT_BRANCH
changes:
paths:
- *
compare:
branch: master
```
### old Proposal (not relevant)
<details><summary>Click to expand</summary>
By having a new variable `CI_BRANCH_COMMIT_COUNT` that users could add to the `workflow:rules` condition, the variable will be defined based on a result of using a Git command, any pipeline using can then determine whether the branch is the same as the default branch.
An example for capturing a branch commit count could look like this:
```
git rev-list --count $CI_COMMIT_BRANCH ^DEFAULT_BRANCH (for regular pipelines)
git rev-list --count $CI_COMMIT_BRANCH ^CI_MERGE_REQUEST_TARGET_BRANCH_NAME (for MR pipelines)
```
This way users could add that to the pipeline configuration as
```yaml
workflow:
rules:
- if: $CI_BRANCH_COMMIT_COUNT == 0
when: never
...
```
in case they would like to avoid a pipeline to run when a new branch is created
</details>
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->Furkan AyhanFurkan Ayhan2022-08-10https://gitlab.com/gitlab-org/gitlab/-/issues/353097Remove approvals_before_merge/approvals_required fields from public API (brea...2024-03-28T14:01:26ZIgor Drozdovidrozdov@gitlab.comRemove approvals_before_merge/approvals_required fields from public API (breaking change)The `approvals_before_merge` field has been made redundant within:
- Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/11132.
- Merge request: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16121
Within this issue, we should ...The `approvals_before_merge` field has been made redundant within:
- Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/11132.
- Merge request: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16121
Within this issue, we should remove `approvals_before_merge`/`approvals_required` fields from public API or Projects and Merge Requests. It's a breaking change and must be done within a major release %"15.0"
It includes:
- `approvals_before_merge` API [field](https://gitlab.com/gitlab-org/gitlab/blob/0b62424123c2b721a9cad8608cda4933ae5ee780/ee/lib/ee/api/merge_requests.rb#L11)
- Updating documentation: https://docs.gitlab.com/ee/api/merge_request_approvals.html
- Removing `/approvals` [endpoint](https://gitlab.com/gitlab-org/gitlab/blob/0b62424123c2b721a9cad8608cda4933ae5ee780/ee/lib/ee/api/merge_request_approvals.rb#L60)16.0Vasilii Iakliushinviakliushin@gitlab.comVasilii Iakliushinviakliushin@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/227062gitlab-runner exec docker - support env var file2024-03-28T12:52:55ZJames Sandlinjsandlin@gitlab.comgitlab-runner exec docker - support env var file<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. Howe...<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->
### Problem to solve
When running local `gitlab-runner exec docker` and trying to replicate the "automatic" variables GitLab defines, I must provide each env var via cmd line. EX:
```
➜ gitlab-runner exec docker --env "CI_REGISTRY_USER=jsandlin" --env "CI_REGISTRY_PASSWORD=918234pqsfd" test
```
Having to provide this manually is extremely error-prone.
### Intended users
Anyone who wants to develop/debug beyond vanilla `.gitlab-ci.yml`
[Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
[Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
[Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
[Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
[Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
### User experience goal
<!-- What is the single user experience workflow this problem addresses?
For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>"
https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ -->
### Proposal
Allow an argument so I can refer to a local variable file to read & send to the cmd. EX:
```
gitlab-runner exec docker --env-file ~/.gitlab/job_env_vars.cfg
```
### Further details
<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
I am trying to test locally rather than commit / wait / commit / wait / commit wait.
With this, I could develop the `.gitlab-ci.yml` locally.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?-->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change
* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->
### Availability & Testing
### What does success look like, and how can we measure that?
As a developer, I can work on my `.gitlab-ci.yml` locally and execute it locally (via Docker) and use logs to develop / debug.
### What is the type of buyer?
<!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/
In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
Any organization working on complex pipeline jobs.
### Is this a cross-stage feature?
<!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features -->
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/362910Benchmark DB workload with CI/CD partitioning2024-03-28T00:11:32ZFabio Pitinofpitino@gitlab.comBenchmark DB workload with CI/CD partitioning## Problem
With an exponential growth in `ci_pipelines` (`ci_builds`, `ci_job_artifacts`, etc.) we would also have an exponential growth in the operations (reads/writes) that occur concurrently. This will mean:
- More pipelines to proce...## Problem
With an exponential growth in `ci_pipelines` (`ci_builds`, `ci_job_artifacts`, etc.) we would also have an exponential growth in the operations (reads/writes) that occur concurrently. This will mean:
- More pipelines to process concurrently
- More jobs to update concurrently
- More artifacts being created in a short period of time
- More artifacts to be expired and destroyed
Similar to https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/15661, it could be good to being able to answer questions like: How does the exponential growth of operations per second affect the database performance? - For example: how does that impact AUTOVACUUM?Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/7583Developer cannot push to projects they create in groups2024-03-27T23:45:48ZJames Ramsay (ex-GitLab)Developer cannot push to projects they create in groups### Summary
When a group allows developers to create new projects, the developer is unable to push any code without the `Maintainer` permission, but it is not desirable for a developer to receive elevated permissions. The `master` branc...### Summary
When a group allows developers to create new projects, the developer is unable to push any code without the `Maintainer` permission, but it is not desirable for a developer to receive elevated permissions. The `master` branch is protected by default when creating a new project, which prevents the developer from pushing to that branch without the involvement of a `Maintainer`. This workflow is disruptive and does not provide the expected experience for users.
### Steps to reproduce
1. In a group where you only have developer permissions, create a project
1. Check the members page to see your permissions and try to push to the `master` branch
### What is the current *bug* behavior?
I only have **Developer** permissions on the project I created and cannot push to the `master` (default protected) branch.
### What is the expected *correct* behavior?
As a `Developer`, I should be able to push to the project I've just created without intervention from a `Maintainer`.
### Use Case
As a `Group Owner`, I want `Developers` to be able to push code to new projects they create and allow `Owners` and `Maintainers` to protect the branch after the initial code has been pushed.
### Proposal
Bring `default branch protection` settings to the group-level to allow flexibility in defining expected behaviors for `project creation` and `pushing commits`.
| Figure 1 |
| ------ |
| ![clip-2020-02-12](/uploads/5036ccba19b7bae711d1dbdbb2dc101d/clip-2020-02-12.png) |
| Instance-level setting for `default branch protection` |
### Additional information
The possible configurations would be possible in this move:
| **Default branch protection** | **Default project creation protection** | **Create Projects** | **Push new commits** | **Benefit** |
| ------ | ------ | ------ | ------ | ------ |
| Fully protected | Maintainers | Maintainers | Maintainers | Maintainers retain strict control of the group and must be involved with project initialization. |
| Partially protected | Maintainers | Maintainers | Maintainers + Developers | Maintainers control project creation to limit volume, but Developers can still push new commits to these new projects. |
| Partially protected | Maintainers + Developers | Maintainers + Developers | Maintainers + Developers | Both Maintainers and Developers can create projects and push new commits. |
`Maintainers` can still visit each project created by a `Developer` to modify the default protected branch setting **Allowed to push** from `Maintainers + Developers` -> `Maintainers` after a project has been initialized.
These settings could allow developers to create projects and initialize them **without involving a maintainer**.
This provides some flexibility to group owners to alleviate friction for `Developers`.
More work is required to address the multiple use cases represented in this issue.
<details>
<summary>Original Proposal</summary>
1. A new setting on the project creation screen to (optionally) protect the `master` branch. (default: checked/enabled) - **Figure 1**
1. If enabled, only `Maintainers` can push code and workflows remain unchanged
1. If disabled, the default protected branch is created with the settings in **Figure 2**. Both `Maintainers` and `Developers` can push code to `master` for this project only.
1. Once a project has been setup, an `Owner` or `Maintainer` can modify the project settings to `Protect` the master branch by changing the protected branch settings to `Maintainer` only. - **Figure 3**
**Workflow**
| Figure 1 | Figure 2 | Figure 3 |
| ------ | ------ | ------ |
| ![clip-2020-01-22-3](/uploads/1e1295e49eed512035e0473f86cc577d/clip-2020-01-22-3.png) | ![clip-2020-02-06](/uploads/6aa62107adbbea5974633b63403fc1d9/clip-2020-02-06.png) | ![clip-2020-01-22-2](/uploads/18f973c7a662f5fe7a8424b43a9087a8/clip-2020-01-22-2.png) |
| Any `User` who can create a project, can (optionally) protect `master` on new projects. | The default protected branch, when initialized, will allow `Maintainers + Developers` to push and merge code into the default protected branch. | `Owners` and `Maintainers` would be able to modify `Protected Branches` in the project settings to secure the project once initial code has been pushed by a `Developer`. |
</details>
<!--
| New Group level setting | Create Project | Maintainer View | Developer View |
| ------ | ------ | ------ | ------ |
| ![Push_Rules](/uploads/ad210ef7669552d1fa98d6a6c0f2ca7f/Push_Rules.png) | ![Screen_Shot_2020-01-07_at_3.29.39_PM](/uploads/7607a0859c016abc5d43ecbc35fadd7f/Screen_Shot_2020-01-07_at_3.29.39_PM.png) | ![Screen_Shot_2020-01-07_at_3.31.21_PM](/uploads/d6ceadc09560e6b53bfa010e559564a5/Screen_Shot_2020-01-07_at_3.31.21_PM.png) | ![Screen_Shot_2020-01-17_at_12.26.15_PM](/uploads/75ec4d3e3cd8b69b7576e0a163c118a5/Screen_Shot_2020-01-17_at_12.26.15_PM.png) |
| A `Group Owner` will allow or disallow optional branch protection in `Group Settings`. | A `User`, with permission to create projects, creates a new `Project` in their group. | The `Project` creation UI presents a checkbox to optionally protect (or not) the default branch. | If a `Developer` creates the `Project`, the checkbox is visible but inactive. |
-->
Some thought will be required on managing the compliance aspect of this workflow. While it is desirable to enable developers to push to the projects they've created, it may be necessary to at least notify `Owners` or `Administrators` when an unprotected branch is created.
Additionally, there may be a need to implement a group-level setting (or another mechanism) to "require all new projects protect master branch" to provide controls for organizations to maintain compliance status, which would override the solution proposed here.
This could manifest elsewhere as a report showing a list of unprotected branches, but this is likely a separate issue for consideration.
### Output of checks
This bug happens on GitLab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/357523[MR Widget Eng] - Clicking on a link should open a modal2024-03-27T05:23:58ZSavas Vedova[MR Widget Eng] - Clicking on a link should open a modal## Description
The current MR Widget extension spec does not support opening a modal when a link is clicked.
## Implementation Plan
- TBD
## Security Reports use case
The original MR Security Reports widget had the ability to displa...## Description
The current MR Widget extension spec does not support opening a modal when a link is clicked.
## Implementation Plan
- TBD
## Security Reports use case
The original MR Security Reports widget had the ability to display the vulnerability data when a the vulnerability was clicked. This was done through opening a new modal. Below you'll see a gif which compares the old and new version of the widgets:
![security-widget-missing-feature](/uploads/5b573ed33ad0e2e427c5eccf58c42a0f/security-widget-missing-feature.gif)Miranda FluhartyMiranda Fluhartyhttps://gitlab.com/gitlab-org/gitlab/-/issues/336618Add support for the new pure SSH-based LFS protocol2024-03-27T04:11:12ZElvis StansvikAdd support for the new pure SSH-based LFS protocolNow that a pure SSH-based protocol has been merged in Git LFS (https://github.com/git-lfs/git-lfs/pull/4446), it would be great if GitLab could support this.
This will help in environments in which SSH is the only supported/permitted pr...Now that a pure SSH-based protocol has been merged in Git LFS (https://github.com/git-lfs/git-lfs/pull/4446), it would be great if GitLab could support this.
This will help in environments in which SSH is the only supported/permitted protocol, and in environments where having traffic go over HTTPS is cumbersome, for example environments where HTTPS traffic is protected by SSL client certificate authentication.16.9Ash McKenzieamckenzie@gitlab.comAsh McKenzieamckenzie@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/347274Updated: 31 January 2022 - Action required - Deprecating persistent refresh t...2024-03-26T22:51:18Z🤖 GitLab Bot 🤖Updated: 31 January 2022 - Action required - Deprecating persistent refresh tokensA new [Atlassian developer community announcement](https://community.developer.atlassian.com/t/updated-31-january-2022-action-required-deprecating-persistent-refresh-tokens/54172) was published. Please evaluate if an action is required.A new [Atlassian developer community announcement](https://community.developer.atlassian.com/t/updated-31-january-2022-action-required-deprecating-persistent-refresh-tokens/54172) was published. Please evaluate if an action is required.https://gitlab.com/gitlab-org/gitlab/-/issues/18830Use gitattributes custom merge driver in MRs2024-03-26T16:11:48ZLucien BoillodUse gitattributes custom merge driver in MRs### Description
Currently Gitlab reads .gitattributes file and use informations like "union" or "binary", but custom merge drivers are not used during merge requests (since they are defined in the gitconfig).
It can be a huge help to b...### Description
Currently Gitlab reads .gitattributes file and use informations like "union" or "binary", but custom merge drivers are not used during merge requests (since they are defined in the gitconfig).
It can be a huge help to be able to use this git functionnality in gitlab MRs.
I explain a use case:
I have project with a separate production and staging configs files, so I'll do a branch "prod" and an other "staging", with respective configs. Then the workflow is: dev on staging, and when it's ready for production, just do a merge request targeting prod branche. The problem is the configs files will conflicts during merge. One solution would be to put every configs files in the .gitattributes file, with custom merge driver, and do the merge locally, then push it on production. But we loose all the benefits of Gitlab MR interface, review etc ...
Maybe there is already some good practises, or a way to achieve that ? I didn't found one which fit well with the problem.
### Proposal
Find a way to parse the config file in order to enable the custom driver functionality (maybe force the user to re-write it in some settings on the Gitlab interface ?).
### Links / references
https://medium.com/@porteneuve/how-to-make-git-preserve-specific-files-while-merging-18c92343826b
https://git-scm.com/docs/gitattributesBacklogJohn Caijcai@gitlab.comJohn Caijcai@gitlab.com