GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2023-05-15T07:50:33Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/32793Determine if Sentry browser SDK initialization can be optimized2023-05-15T07:50:33ZDennis TangDetermine if Sentry browser SDK initialization can be optimizedThe loading of the Sentry browser SDK is quite performance-intensive. We should take a look if the init can be optimized.
![firefox_2019-01-14_15-25-37](/uploads/978b0344f8989bf982209355e004b7b7/firefox_2019-01-14_15-25-37.png)
As per ...The loading of the Sentry browser SDK is quite performance-intensive. We should take a look if the init can be optimized.
![firefox_2019-01-14_15-25-37](/uploads/978b0344f8989bf982209355e004b7b7/firefox_2019-01-14_15-25-37.png)
As per Sentry's [documentation](https://docs.sentry.io/platforms/javascript/#lazy-loading-sentry), it may be advisable to consider lazy-loading Sentry, which may involve using their wrapper hosted on their CDN. This would require a bit of a change instead of self-hosting the dependency.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/26761[QA] Avoid loading the login page twice2019-11-06T04:41:58ZMark Lapierre[QA] Avoid loading the login page twiceThe following discussion from gitlab-ce!25257 should be addressed:
- [ ] @ddavison started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25257#note_141483358): (+5 comments)
> this change ... will open up t...The following discussion from gitlab-ce!25257 should be addressed:
- [ ] @ddavison started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25257#note_141483358): (+5 comments)
> this change ... will open up the login page twice, no?
Ideally, the test framework should only open the login page once. It might be possible to have the login page check if it's already loaded. But calling `QA::Runtime::Browser.visit` multiple times might also be a problem. I'll need to investigateBacklogMark LapierreMark Lapierrehttps://gitlab.com/gitlab-org/gitlab/-/issues/26500Mailing list: add model and UI for mailing list settings2021-05-10T00:30:11ZJan Provaznikjprovaznik@gitlab.comMailing list: add model and UI for mailing list settingsSubtask of https://gitlab.com/gitlab-org/gitlab-ce/issues/4272#note_115526454
* adds model for mailing list functionality
* adds basic UI for mailing list setting, I expect that for first iteration we will use email addresses from `gitl...Subtask of https://gitlab.com/gitlab-org/gitlab-ce/issues/4272#note_115526454
* adds model for mailing list functionality
* adds basic UI for mailing list setting, I expect that for first iteration we will use email addresses from `gitlab.yml` so there should not be much to set except enabling/disabling the ML
* adds feature flag for mailing list functionality
Mostly already done by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17502BacklogRiccardo PadovaniRiccardo Padovanihttps://gitlab.com/gitlab-org/gitlab/-/issues/9276Improving configuration for Group SAML: Discovery2023-12-18T05:28:32ZJeremy Watson (ex-GitLab)Improving configuration for Group SAML: DiscoveryThe current configuration page for Group SAML SSO is a little daunting:
![image](/uploads/3a23e4bbf0f9eb73d0a339eba31097e4/image.png)
It's intentionally comprehensive, since many providers have different language/terms that we need to...The current configuration page for Group SAML SSO is a little daunting:
![image](/uploads/3a23e4bbf0f9eb73d0a339eba31097e4/image.png)
It's intentionally comprehensive, since many providers have different language/terms that we need to be aware of. When we did user testing, SAML experts quickly navigated this page. Newcomers struggled and took extra time to parse/understand the terms, and we should ideally make configuration digestible for someone setting up SAML for the first time.
### Proposal
We should explore opportunities to break this page down:
* Which options can we conceal/collapse?
* Can we explore breaking configuration into multiple steps?
* Can we create a wizard for making configuration super easy for common providers? e.g. pick Okta/Azure/OneLogin for a super easy configuration with an Other option for a more manual setup?
### References
GitHub's configuration page:
![image](/uploads/2045b988a409d6e87969a3403858f4bd/image.png)Next 4-6 releaseshttps://gitlab.com/gitlab-org/gitlab/-/issues/26057Accommodate offline users after help links switched to docs.gitlab.com site2020-06-19T14:31:26ZMike LewisAccommodate offline users after help links switched to docs.gitlab.com site### Problem to solve
If we update help links from inside GitLab CE/EE to their equivalent paths on docs.gitlab.com (i.e. deprecate the `<instanceDomain>/help` path), this will affect the small subset of users who use GitLab while they a...### Problem to solve
If we update help links from inside GitLab CE/EE to their equivalent paths on docs.gitlab.com (i.e. deprecate the `<instanceDomain>/help` path), this will affect the small subset of users who use GitLab while they are not connected to the internet.
Most solutions to this involve leaving the docs in place on the GitLab instance at /help, allowing such users to visit that copy of the content, instead. That content will be missing some features that we are only able to provide on the site, like the rendering of a table of contents, and working links to other top-level paths outside of /ee or /ce such as /omnibus and /runner.
### Target audience
Users who are able to connect to their GitLab instance but *not* the internet or otherwise cannot access docs.gitlab.com.
### Further details
This helps toward the goal of allowing a single app for the DevOps lifecycle for any kind of user regardless of environment. Given that we are already building /help with the product, with a few changes, we can make the app easier to use for offline users (or prevent a degradation of their experience) while vastly improving the experience for everyone else by further leveraging docs.gitlab.com.
### Proposal
The optimal solution may be
- Allow the admin to toggle the help path
- Allow them to use `<instanceDomain>/help/` instead of `docs.gitlab.com/<edition>/<version>/` .
- But we'd need to account for how to handle future links we add in the UI to other top-level paths like /runner and /omnibus that are not included in /help and only on the doc site. And perhaps avoid relative links in CE/EE docs to these other top level paths, so that users in /help will at least have the option to go online and have a working link.
- Also allow them to use a custom path. This allows them to build the doc site on their network or user's local machine.
- This will require improved build instructions and perhaps the ability to toggle off items that will only work on docs.gitlab.com, such as comments.
### What does success look like, and how can we measure that?
- Positive feedback from GitLabbers who consult with customers or prospects in such offline / highly secure environments.
### Links / references
1. https://gitlab.com/gitlab-org/gitlab-ce/issues/18739
1. https://gitlab.com/gitlab-org/gitlab-ce/issues/56101
Note: We can add further gitlab-docs project needs to the same epic once the [project's move](https://gitlab.com/gitlab-com/gitlab-docs/issues/310) is complete.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/25859Handle invalid import provider token on clientside - https://gitlab.com/gitla...2024-03-18T19:22:00ZLuke BennettHandle invalid import provider token on clientside - https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22458 follow uphttps://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22458#note_126192955
In `Import::GithubController#status` we get the provider repos to render the list of repos to import. There is a chance this request errors because of an invali...https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22458#note_126192955
In `Import::GithubController#status` we get the provider repos to render the list of repos to import. There is a chance this request errors because of an invalid private token. A spec covers this.
During https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22458 I moved a lot of this to be rendered on the clientside and moved all the query logic to a `respond_to` `:json` block. The one thing I didn't move is the error handling of that initial provider repos request. Because of this, we now call `client_repos` outside of the `respond_to` block to ensure that a user visiting the import table on a browser see's an error page.
This isn't pretty as it requires a comment for the `client_repos` call to make sense. We should instead handle the private token validity error on the frontend by consuming a JSON error response.
**Goal:** Remove `client_repos` call in `Import::GithubController#status` that is not a part of the `respond_to` block.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/25713Add QA selectors for quick action buttons on Project UI page2019-11-06T04:43:36ZMark LapierreAdd QA selectors for quick action buttons on Project UI pageThe following discussion from gitlab-ce!23366 should be addressed:
- [ ] @sliaquat started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23366#note_123944219): (+2 comments)
> Should we use class selector h...The following discussion from gitlab-ce!23366 should be addressed:
- [ ] @sliaquat started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23366#note_123944219): (+2 comments)
> Should we use class selector here instead of text?
> We would need to add a qa class (say `qa-new-file-button`) [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/presenters/project_presenter.rb#L200) and for selector sanity check add this to [qa/qa/page/component/clone_panel.rb](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/qa/qa/page/component/clone_panel.rb):
>
> ```
> base.view 'app/presenters/project_presenter.rb' do
> element :new_file_button
> end
> ```
It looks like they're defined in `app/views/projects/_stat_anchor_list.html.haml` as:
```haml
- anchors = local_assigns.fetch(:anchors, [])
- return unless anchors.any?
%ul.nav
- anchors.each do |anchor|
%li.nav-item
= link_to_if anchor.link, anchor.label, anchor.link, class: anchor.enabled ? 'nav-link stat-link' : "nav-link btn btn-#{anchor.class_modifier || 'missing'}" do
.stat-text= anchor.label
```
So adding selectors isn't as simple as inserting them here into the `.haml`. It looks like we might also need to modify `app/presenters/project_presenter.rb`, which seems to be where the `anchors` data comes from.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/25137Improve E2E test performance by using waits more efficiently2020-02-23T18:29:11ZMark LapierreImprove E2E test performance by using waits more efficientlyIn https://gitlab.com/gitlab-org/gitlab-ce/issues/46074 we discussed changing `default_max_wait_time` to 0 but decided that the problem we were actually trying to solve was that we were forcing Capybara to wait unnecessarily.
## Proposa...In https://gitlab.com/gitlab-org/gitlab-ce/issues/46074 we discussed changing `default_max_wait_time` to 0 but decided that the problem we were actually trying to solve was that we were forcing Capybara to wait unnecessarily.
## Proposal
- [ ] Add wait/predicate/performance best practices to QA docs
- [ ] Identify the places where we're forcing Capybara to wait, and either use predicate methods (e.g., `has_element?`) appropriately or eliminate them entirely.
- [ ] Review usage of predicate methods to determine if they should be assertions (i.e., should an exception be raised if the predicate returns `false`?)
For example:
```ruby
def has_merge_options?
has_css?(element_selector_css(:merge_moment_dropdown))
end
def merge_immediately
if has_merge_options?
click_element :merge_moment_dropdown
click_element :merge_immediately_option
else
click_element :merge_button
end
end
```
Every time `has_merge_options?` returns false there a delay that doesn't need to occur. We should know whether a test needs to use the dropdown or not, so there's no need for `has_merge_options?`.
/cc @gl\-qualityBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/8291Test plan for "Multiple approval groups/rules"2020-08-14T15:45:56ZMark LapierreTest plan for "Multiple approval groups/rules"## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ee/issues/1979. The feature allows approval to be required from multiple rules, where a rule is a group (or lists of users) and a number indicating the number of...## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ee/issues/1979. The feature allows approval to be required from multiple rules, where a rule is a group (or lists of users) and a number indicating the number of required approvals.
## Scope
- EE-only (Starter and Premium)
## ACC Matrix
| | Secure | Responsive | Intuitive | Reliable |
|------------|:------:|:----------:|:---------:|:--------:|
| Project | | | | |
| MRs | | | | |
| Settings | | | | |
| API | | | | |
For more information see the [Google Testing Blog article about the 10 minute
test plan](https://testing.googleblog.com/2011/09/10-minute-test-plan.html) and
[this wiki page from an open-source tool that implements the ACC
model](https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki).
## Capabilities
Settings are:
* Intuitive
- Rules can be specified in the Project settings
* Reliable
- It's not possible to require more approvals than there are users specified in a rule. I.e., if a rule lists 2 users it should not be possible to require 3 approvals from that group.
MRs are:
* Intuitive
- If project settings allow overriding approvers, the list of approvers and number of approvals can be modified.
- Authors can self-approve if the setting is enabled and they are in one of the rules.
## Test Plan
[Test Coverage sheet](https://docs.google.com/spreadsheets/d/1RlLfXGboJmNVIPP9jgFV5sXIACGfdcFq1tKd7xnlb74/)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/8286Test plan for "Mirror changes from Web IDE to CI runner"2020-08-14T15:45:58ZMark LapierreTest plan for "Mirror changes from Web IDE to CI runner"# Test Plan
## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ee/issues/5276 and extends https://gitlab.com/gitlab-org/gitlab-ee/issues/7658. The feature allows a user to open a web terminal from the Web IDE an...# Test Plan
## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ee/issues/5276 and extends https://gitlab.com/gitlab-org/gitlab-ee/issues/7658. The feature allows a user to open a web terminal from the Web IDE and execute commands against the code as it exists in the Web IDE (i.e., the current state of the code, not the latest commit).
Implementation details are still under discussion.
## Scope
* EE-only (Ultimate)
* The terminal will include the current state of the code in the Web IDE.
* Starting/stopping the web terminal and basic functionality is covered as part of https://gitlab.com/gitlab-org/gitlab-ee/issues/7658. This test plan focuses on mirroring changes during an active session. But it should include what happens when a session is interrupted.
## ACC Matrix
| | Secure | Responsive | Intuitive | Reliable |
|-------------|:------:|:----------:|:---------:|:--------:|
| Web IDE | | | | |
For more information see the [Google Testing Blog article about the 10 minute
test plan](https://testing.googleblog.com/2011/09/10-minute-test-plan.html) and
[this wiki page from an open-source tool that implements the ACC
model](https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki).
## Capabilities
Web IDE is:
* Reliable
* Code changes made in the Web IDE are available in the web terminal without undue delay.
* Intuitive
* It's clear when code changes made in the IDE will be available in the web terminal. E.g., if the user has to save their changes first, the UI should make that clear.
* It's clear what's happening if there is a delay in syncing data from the Web IDE to the web terminal. I.e., there is some kind of indication that data is out of sync and is being updated.
## Test Plan
End-to-end tests:
* Add and configure a runner, push code to a project, and then
* start the web terminal and `cat` the changed file
* make a change to a project via the Web IDE and `cat` the changed file
[Test Coverage sheet](https://docs.google.com/spreadsheets/d/1RlLfXGboJmNVIPP9jgFV5sXIACGfdcFq1tKd7xnlb74/)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/24665Test plan for "SSH push mirroring support with public-key authentication"2020-08-14T15:47:02ZMark LapierreTest plan for "SSH push mirroring support with public-key authentication"# Test Plan
## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ce/issues/49565. The feature allows remote repositories to be updated via SSH push mirroring with public-key authentication.
## Scope
* Push mirro...# Test Plan
## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ce/issues/49565. The feature allows remote repositories to be updated via SSH push mirroring with public-key authentication.
## Scope
* Push mirroring, not pull
* Public-key authentication *or* password
## ACC Matrix
| | Secure | Responsive | Intuitive | Reliable |
|------------|:------:|:----------:|:---------:|:--------:|
| Repository | | | | |
For more information see the [Google Testing Blog article about the 10 minute
test plan](https://testing.googleblog.com/2011/09/10-minute-test-plan.html) and
[this wiki page from an open-source tool that implements the ACC
model](https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki).
## Capabilities
* Respository is
* Secure
* Mirroring can use public-key authentication.
* When using password authentication the password is obscured (known risk: password is sent as clear text).
* Intuitive
* Configuring mirror direction and authentication is simple.
* A key pair is generated automatically and the user can easily copy the public key.
* Responsive
* Mirroring can be initiated on-demand.
* Reliable
* Changes continued to be mirrored as they are made.
## Test Plan
### End-to-end tests:
Scenario 1: Push mirror using public-key authentication
1. Create source and target projects, configure push to target using SSH keys, push.
1. Check project exists on target with latest change.
1. Make a change to source project. Update mirroring.
1. Check target for update.
Scenario 2: Push mirror using password authentication
1. As above, but using a password
[Test Coverage sheet](https://docs.google.com/spreadsheets/d/1RlLfXGboJmNVIPP9jgFV5sXIACGfdcFq1tKd7xnlb74/)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/7658Test plan for "Open Web Terminal from attached CI runner in Web IDE"2020-08-14T15:48:03ZMark LapierreTest plan for "Open Web Terminal from attached CI runner in Web IDE"# Test Plan
## Introduction
This test plan is for #5426. The feature allows a user to open a web terminal from the Web IDE and execute commands against the latest committed version of their code.
## Scope
* EE-only (Ultimate)
* The t...# Test Plan
## Introduction
This test plan is for #5426. The feature allows a user to open a web terminal from the Web IDE and execute commands against the latest committed version of their code.
## Scope
* EE-only (Ultimate)
* The terminal will include only the latest commit, not any uncommited changes. A new commit will destroy the current web terminal instance and replace it.
* The web terminal is displayed as a vertical panel. It can be resized but not moved.
## ACC Matrix
| | Simple | Secure | Responsive | Intuitive | Reliable |
|-------------|:------:|:------:|:----------:|:---------:|:--------:|
| Web IDE | | | | | |
| CI/CD | | | | | |
For more information see the [Google Testing Blog article about the 10 minute
test plan](https://testing.googleblog.com/2011/09/10-minute-test-plan.html) and
[this wiki page from an open-source tool that implements the ACC
model](https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki).
## Capabilities
Web IDE is:
* Intuitive
* When a new commit is made and the web terminal is already open the change in the web terminal is clear.
* If a runner it not available the user is appropriately informed.
* The terminal behaves as a typical terminal
* Reliable
* All code up to the latest commit can be accessed via the web terminal.
* Responsive
* The web terminal can be resized.
CI/CD is:
* Secure
* The web terminal should allow access only to the code for the project. If a runner is reused or shared there should be no trace of any previous code or code from another project.
* Only applicable runners are used for the web terminal.
## Test Plan
End-to-end tests:
* Add and configure a runner, push a change to a project, and then
* start the web terminal and `cat` the changed file
* make a change to a project via the Web IDE, commit it and `cat` the changed file
* Start the web terminal while there are no runners available. Check that there is an appropriate message.
* Check that the web terminal can't be started if there is no `web-ide` job defined in `.gitlab-ci.yml`.
* Check that the web terminal can be stopped and restarted and that there is appropriate feedback.
[Test Coverage sheet](https://docs.google.com/spreadsheets/d/1RlLfXGboJmNVIPP9jgFV5sXIACGfdcFq1tKd7xnlb74/)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/6194Make LFS file locking use the same DB table than File Locking feature2023-09-08T12:04:44ZRubén DávilaMake LFS file locking use the same DB table than File Locking featureRight now we use separate tables for LFS file locking and the File Locking feature.
Given these features are very similar with the main difference that File Locking has a UI to lock/unlock a file we should consider using a single table ...Right now we use separate tables for LFS file locking and the File Locking feature.
Given these features are very similar with the main difference that File Locking has a UI to lock/unlock a file we should consider using a single table in order to avoid some DB complexity and also try to reuse some code.
This change should consider two important things:
1. Migrate the data from the LFS file locking table to the table used by File Locking.
1. Backport to CE the necessary changes.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/1413Gotcha with guard clause in overridden methods2020-07-23T16:40:50ZRémy CoutableGotcha with guard clause in overridden methodsThe proper way of handling anonymous rules should be by overriding `#anonymous_rules` in `BasePolicy` subclasses. The default for `#anonymous_rules` is `#rules`.
As mentioned in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/822...The proper way of handling anonymous rules should be by overriding `#anonymous_rules` in `BasePolicy` subclasses. The default for `#anonymous_rules` is `#rules`.
As mentioned in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/822#note_19898741, an early `return` does not return from the "overrider" method (be it via inheritance or via `prepend`).
For instance:
```ruby
# app/policies/group_policy.rb
class GroupMemberPolicy < BasePolicy
def rules
return unless @user
target_user = @subject.user
group = @subject.group
return if group.last_owner?(target_user)
can_manage = Ability.allowed?(@user, :admin_group_member, group)
if can_manage
can! :update_group_member
can! :destroy_group_member
elsif @user == target_user
can! :destroy_group_member
end
end
end
# app/policies/ee/group_policy.rb
module EE
module GroupPolicy
def rules
raise NotImplementedError unless defined?(super)
super
owner = @user.admin? || @subject.has_owner?(@user)
master = owner || @subject.has_master?(@user)
if @subject.ldap_synced?
cannot! :admin_group_member
can! :override_group_member if master
end
end
end
end
=> NoMethodError - undefined method `admin?' for nil:NilClass:
app/policies/ee/group_policy.rb:8:in `rules
```
So there's two thing here:
1. Audit our current usage of prepend and make sure we don't have code that don't behave as we'd expect
1. When guard clauses are used in an overridden method, another strategy (documented by https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/963/diffs) should be used:
> create a "hook" method that is empty in CE, and with the EE-specific implementation in EEBacklog