GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2024-03-25T21:57:55Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/449097Restrict instance runner access enablement to top-level group owner only2024-03-25T21:57:55ZChris StoneRestrict instance runner access enablement to top-level group owner only<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
Provide option to restrict enablement of instance runners to top-level group owners only.
The current model...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
Provide option to restrict enablement of instance runners to top-level group owners only.
The current model for enabling access to [instance runners](https://docs.gitlab.com/ee/ci/runners/runners_scope.html) allows any owner of a subgroup to enable instance runners for their group/subgroups/projects if the hierarchy permits, this may not be sufficiently restrictive in some scenarios and established enterprise structures.
![image](/uploads/041c5f629e03f58e24e461cf7df2264e/image.png){width=40%}
Take the enterprise customer scenario below:
- **Enterprise (Group Level)**: manages top-level settings and security, having precedence over subgroup settings.
- **Subgroup (Product/Team Level)**: Teams like Marketing Tech, with their "owner" roles, are subordinate to the enterprise's overarching governance.
Despite the logical hierarchy where enterprise settings should dictate the accessibility of instance runners across the platform, the ability for subgroup "owners" to override these settings poses a significant challenge for us. Our main concern revolves around the efficient and exclusive allocation of SaaS runner resources to a specific team, without the risk of unauthorized access and potential overage charges.
We propose a feature request to enhance permission granularity, enabling us to designate instance runner access to a chosen subgroup without granting such capabilities universally to all subgroup "owners." This targeted permission strategy is crucial for us, given our reliance on both self-hosted and SaaS runners, and the unique advantages the latter provides for specific operational needs.
To summarize, we seek a feature that allows enterprise-level administrators to:
1. Allocate instance runner usage exclusively to selected subgroups, bypassing the current all-or-nothing override capability.
2. Maintain strict control over resource distribution to prevent inadvertent overage, while still leveraging the unique features of SaaS runners for chosen projects.
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/449078Allow grouping deployment environments at the project level for monorepo2024-03-25T02:02:32ZChloe CartronAllow grouping deployment environments at the project level for monorepo### Proposal
At the project level, users can view and manage all their deployment environments.
This becomes challenging for users with a monorepository as they might have different environments (e.g dev, staging, production) for mult...### Proposal
At the project level, users can view and manage all their deployment environments.
This becomes challenging for users with a monorepository as they might have different environments (e.g dev, staging, production) for multiple services inside the same project.
This could be solved by grouping deployment environments together per services. For example, having a group "service-a" with a dropdown to see the corresponding environments (service-a-dev, service-a-stagging, service-a-prod).
There are initiatives to [improve the environment management at the organisation level](https://gitlab.com/groups/gitlab-org/-/epics/7558) but so far this seems to only apply to users with multiple projects and does not solve for monorepo.https://gitlab.com/gitlab-org/gitlab/-/issues/449043Feature: permit administrators to revoke active user sessions directly and in...2024-03-12T18:31:15ZBrie CarranzaFeature: permit administrators to revoke active user sessions directly and in bulk/en masse (UI and API)<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated us...<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab.
The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). -->
### Release notes
<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
With this _proposed_ feature, there is an API for **Administrators** to revoke one, many or all of a user's active session(s). It is also possible for **Administrators** to revoke one, many or all active sessions for a user via the UI. It is no longer necessary to [impersonate](https://docs.gitlab.com/ee/administration/admin_area.html#user-impersonation) a user in order to [revoke a session](https://docs.gitlab.com/ee/user/profile/active_sessions.html#revoke-a-session).
### Problem to solve
<!-- What is the user problem you are trying to solve with this issue? -->
The docs (and functionality) for how to [revoke an active session](https://docs.gitlab.com/ee/user/profile/active_sessions.html#revoke-a-session) are aimed at users (rather than administrators).
Administrators can not easily revoke active sessions for one (or more users) directly.
Administrators can not rapidly revoke active sessions for one (or more users) quickly.
### Proposal
<!-- 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. -->
### Intended users
* [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator)
* [Isaac (Infrastructure Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer)
* [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer)
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas are described at https://handbook.gitlab.com/handbook/product/personas/
* [Parker (Product Manager)](https://handbook.gitlab.com/handbook/product/personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead)
* [Presley (Product Designer)](https://handbook.gitlab.com/handbook/product/personas/#presley-product-designer)
* [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer)
* [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer)
* [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator)
* [Rachel (Release Manager)](https://handbook.gitlab.com/handbook/product/personas/#rachel-release-manager)
* [Simone (Software Engineer in Test)](https://handbook.gitlab.com/handbook/product/personas/#simone-software-engineer-in-test)
* [Allison (Application Ops)](https://handbook.gitlab.com/handbook/product/personas/#allison-application-ops)
* [Ingrid (Infrastructure Operator)](https://handbook.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator)
* [Dakota (Application Development Director)](https://handbook.gitlab.com/handbook/product/personas/#dakota-application-development-director)
* [Dana (Data Analyst)](https://handbook.gitlab.com/handbook/product/personas/#dana-data-analyst)
* [Eddie (Content Editor)](https://handbook.gitlab.com/handbook/product/personas/#eddie-content-editor)
* [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer)
* [Isaac (Infrastructure Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer)
* [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer)
* [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager)
-->
### Feature Usage Metrics
<!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide.
-->
### Does this feature require an audit event?
Yes.
<!--- Checkout these docs to know more
https://docs.gitlab.com/ee/development/audit_event_guide/#what-are-audit-events
https://docs.gitlab.com/ee/administration/audit_events.html
--->
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->
<!-- 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 -->https://gitlab.com/gitlab-org/gitlab/-/issues/448899Update license-interfacer to support cargo2024-03-25T03:26:50ZIgor FrenkelUpdate license-interfacer to support cargo### Problem to solve
Classify `deps.dev` licenses to match internal representation.
### Proposal
The [license-finder](https://gitlab.com/gitlab-org/gitlab/-/issues/448898 "Update license-feeder to support cargo") emits license data st...### Problem to solve
Classify `deps.dev` licenses to match internal representation.
### Proposal
The [license-finder](https://gitlab.com/gitlab-org/gitlab/-/issues/448898 "Update license-feeder to support cargo") emits license data stored under the [PackageVersions](https://docs.deps.dev/bigquery/v1/#packageversions) table to the `cargo` pubsub topic. The license names do not precisely match the licenses in the `license-db` database and thus need to be classified before storage.
This issue covers the creation of the interfacer which will handle messages arriving on the `cargo` interfacer pubsub topic, classify them, and then re-emit them onto the processor pubsub topic.
### Implementation Plan
* [ ] Create a mapping of common license names in `deps.dev` to license names in `license-db` (weight of \~3).
* [ ] Handle classification (weight of \~3).
* [ ] Handle arriving messages
* [ ] Classify licenses in the message
* [ ] Create outgoing message and publish it tot he processor topic
### Verification Steps
TBC
### Documentation
* [ ] Update [dev docs](https://gitlab.com/gitlab-org/security-products/license-db/deployment/-/blob/main/docs/fullstack_development.md) with any new instructions concerning `cargo` and `license-interfacer`16.11https://gitlab.com/gitlab-org/gitlab/-/issues/448898Update license-feeder to support cargo2024-03-25T03:26:50ZIgor FrenkelUpdate license-feeder to support cargo### Problem to solve
Create a source of `cargo` package metadata by importing data from the `deps.dev` [bigquery dataset](https://docs.deps.dev/bigquery/v1/).
### Proposal
The [PackageVersions](https://docs.deps.dev/bigquery/v1/#pack...### Problem to solve
Create a source of `cargo` package metadata by importing data from the `deps.dev` [bigquery dataset](https://docs.deps.dev/bigquery/v1/).
### Proposal
The [PackageVersions](https://docs.deps.dev/bigquery/v1/#packageversions) table stores needed information in the `Name`, `Version` and `Licenses` columns. The `System` column is used to determine for which package registry to fetch data. In this case we are fetching for `CARGO`
Two modes are needed:
* delta: only for those packages that changed since last update
* full: import the full dataset (see the [ignore_cursor](https://gitlab.com/gitlab-org/security-products/license-db/license-feeder/-/blob/main/cmd/license-feeder/main.go?ref_type=heads#L96) argument)
### Implementation Plan
* [ ] Querying the `deps.dev` dataset
* [ ] Add [bigquery](https://pkg.go.dev/cloud.google.com/go/bigquery) package to project
* [ ] Extend gcp authentication to `bigquery`
* [ ] Add queries ( https://gitlab.com/gitlab-org/gitlab/-/issues/443840#note_1807939228)
* [ ] Delta between last saved snapshot and current
* [ ] Full export of snapshot
* [ ] Add InternalBucket cursor for `cargo`
* [ ] Support error scenarios for `bigquery`
* [ ] Client auth
* [ ] Query timeout
* [ ] Data errors (e.g. missing snapshot)
* [ ] Emit a well formed message on the `cargo` interfacer topic for each package
### Verification Steps
TBC
### Documentation
* [ ] Update [dev docs](https://gitlab.com/gitlab-org/security-products/license-db/deployment/-/blob/main/docs/fullstack_development.md) with any new instructions concerning `cargo` and `license-feeder`16.11Igor FrenkelIgor Frenkelhttps://gitlab.com/gitlab-org/gitlab/-/issues/448883Classify Threat Insights owned tables2024-03-19T18:18:51ZAlana Bellucciabellucci@gitlab.comClassify Threat Insights owned tablesIn this issue, we need to classify all the tables owned by Threat Insights and set the correct database for each of them.
Tables belong to either `gitlab_main_cell` or `gitlab_clusterwide`.In this issue, we need to classify all the tables owned by Threat Insights and set the correct database for each of them.
Tables belong to either `gitlab_main_cell` or `gitlab_clusterwide`.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/448882Add sharding keys to cell local tables2024-03-22T19:01:50ZAlana Bellucciabellucci@gitlab.comAdd sharding keys to cell local tablesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/448881Cells 1.0 Workflow Review2024-03-19T18:18:51ZAlana Bellucciabellucci@gitlab.comCells 1.0 Workflow Review# :fire: Smoke Tests :fire_engine:
## Configuration
This setup is recommended for testing to make sure users only have access to what they have with their associated permissions.
- _All tests assume that at least one security scan (of ...# :fire: Smoke Tests :fire_engine:
## Configuration
This setup is recommended for testing to make sure users only have access to what they have with their associated permissions.
- _All tests assume that at least one security scan (of any type, SAST, Dependency Scanning, etc.) is configured for each project._
- Security findings are available on two projects, each with the same group.
- Security findings are available for two different groups.
## Merge Request
- [ ] The merge request security widget displays vulnerability findings in the merge request. **[Failed on E2E Tests](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/2414#note_1771933952)**
- [ ] User can `Dismiss` a vulnerability from a finding with a reason (this will be limited to Maintainers and users with the `admin_vulnerabilty` role starting in %"17.0")
- [ ] User can create an issue from a vulnerability finding, **[Failed on E2E Tests](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/2414#note_1771972751)**
## Pipeline Security Tab
- [ ] The pipeline security tab displays vulnerability findings in the merge request.
- [ ] User can `Dismiss` a vulnerability from the pipeline security tab with a reason (this will be limited to Maintainers and users with the `admin_vulnerabilty` role starting in %"17.0"), **[Failed on E2E Tests](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/2414#note_1771972751)**
## Vulnerability Report
- [ ] Security reports last updated link to the correct pipeline
- [ ] SBOMs last updated link to the correct pipeline
_Check the following for Development vulnerabilities tab AND the Operational vulnerabilities tab._
- [ ] All filters work as expected; Status, Severity, Tool, Activity
- [ ] Group by options (project level) work as expected; Status, Severity, Tool, OWASP Top 10 2017
- [ ] Bulk actions work as expected
- [ ] Sort by severity, on the Severity column header, works as expected
## Vulnerability Page
_Please check each of the following at the project and group level._
- [ ] Status can be updated
- [ ] Project hyperlink opens to the right project
- [ ] Any Identifiers have the correct links
- [ ] File hyperlink opens to the correct location
- [ ] Pipeline the vulnerability was detected in links to the correct pipeline
- [ ] Any/all status changes appear on the vulnerability page as a system note
- [ ] Users can add an existing issue
- [ ] Vulnerability Explanation works as expected
- [ ] Vulnerability Resolution opens a new MR, **[Failed on E2E Tests](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/2414#note_1771933952)**
- [ ] Security Training Vendors (configured in Security Configuration) link to the correct vendor.
- [ ] Submit a manual vulnerability
- [ ] Export the Vulnerability report
## Dependency List
_Please check the following at the Project level_
- [ ] Chevron opens to associated vulnerabilities for a specific component
- [ ] All sort options are working as expected; Component name, Packager, and Severity
- [ ] _Software Bill of Materials (SBOM) based on the `latest successful scan`_ links to the correct pipeline job
- [ ] Export the Dependency list
_Please check the following at the Group level_
- [ ] All sort options are working as expected; Component name, Packager, and Severity
- [ ] Filters are working as expected; License and Project
- [ ] Export the Dependency list
## Security Dashboard (Project)
- [ ] Time-series graph of vulnerabilities by severity is accurate
## Security Dashboard (Group)
**[Failed on E2E Tests](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/2414#note_1772019177), Page did not fully load. This could be due to an unending async request or loading icon.**
- [ ] Vulnerabilities over time chart is accurate
- [ ] Project security status widget is accurate
## Security Center
- [ ] Add projects to the Vulnerability Report that the user has access to
- [ ] Add projects to the Security Dashboard that the user has access toBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/448879[Spike] - AI Gateway Implementation2024-03-22T19:32:00ZAlana Bellucciabellucci@gitlab.com[Spike] - AI Gateway Implementation## Summary - Why is this spike needed?
As a part of https://gitlab.com/groups/gitlab-org/-/epics/13024+, we will need to investigate what is required to move Vulnerability Explanation and Vulnerability Resolution to the AI Gateway.
As @...## Summary - Why is this spike needed?
As a part of https://gitlab.com/groups/gitlab-org/-/epics/13024+, we will need to investigate what is required to move Vulnerability Explanation and Vulnerability Resolution to the AI Gateway.
As @ghavenga [noted](https://gitlab.com/groups/gitlab-org/-/epics/13024#note_1803350324):
> The AI Gateway is provided in GitLab as a separate LLM client class, similar to how we currently interact with Anthropic and Vertex. We will need to rework our classes to use the new gateway client classes and then test that our integrations work correctly and our prompts are behaving as expected.
## Timebox Expectations
<How much time should be spent on this spike>
No more than 3 days, this work is completed by the end of %"16.11".
## Expected Outcomes
- [ ] Possible options are explored and documented
- [ ] Issues are created for implmentation
## Links/References
Some materials for getting started with the Gateway:
* https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/README.md?ref_type=heads
* https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/tree/main?ref_type=heads#local-development-using-gdk
* https://youtu.be/SXfLOYm4zS416.11https://gitlab.com/gitlab-org/gitlab/-/issues/448876Admin ability to restrict certain runner executor types2024-03-18T15:30:15ZAustin PierceAdmin ability to restrict certain runner executor types<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical detail...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
<!-- 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. -->
Add a method for self-managed admins to globally restrict certain runner type registrations. For example the customer in question wants the ability to globally restrict all runners that have a [shell executor](https://docs.gitlab.com/runner/executors/shell.html) from being used. This could be managed either at the registration level or after registration. Regardless this would ideally be managed from the Admin UI.
This aims to provide a solution to the issue raised by the customer. Shell executors have a security warning in our docs to let user's know that they are inherently more privileged on the runner host than other executor types and due to that have some security risk involved:
>Generally it’s unsafe to run jobs with shell executors. The jobs are run with the user’s permissions (gitlab-runner) and can “steal” code from other projects that are run on this server. Depending on your configuration, the job could execute arbitrary commands on the server as a highly privileged user. Use it only for running builds from users you trust on a server you trust and own.
Since many organizations do not restrict the ability to register runners, this leaves a situation where an inside threat actor could abuse the shell runner to gather privileged information shared on that runner.
We currently don't have a supported method for identifying and restricting what types of executors a runner is registered with. Tags could offer a solution but only in a limited capacity, which would also require custom scripting from the customer to achieve something similar to the above described solution.
<!-- 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:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->Awaiting further demandhttps://gitlab.com/gitlab-org/gitlab/-/issues/448868When visiting a file (blob) page provide a way to see the list of Open MRs ta...2024-03-27T06:06:08ZAndré Luísaluis@gitlab.comWhen visiting a file (blob) page provide a way to see the list of Open MRs targeting that file<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
We all know how painful conflicts are. Git and gitlab do a fairly good job at dealing with them when they ha...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
We all know how painful conflicts are. Git and gitlab do a fairly good job at dealing with them when they happen but how about avoiding them?
What if we could leverage the data we have at our disposal that is not in Git to promote more efficient collaboration by raising awareness of currently-in-flight work that could impact what you're doing?
**Proposal:** When seeing a specific file in the repository, add a way to see the list of Open MRs that touch that file.
### Context:
#### Why is this useful information?
Especially in the context of refactors that touch many files or simply rename some, knowing this information allows the contributor to plan accordingly. Time the contribution in a way that causes the least disruption to others work.
This feature leverages data that GitLab harnesses but Git isn't able to provide on its own.
### Details
* For performance reasons, we might want to make this call happen on-demand (at least to start with)
* It should list any MR which latest version includes at least one change to the current file.
* There is work in flight to simplify the UI, so this should be added under the context of that effort (ellipsis menu?)
* While the number of open MRs targeting this file is useful, knowing which MRs is where the usefulness starts.
* Perhaps after we have this we might drill deeper and do the same at the line level.
<!-- 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:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->Next 1-3 releaseshttps://gitlab.com/gitlab-org/gitlab/-/issues/448760Include full Gitaly error message in the UI when repository import fails2024-03-12T10:06:39ZChris StoneInclude full Gitaly error message in the UI when repository import fails<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
When the importation of a repository to GitLab.com fails, the only error description available to the end us...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
When the importation of a repository to GitLab.com fails, the only error description available to the end user, reported at `https://gitlab.com/<project path>/-/import/new`, is somewhat terse and does not include the full error. For example:
![image](/uploads/2b0877bab2d97f3794fca0aa09cf99f7/image.png){width=40%}
The only way to determine the root cause is by examination of Gitaly logs, which for GitLab.com would require a ticket raised with support.
We could add the full `json.error_metadata.stderr (as seen in the log)` which would go a long way to enabling the end user to be self-sufficient, for example:
```
creating repository: cloning repository: exit status 128
error: object 83db39a8630e64c5200c0644126fc6f0bfe69e07: hasDotgit: contains '.git'
fatal: fsck error in packed object
fatal: fetch-pack: invalid index-pack output
```
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/448645Add custom roles to protected branch rules configuration2024-03-19T19:06:53ZChristopher Guitartecguitarte@gitlab.comAdd custom roles to protected branch rules configuration### Proposal
For some customers, not all developers should be able to push and merge to protected branches. Additionally, not all developers should be upgraded to Maintainer. However it can be too cumbersome to manually select individua...### Proposal
For some customers, not all developers should be able to push and merge to protected branches. Additionally, not all developers should be upgraded to Maintainer. However it can be too cumbersome to manually select individual users to give them granular permissions on a per project level.
We will need a capability to create a [custom role](https://docs.gitlab.com/ee/user/custom_roles.html), assign to a subset of users in the group hierarchy and use that custom role as an approved role to Push and Merge on a protected branch.
Related customer conversation: https://hello.chorus.ai/listen?guid=ffed32f46f8e44898b692fdf7de85433 (GitLab team member only access)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/448640Align container user's home directory value in /etc/passwd and HOME env variable2024-03-07T20:43:58ZOscar TovarAlign container user's home directory value in /etc/passwd and HOME env variable## Summary
The Gemnasium analyzers have a mismatch between the home directory value in `/etc/passwd` and the HOME environment variable. This has caused issues in the past as can be seen in https://gitlab.com/gitlab-org/gitlab/-/issues/3...## Summary
The Gemnasium analyzers have a mismatch between the home directory value in `/etc/passwd` and the HOME environment variable. This has caused issues in the past as can be seen in https://gitlab.com/gitlab-org/gitlab/-/issues/374571.
To prevent this from happening in the future elsewhere, and to prevent a regression of https://gitlab.com/gitlab-org/gitlab/-/issues/374571, we should align these values. Here's an example of how the `/etc/passwd` file looks like in `gemnasium-maven`.
```sh
root@58a0e8bc3a26:~# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
```
And here's how `$HOME` is set:
```sh
root@58a0e8bc3a26:~# echo $HOME
/gemnasium-maven
```
The correct behavior would be for the `/etc/passwd` file to contain:
```sh
root@58a0e8bc3a26:~# cat /etc/passwd
root:x:0:0:root:/gemnasium-maven:/bin/bash
```
## Improvements
Removes the possibility of a regression of https://gitlab.com/gitlab-org/gitlab/-/issues/374571+s.
## Risks
<!--
Please list features that can break because of this refactoring and how you intend to solve that.
-->
- Editing a `/etc/passwd` file manually (without `usermod` or `useradd`) is risky. We could mitigate this by adding a `gitlab` non-root user instead. If https://gitlab.com/gitlab-org/gitlab/-/issues/431945+ is completed then the new user should be checked to ensure consistency between `$HOME` and `/etc/passwd`
## Involved components
<!--
List files or directories that will be changed by the refactoring.
-->
- `build/*/*/Dockerfile`
- All the `Dockerfile` files will need to be updated to use the correct home directory.
<!--
Please select the appropriate label from the following:
~"feature::addition"
~"type::maintenance"
~"maintenance::refactor"
~"maintenance::pipelines"
~"maintenance::workflow"
-->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/448637Search for project settings via the command palette2024-03-26T20:41:03ZJeff TuckerSearch for project settings via the command palette<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated us...<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab.
The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). -->
### Release notes
<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
### Problem to solve
* GitLab offers many settings across project, group, instance, and personal levels.
* Users find it difficult to know where to look for a given setting.
* They have to spend time looking through many possible locations in order to find the right spot.
### Proposal
* Add support for searching section headers for **project settings** in global search
* Users must enter "command mode" to search for section headers
* Users can only see results for pages they have access to
* When a search result is selected, navigate the user to the appropriate settings page with the selected section pre-expanded
### Intended users
Individuals that need to manage settings for their project, especially those that infrequently visit the settings page (and thus may not recall exactly where their desired setting lives)
* [Delaney (Development Team Lead)](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead)
* [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer)
* [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator)
* [Rachel (Release Manager)](https://handbook.gitlab.com/handbook/product/personas/#rachel-release-manager)
* [Allison (Application Ops)](https://handbook.gitlab.com/handbook/product/personas/#allison-application-ops)
* [Isaac (Infrastructure Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer)
* [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager)
### Feature Usage Metrics
<!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide.
-->
Likely covered by https://gitlab.com/gitlab-org/gitlab/-/issues/438845+s
### Does this feature require an audit event?
<!--- Checkout these docs to know more
https://docs.gitlab.com/ee/development/audit_event_guide/#what-are-audit-events
https://docs.gitlab.com/ee/administration/audit_events.html
--->
No, this feature only impacts navigation. It does not change any permissions or data.
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->
<!-- 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 -->17.0https://gitlab.com/gitlab-org/gitlab/-/issues/448593Security Policy Project modal refreshes dropdown when bottom is reached inste...2024-03-11T05:31:01ZAlexander Turinskeaturinske@gitlab.comSecurity Policy Project modal refreshes dropdown when bottom is reached instead of showing loading icon and adding more options## Summary
- Security Policy Project modal refreshes dropdown when bottom is reached instead of showing loading icon and adding more options
The following discussion from !145045 should be addressed:
- [ ] @bauerdominic started a [dis...## Summary
- Security Policy Project modal refreshes dropdown when bottom is reached instead of showing loading icon and adding more options
The following discussion from !145045 should be addressed:
- [ ] @bauerdominic started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145045#note_1803132858): (+3 comments)
> As the query doesn't support pagination, do we need those parameters?
## Implementation
- [ ] ~frontend update [spp_selector](https://gitlab.com/gitlab-org/gitlab/-/blob/1ee5363eb4e8c9942a5cc07b71a15ec706634104/ee/app/assets/javascripts/security_orchestration/components/policies/spp_selector.vue) to implement infinite scroll without the dropdown refreshing the whole list ([like the storybook example](https://gitlab-org.gitlab.io/gitlab-ui/?path=/docs/base-dropdown-collapsible-listbox--docs#infinite-scroll))Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/448542Analytics dashboards - Add optional `feature_flag` setting to visualization c...2024-03-20T19:13:37ZAlex PennellsAnalytics dashboards - Add optional `feature_flag` setting to visualization configThis issue was created to solve the problem presented in [this thread](https://gitlab.com/gitlab-org/gitlab/-/issues/408516#note_1792191901)
### Problem
When developing new analytics dashboard visualizations, we don't have a good way t...This issue was created to solve the problem presented in [this thread](https://gitlab.com/gitlab-org/gitlab/-/issues/408516#note_1792191901)
### Problem
When developing new analytics dashboard visualizations, we don't have a good way to toggle visibility based on a feature flag.
### Proposed solution
Add a new `feature_flag` option to the [visualization schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json) that allows showing/hiding the visualization based on a given feature flag.
```diff
---
version: 1
type: NewDashboardPanel
+feature_flag: new_dashboard_panel
data:
type: value_stream
query: {}
options: {}
```Next 1-3 releaseshttps://gitlab.com/gitlab-org/gitlab/-/issues/446262Increase Rate Limit on User API Threshold to 1000 for SaaS customers2024-03-07T20:36:41Zjgleason1Increase Rate Limit on User API Threshold to 1000 for SaaS customers### Problem to solve
A [large Ultimate, SaaS customer](https://gitlab.my.salesforce.com/0014M00001gAdAjQAK) is requesting that our Rate Limit for the User API threshold be increased to 1000. The current limit of 300 requests per 10 min...### Problem to solve
A [large Ultimate, SaaS customer](https://gitlab.my.salesforce.com/0014M00001gAdAjQAK) is requesting that our Rate Limit for the User API threshold be increased to 1000. The current limit of 300 requests per 10 minutes is causing this customer to receive 429 errors.
Use Case: [Support ticket](https://gitlab.zendesk.com/agent/tickets/506594)
### Proposal
Increase Rate Limit for the User API threshold be increased to 1000 or potentially even raising it to only 450.
### Intended users
* [Parker (Product Manager)](https://handbook.gitlab.com/handbook/product/personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead)
* [Presley (Product Designer)](https://handbook.gitlab.com/handbook/product/personas/#presley-product-designer)
* [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer)
* [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer)
* [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator)
* [Rachel (Release Manager)](https://handbook.gitlab.com/handbook/product/personas/#rachel-release-manager)
* [Simone (Software Engineer in Test)](https://handbook.gitlab.com/handbook/product/personas/#simone-software-engineer-in-test)
* [Allison (Application Ops)](https://handbook.gitlab.com/handbook/product/personas/#allison-application-ops)
* [Ingrid (Infrastructure Operator)](https://handbook.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator)
* [Dakota (Application Development Director)](https://handbook.gitlab.com/handbook/product/personas/#dakota-application-development-director)
* [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer)
* [Isaac (Infrastructure Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer)
* [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer)
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->https://gitlab.com/gitlab-org/gitlab/-/issues/446235Threat Insights 17.0 Planning Issue2024-03-06T19:27:18ZAlana Bellucciabellucci@gitlab.comThreat Insights 17.0 Planning IssueREMOVALS!!! - https://gitlab.com/groups/gitlab-org/-/epics/10425+REMOVALS!!! - https://gitlab.com/groups/gitlab-org/-/epics/10425+17.0https://gitlab.com/gitlab-org/gitlab/-/issues/446176Geo: Improve chances of the first stage of the pipeline being accelerated by ...2024-03-25T02:03:15ZSampath RanasingheGeo: Improve chances of the first stage of the pipeline being accelerated by Geo secondary<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated us...<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab.
The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). -->
### Release notes
<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
### Problem to solve
Geo accelerates CI runners by allowing them to clone from secondary sites. However, the clone for the first stage of the pipeline is almost always proxied to the primary site. This is because the verification of the replicated changes (such as pipeline ref) has not been completed by the time the first stage of the pipeline is executed. Typically it takes about 90 seconds for the verification to complete on a lightly loaded deployment.
This issue is a follow on from discussions had [here](https://gitlab.com/gitlab-org/gitlab/-/issues/415179#note_1752250854)
### Proposal
Ensure that the clone for the first stage of the pipeline is guaranteed or has a higher chance of being served from a secondary site.
Some options that have been discussed:
- The decision to proxy the request to the primary is not made on the status of verification but instead on the status of replication
- Delay the clone request at the secondary site until replication and verification is complete.
### Intended users
* [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer)
* [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator)