GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2022-11-22T20:21:07Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/24150Consolidate UI page widths - Part 08: Operations2022-11-22T20:21:07ZAndreas KämmerleConsolidate UI page widths - Part 08: Operations### Problem to solve
Via [this design pattern issue](https://gitlab.com/gitlab-org/design.gitlab.com/issues/47) we explored how to consolidate our page widths (`990px`, `1280px`, `full-width`). The overall goal is to simplify and move m...### Problem to solve
Via [this design pattern issue](https://gitlab.com/gitlab-org/design.gitlab.com/issues/47) we explored how to consolidate our page widths (`990px`, `1280px`, `full-width`). The overall goal is to simplify and move most pages to a width of `990px`.
In addition, we are tackling a second iteration https://gitlab.com/gitlab-org/design.gitlab.com/issues/103 to identify if we can get right of the larger width `1280px` completely by moving these to either the smaller width or full width.
### Proposal
This issue serves as the corresponding implementation part. I expect that related changes will be split into several MRs and potentially be implemented across a few milestones.
Scope: All sub-pages of "Operations"
### What does success look like, and how can we measure that?
We reduced the available range of page widths to simplify FE environment, reduce complexity and improve readability in the UI.https://gitlab.com/gitlab-org/gitlab/-/issues/24149Consolidate UI page widths - Part 07: Project settings2023-08-10T10:08:42ZAndreas KämmerleConsolidate UI page widths - Part 07: Project settings### Problem to solve
Via [this design pattern issue](https://gitlab.com/gitlab-org/design.gitlab.com/issues/47) we explored how to consolidate our page widths (`990px`, `1280px`, `full-width`). The overall goal is to simplify and move m...### Problem to solve
Via [this design pattern issue](https://gitlab.com/gitlab-org/design.gitlab.com/issues/47) we explored how to consolidate our page widths (`990px`, `1280px`, `full-width`). The overall goal is to simplify and move most pages to a width of `990px`.
In addition, we are tackling a second iteration https://gitlab.com/gitlab-org/design.gitlab.com/issues/103 to identify if we can get right of the larger width `1280px` completely by moving these to either the smaller width or full width.
### Proposal
This issue serves as the corresponding implementation part. I expect that related changes will be split into several MRs and potentially be implemented across a few milestones.
Scope: All sub-pages of "Project/Settings"
### What does success look like, and how can we measure that?
We reduced the available range of page widths to simplify FE environment, reduce complexity and improve readability in the UI.https://gitlab.com/gitlab-org/gitlab/-/issues/24144Markdown image alt text is not shown as a tooltip (image title) on hover2019-11-05T18:36:57ZTaylor Braun-JonesMarkdown image alt text is not shown as a tooltip (image title) on hover### Summary
The [documentation here](https://docs.gitlab.com/ce/user/markdown.html#images) says I should be able to see the alt text of the images by hovering my mouse over the image, but I cannot.
### Relevant logs and/or screenshots
...### Summary
The [documentation here](https://docs.gitlab.com/ce/user/markdown.html#images) says I should be able to see the alt text of the images by hovering my mouse over the image, but I cannot.
### Relevant logs and/or screenshots
Tested on:
<details><summary>Chrome 68</summary>
<pre>
Google Inc.
Copyright 2018 Google Inc. All rights reserved.
Google Chrome 68.0.3440.106 (Official Build) (64-bit)
Revision 1c32c539ce0065a41cb79da7bfcd2c71af1afe62-refs/branch-heads/3440@{#794}
OS Linux
JavaScript V8 6.8.275.26
Flash 31.0.0.108 /home/tbraunjones/.config/google-chrome/PepperFlash/31.0.0.108/libpepflashplayer.so
User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Command Line /usr/bin/google-chrome-stable --flag-switches-begin --flag-switches-end
Executable Path /opt/google/chrome/google-chrome
Profile Path /home/tbraunjones/.config/google-chrome/Default
Variations c134752e-1ece3553
59aeb88e-3f4a17df
1a0d11d4-2f9febdf
ebeb14fc-3f4a17df
34a6bf44-ca7d8d80
752a9400-3d47f4f4
bacf97b2-ca7d8d80
241fff6c-1623a499
3095aa95-3f4a17df
7c1bc906-f55a7974
47e5d3db-3d47f4f4
125b7f68-25d35d0e
1149accc-f23d1dea
4dc30737-b8a5ea08
c865fdc1-ca7d8d80
a582a1b8-ad75ce17
3042ad4b-ca7d8d80
ebbb4e0a-ca7d8d80
267255c3-f4950e99
44827ee5-3f4a17df
8f1e27f-ca7d8d80
43f62d3b-28165b59
165e16d1-3f4a17df
9e5c75f1-2ad3bd2f
f79cb77b-3d47f4f4
e5218ffe-ca7d8d80
4ea303a6-ecbb250e
bcc34a89-3f4a17df
4da5ae82-6edc92c7
2c1d398c-3f4a17df
6973a1cf-3f4a17df
58a025e3-36e97b2c
2a32876a-ca7d8d80
ff29b1bd-37ef7e17
da460ac8-3f4a17df
4bc337ce-69465896
9a2f4e5b-ca7d8d80
1354da85-f1a864dc
17507c76-ca7d8d80
494d8760-52325d43
3ac60855-486e2a9c
f296190c-477de798
4442aae2-e1cc0f14
ed1d377-e1cc0f14
12e17bc5-e1cc0f14
75f0f0a0-6bdfffe7
e2b18481-a90023b1
e7e71889-4ad60575
3a8271ac-12c226
b1ceb06f-d1372334
3a4029d-ca7d8d80
41aa6aaa-da82a76f
94e68624-803f8fc4
8834fcca-ca7d8d80
</pre>
</details>
### Output of checks
This bug happens on GitLab.com)
### Possible fixes
- When rendering `<img>` elements, put the `alt` attribute text also in the `title` attribute.
- Change the documentation to match the current behavior (but I'd much rather see the first option!)https://gitlab.com/gitlab-org/gitlab/-/issues/24143Support CockroachDB as a backing store2023-12-11T15:42:08ZJoe RocklinSupport CockroachDB as a backing store### Problem to solve
Reduce the operational burden on teams desiring to deploy a highly available version of Gitlab on-prem or in a cloud/kubernetes environment.
### Further details
Regardless of the scale of an installation, no one w...### Problem to solve
Reduce the operational burden on teams desiring to deploy a highly available version of Gitlab on-prem or in a cloud/kubernetes environment.
### Further details
Regardless of the scale of an installation, no one wants their service to be down. PostgreSQL has been around a long time and is a fine database, but it was designed in a time before the modern concept of highly-available distributed systems. As a result, it is not trivial to run or maintain a PostgreSQL replica let alone scale and shard the data.
CockroachDB[^1] is a modern RDBMS which implements a PostgreSQL compatible wire protocol[^2] and is designed to make some of the modern scaling problems easier to manage. While the wire protocol is consistent, the SQL Dialect is not identical. CoackroachDB documents their SQL support[^5] and has shown a willingness to implement additional features as need arises[^6].
### Proposal
Gitlab should support using CockroachDB in addition to PostgreSQL.
### What does success look like, and how can we measure that?
Success can be measured in a number of ways, though many are only tangible to operators of Gitlab.
1. High-Availability of the database layer
1. Scaling the DB layer in an active-active capacity at a single site becomes feasible.
1. Kubernetes-based deployments can leverage StatefulSets to run the database in a manner supported by the database vendor[^3]. charts/gitlab#48
1. Simplified geographic replication - CockroachDB supports live replication across a WAN connection. When the database natively supports replication there is less burden on the development teams to handle replication checks and on operators to maintain the replication processes.
There may be measurable performance differences, but the diverse types of queries used in Gitlab makes it difficult to surmise what performance would look like on CockroachDB vs. PostgreSQL.
Possible new features:
1. Enable Geographic data constraints - Commercial versions of CockroachDB allows data to remain in specific geographic locales[^4].
### Links / references
[^1]: CockroachDB: https://www.cockroachlabs.com/product/cockroachdb/
[^2]: CockroachDB SQL Layer - https://www.cockroachlabs.com/docs/stable/architecture/sql-layer.html#postgresql-wire-protocol
[^3]: CockroachDB and Kubernetes - https://www.cockroachlabs.com/campaigns/kubernetes/
[^4]: Global Clusters - https://www.cockroachlabs.com/solutions/global-clusters/
[^5]: Cocroach SQL Feature Support - https://www.cockroachlabs.com/docs/stable/sql-feature-support.html
[^6]: Cockroach PostgreSQL compatibility - https://www.cockroachlabs.com/blog/why-postgres/BacklogAlex Ivesaives@gitlab.comAlex Ivesaives@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/24141Show error message when Redis/Postgres is down2020-09-07T01:14:57ZYuanchen LuShow error message when Redis/Postgres is downIn the case when Redis or Postgres connection is down, GitLab would show a 500 error, which is expected. However, given that other conditions might cause such error, is there any way we can view the exact error message other than viewing...In the case when Redis or Postgres connection is down, GitLab would show a 500 error, which is expected. However, given that other conditions might cause such error, is there any way we can view the exact error message other than viewing the log? The health check endpoint `/-/readiness` or `/-/liveness` would also be down since the entire server is down.
Side question: can GitLab still start if Redis/Postgres is down? I noticed `current_setting` would "fake" an application setting in case of a failover, but still the endpoints can't be reached.https://gitlab.com/gitlab-org/gitlab/-/issues/24135Summary content of issues provided by RSS feeds doesn't include correct image...2019-11-05T18:36:58ZMarc SchwedeSummary content of issues provided by RSS feeds doesn't include correct images url### Summary
While including images to issues to provide more information about certain issues, those images will get lazy loaded by the frontend. While creating the html code for the summary for issues in RSS feeds, exactly the same mec...### Summary
While including images to issues to provide more information about certain issues, those images will get lazy loaded by the frontend. While creating the html code for the summary for issues in RSS feeds, exactly the same mechanism is used. But usually RSS reader don't use same mechanisms like lazy-loading etc. for example for loading of images. This is, why images inside issue comments will not be loaded inside RSS readers.
### Steps to reproduce
1. Create an issue with one or more images inside of it.
2. Open the personal activities RSS feed inside a reader or use `curl` to display the content
3. Check for the item with the content of the newly created issue
### What is the current *bug* behavior?
Mechanisms that apply to browsers are applied to RSS feed creation. But this doesn't work resulting in RSS Readers not displaying the correct content for issues.
Where the Images should be displayed, currently empty/white gif placeholders will be shown.
### What is the expected *correct* behavior?
Use the correct url for images and not lazy loading mechanisms for RSS feeds
### Relevant logs and/or screenshots
```html
`<a class="no-attachment-icon" href="URI_TO_IMAGE" target="_blank" rel="noopener noreferrer"><img src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" alt="image1" class="lazy" data-src="URI_TO_IMAGE" /></a>`
```
| RSS reader | browser |
|---|---|
|![Bildschirmfoto_2018-09-12_um_11.33.01](/uploads/f0c660f96e331135aa28fd0822f39e5d/Bildschirmfoto_2018-09-12_um_11.33.01.png)|![Bildschirmfoto_2018-09-12_um_11.35.07](/uploads/17b1c2f273f21a0add9a50d758338358/Bildschirmfoto_2018-09-12_um_11.35.07.png)|
### Output of checks
This bug happens on GitLab.com
and on GitLab CE 11.2.3 gitlab-ce@06cbee3bf9dd960380390c0a5df9b67a52a85ba9
### Possible fixes
remove the creation of the following snippet
Inside [_event_issue.atom.haml](app/views/events/_event_issue.atom.haml) the `markdown` function provides the code, which should directly include the URI_TO_IMAGE inside the `<img src=""` tag and not inside the `data_src` one.https://gitlab.com/gitlab-org/gitlab/-/issues/24134Issue Boards: Can't drag issues using IE112022-05-19T16:22:48ZCollenIssue Boards: Can't drag issues using IE11Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/103524 (internal-only link)
### Summary
IE 11.2430.14393.0 (which is pretty current) does not allow us to drag issues on the issues board.
Reported on an instance running GitLab...Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/103524 (internal-only link)
### Summary
IE 11.2430.14393.0 (which is pretty current) does not allow us to drag issues on the issues board.
Reported on an instance running GitLab 11.2.3-ee.
### Steps to reproduce
I've not reproduced this as I do not have a Windows VM. Downloading one now and if all goes well I'll try and reproduce and report back. I've asked the customer for some additional info via the ticket too.
**Update:** After several attempts I've given up on getting a Windows VM to run in VirtualBox. I did use Browserstack to test this on Edge. I was unable to drag issues between boards but got no errors or anything helpful from the dev tools console. See GIF below:
![drag_issue_ms_edge](/uploads/bf55835b4dd69d3033431e19e540610d/drag_issue_ms_edge.gif)
### What is the current *bug* behaviour?
Can't drag issues on issue board.
### What is the expected *correct* behaviour?
Should be able to drag issues on issue board.
### Relevant logs and/or screenshots
TBDBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/24133Host network is not allowed to be used spec.containers[0].securityContext.hos...2019-11-05T18:36:58Zsheldon yangHost network is not allowed to be used spec.containers[0].securityContext.hostNetworkI ran into a problem.
When I deployed the ingress-controller deployment on my kubernetes, the pod was created with hostNetwork=true enabled to listen on port 80 of the host. But can't create, prompt error:
message: 'pods "nginx-ingr...I ran into a problem.
When I deployed the ingress-controller deployment on my kubernetes, the pod was created with hostNetwork=true enabled to listen on port 80 of the host. But can't create, prompt error:
message: 'pods "nginx-ingress-controller-7885cc9b4b-" is forbidden: unable to
validate against any pod security policy: [spec.securityContext.hostNetwork:
Invalid value: true: Host network is not allowed to be used spec.containers[0].securityContext.hostNetwork:
Invalid value: true: Host network is not allowed to be used spec.containers[0].securityContext.containers[0].hostPort:
Invalid value: 80: Host port 80 is not allowed to be used. Allowed ports: []
spec.containers[0].securityContext.containers[0].hostPort: Invalid value: 443:
Host port 443 is not allowed to be used. Allowed ports: []]'
![image](/uploads/9bdb44f1f95f19a03d749e195ef167a0/image.png)https://gitlab.com/gitlab-org/gitlab/-/issues/24130Unable to edit issues on the boards screen in Chrome2020-07-31T20:10:41ZDavidUnable to edit issues on the boards screen in Chrome### Summary
When I click on an item in a GitLab board using Google Chrome, the right-hand quick edit panel does not appear. Some of my colleagues are still able to access the boards' quick edit functionality, so it doesn't seem to be an...### Summary
When I click on an item in a GitLab board using Google Chrome, the right-hand quick edit panel does not appear. Some of my colleagues are still able to access the boards' quick edit functionality, so it doesn't seem to be an issue affecting all users. The problem does not appear for MS Edge or Mozilla Firefox.
### Steps to reproduce
I can reproduce this easily:
1. Using Chrome, log into gitlab.com
2. Go to any project or group
3. Click on Issues -> Boards
4. Click any of the issues on the boards (not the headline but the body of the tile) => Nothing happens
But - as mentioned - this does not happen for all of my colleagues. My System:
* Windows 10 version 1803
* Chrome 68.0.3440.106
I tried clearing cookies & local storage for GitLab.com, which did not help.
The quick-edit panel **does** appear after creating a new issue on the boards screen (but it seems to be a bit broken too: I can't assign issue weights until I reload the page)
### Example Project
https://gitlab.com/Bauske/bug-showcase/boards
### What is the current *bug* behavior?
In Chrome, the right-hand quick-edit panel does not open. In Edge and Firefox, the panel appears as expected.
### What is the expected *correct* behavior?
The right-hand quick-edit panel also appears on Chrome, allowing me to change issue properties without accessing the issue's page.
### Relevant logs and/or screenshots
There are no error messages in the browser's console.
### Output of checks
This bug happens on GitLab.com
### Possible fixes
I do not know.https://gitlab.com/gitlab-org/gitlab/-/issues/24129Public opengraph metadata2019-11-05T18:36:59ZEloy Espinacoeloyesp@gmail.comPublic opengraph metadata### Problem to solve
When adding links to private project pages on slack or other media, metadata is missing (because the project is private). I would like to have an option to make metadata public, so people interested in the project c...### Problem to solve
When adding links to private project pages on slack or other media, metadata is missing (because the project is private). I would like to have an option to make metadata public, so people interested in the project can see info about what is being worked on, without the need to make all the project public.
### Further details
Currently we use a trello board to manage a project, I would like to switch to gitlab issues to add more visibility and integration, but those kind of annoyances make it difficult to move the team.
### Proposal
Adding an option about the visibility level for metadata, making it possible to have rich links to issues and merge requests. An external user cannot see what is being done in a merge request, but they can have metadata about it, when we started working on this, the description and image (if it has).
### What does success look like, and how can we measure that?
Add a link to a private merge request on slack and see something more interesting that please log in. There will be a lots of metadata only requests.
### Links / references
I'm making part of the project public with https://gitlab.com/gitlab-org/gitlab-ce/issues/19734 but I needed better links.https://gitlab.com/gitlab-org/gitlab/-/issues/24128gitlab-ce docker container:Unable to execute command via ' docker exec gitlab...2019-11-05T18:36:59Zkychengitlab-ce docker container:Unable to execute command via ' docker exec gitlab-container ls '.### Summary
The container cannot be manipulated by "Docker exec" after the Gitlab Docker container has been running for about 1 months. Other containers on the server can be executed normally. The Gitlab works correctly, but it cannot b...### Summary
The container cannot be manipulated by "Docker exec" after the Gitlab Docker container has been running for about 1 months. Other containers on the server can be executed normally. The Gitlab works correctly, but it cannot be modified.
### Steps to reproduce
No attempt to reproduce.
### What is the current *bug* behavior?
Gitlab containers cannot be maintained by "Docker exec".
### What is the expected *correct* behavior?
The Gitlab container can be maintained normally using "Docker exec".
### Relevant logs and/or screenshots
Just docker log:
[docker.log](/uploads/a40e6e8419ddf2d7b535f74d406128e1/docker.log)
#### Results of GitLab environment info
docker info:
```yaml
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 29
Server Version: 17.12.0-ce
Storage Driver: aufs
Root Dir: /opt/lib/docker/aufs
Backing Filesystem: xfs
Dirs: 214
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-62-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.796GiB
Name: git.cqrd.com
ID: SC55:OWCD:2AR5:ZQUA:IZ3L:U6HT:MRBW:WOYE:HGOQ:JSZE:OGCX:CK5S
Docker Root Dir: /opt/lib/docker
Debug Mode (client): false
Debug Mode (server): false
HTTP Proxy: http://172.17.18.80:8080
HTTPS Proxy: http://172.17.18.80:8080
No Proxy: .x,hub.com,h.com,.cae.com
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
h.com
hub.com
hub.x
127.0.0.0/8
Registry Mirrors:
https://mirror.cae.com/
Live Restore Enabled: true
WARNING: No swap limit support
```
docker version:
```yaml
Client:
Version: 17.12.0-ce
API version: 1.35
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:11:19 2017
OS/Arch: linux/amd64
Server:
Engine:
Version: 17.12.0-ce
API version: 1.35 (minimum version 1.12)
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:09:53 2017
OS/Arch: linux/amd64
Experimental: false
```
docker service status:
```yaml
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/docker.service.d
└─proxy.conf
Active: active (running) since Fri 2018-07-06 18:26:42 CST; 2 months 6 days ago
Docs: https://docs.docker.com
Main PID: 1207 (dockerd)
Tasks: 63
Memory: 666.4M
CPU: 12h 42min 45.760s
CGroup: /system.slice/docker.service
├─1207 /usr/bin/dockerd -H fd://
├─1319 docker-containerd --config /var/run/docker/containerd/containerd.toml
├─2720 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 443 -container-ip 172.172.172.2 -container-port 443
├─2744 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 80 -container-ip 172.172.172.2 -container-port 80
├─2762 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 22 -container-ip 172.172.172.2 -container-port 22
└─2772 docker-containerd-shim -namespace moby -workdir /opt/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/52b11c202caebc
```
server info
```yaml
Linux git.cqrd.com 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
```
gitlab version:`GitLab Community Edition 11.0.0`
gitlab container status:
```yaml
52b11c202cae gitlab/gitlab-ce:11.0.0-ce.0 "/assets/wrapper" 7 weeks ago Up 7 weeks (healthy) 0.0.0.0:22->22/tcp, 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp gitlab
```https://gitlab.com/gitlab-org/gitlab/-/issues/24127UX: Menubar Height2019-11-05T18:37:00ZNazar Maksymchuknzrbeats@gmail.comUX: Menubar HeightThe menu bar is smaller(short in height), it would be a better UX if it would be more taller.The menu bar is smaller(short in height), it would be a better UX if it would be more taller.https://gitlab.com/gitlab-org/gitlab/-/issues/24126Install-helm times out on bare-metal k8s install2019-11-05T18:37:00ZEmmett HitzInstall-helm times out on bare-metal k8s installHi!
While attempting to install tiller on my kubernetes bare-metal cluster, I get the rather nebulous error:
![Screenshot_2018-09-11_19.48.59_FEndUo](/uploads/e2b98d7eb6de591b58d454b8ec481de8/Screenshot_2018-09-11_19.48.59_FEndUo.png...Hi!
While attempting to install tiller on my kubernetes bare-metal cluster, I get the rather nebulous error:
![Screenshot_2018-09-11_19.48.59_FEndUo](/uploads/e2b98d7eb6de591b58d454b8ec481de8/Screenshot_2018-09-11_19.48.59_FEndUo.png)
`192.168.1.172` is the LAN IP of one of the workers in the cluster. The nodes are all capable of talking to one another. I know this isn't a firewall problem.
After doing a little digging, the `install-helm` pod terminates with an error shortly after spinning up. I tried to grab the errors with `kubectl logs install-helm -n gitlab-managed-apps --follow=true --all-containers` with no success, since the pod dies too quickly.
Any help would be much appreciated. Thanks!!https://gitlab.com/gitlab-org/gitlab/-/issues/24124Beta features configuration panel2019-11-05T18:37:01ZDaniel GruessoBeta features configuration panel### Problem to solve
Currently, whenever GitLab ships a feature behind a feature flag, users must go through some hurdles in order to enable them.
### Further details
When users wish to enable a feature flag, they have to:
* execute a...### Problem to solve
Currently, whenever GitLab ships a feature behind a feature flag, users must go through some hurdles in order to enable them.
### Further details
When users wish to enable a feature flag, they have to:
* execute a command in the console
* know the name of the feature flag in order to enable
This is problematic for the following reasons:
* users are not likely to know the name of the feature flag
* feature flag names are not always documented
* users may not have access to the console in order to execute the command
### Proposal
Provide a control panel where "experimental" features (those behind a feature flag) can be enabled or disabled, easily, from the GitLab GUI.
### What does success look like, and how can we measure that?
(If no way to measure success, link to an issue that will implement a way to measure this)
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/24117server error 500 when trying to open Help page2023-02-06T03:04:02ZEugene M. Zheganinserver error 500 when trying to open Help pageEach time I'm trying to open the help page in the Gitlab CE 11.2.3 I got server error.
production log:
Started GET "/help" for 127.0.0.1 at 2018-09-11 16:27:15 +0500
Processing by HelpController#index as HTML
Started POST "...Each time I'm trying to open the help page in the Gitlab CE 11.2.3 I got server error.
production log:
Started GET "/help" for 127.0.0.1 at 2018-09-11 16:27:15 +0500
Processing by HelpController#index as HTML
Started POST "/api/v4/jobs/request" for 127.0.0.1 at 2018-09-11 16:27:15 +0500
Completed 500 Internal Server Error in 153ms (ActiveRecord: 1.8ms)
ActionView::Template::Error (undefined method `add_class' for #<Nokogiri::XML::Element:0x0000000835810f00>):
31: .row.prepend-top-default
32: .col-md-8
33: .documentation-index.wiki
34: = markdown(@help_index)
35: .col-md-4
36: .card
37: .card-header
lib/banzai/filter/image_lazy_load_filter.rb:10:in `block in call'
lib/banzai/filter/image_lazy_load_filter.rb:9:in `call'
lib/banzai/pipeline/base_pipeline.rb:21:in `block (2 levels) in singleton class'
lib/banzai/renderer.rb:108:in `render_result'
lib/banzai/renderer.rb:139:in `block in cacheless_render'
lib/gitlab/metrics/influx_db.rb:98:in `measure'
lib/banzai/renderer.rb:138:in `cacheless_render'
lib/banzai/renderer.rb:28:in `render'
lib/banzai.rb:3:in `render'
app/helpers/markup_helper.rb:246:in `markdown_unsafe'
app/helpers/markup_helper.rb:91:in `markdown'
app/views/help/index.html.haml:34:in `_app_views_help_index_html_haml__3710500830282665884_17630413960'
lib/gitlab/i18n.rb:51:in `with_locale'
lib/gitlab/i18n.rb:57:in `with_user_locale'
app/controllers/application_controller.rb:401:in `set_locale'
lib/gitlab/middleware/multipart.rb:97:in `call'
lib/gitlab/request_profiler/middleware.rb:14:in `call'
lib/gitlab/middleware/go.rb:17:in `call'
lib/gitlab/etag_caching/middleware.rb:11:in `call'
lib/gitlab/middleware/read_only/controller.rb:38:in `call'
lib/gitlab/middleware/read_only.rb:16:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:18:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
lib/gitlab/middleware/release_env.rb:10:in `call'
#### Results of GitLab environment info
<details>
<summary>Expand for output related to GitLab environment info</summary>
<pre>
$ bundle exec rake gitlab:env:info RAILS_ENV=production
System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.4.4p296
Gem Version: 2.7.7
Bundler Version:1.16.4
Rake Version: 12.3.1
Redis Version: 4.0.11
Git Version: 2.18.0
Sidekiq Version:5.2.1
Go Version: go1.11 freebsd/amd64
GitLab information
Version: 11.2.3
Revision: Unknown
Directory: /usr/local/www/gitlab-ce
DB Adapter: mysql2
URL: http://XXXXXXXXXXXXXXX.net
HTTP Clone URL: http://XXXXXXXXXXXXXXX.net/some-group/some-project.git
SSH Clone URL: git@XXXXXXXXXXXXXXX.net:some-group/some-project.git
Using LDAP: yes
Using Omniauth: no
GitLab Shell
Version: 8.1.1
Repository storage paths:
- default: /usr/home/git/repositories
Hooks: /usr/local/share/gitlab-shell/hooks
Git: /usr/local/bin/git
</pre>
</details>
#### Results of GitLab application Check
<details>
<summary>Expand for output related to the GitLab application check</summary>
<pre>
$ bundle exec rake gitlab:check RAILS_ENV=production
Checking GitLab Shell ...
GitLab Shell version >= 8.1.1 ? ... OK (8.1.1)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
[... repositories are ok with two empty ones, I'm afraid I cannot disclose this info 'cause I'm under NDA ...]
Running /usr/local/share/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /usr/home/git/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Reply by email is disabled in config/gitlab.yml
Checking LDAP ...
Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: cn=ХХХ,ou=users,dc=XXXX,dc=XXXX uid: XXX
[... same story with LDAP usernames and CNs ...]
Checking LDAP ... Finished
Checking GitLab ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... no
Try fixing it:
Install the init script
For more information see:
doc/install/installation.md in section "Install Init Script"
Please fix the error above and rerun the checks.
Init script up-to-date? ... can't check because of previous errors
Projects have namespace: ...
[... namespaces check also went okay ...]
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.4)
Git version >= 2.9.5 ? ... yes (2.18.0)
Git user has default SSH configuration? ... no
Try fixing it:
mkdir ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/dev_id_dsa ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/id_dsa ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/authorized_keys\~ ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/id_dsa.pub ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/svn_id_dsa ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/known_hosts.old ~/gitlab-check-backup-1536660944
For more information see:
doc/ssh/README.md in section "SSH on the GitLab server"
Please fix the error above and rerun the checks.
Active users: ... 160
Checking GitLab ... Finished
</pre>
</details>https://gitlab.com/gitlab-org/gitlab/-/issues/24115Jenkins integration - port 22: Operation timed out2019-11-05T18:37:03ZMichal WietechaJenkins integration - port 22: Operation timed outI was trying to create integration between Jenkins and GitLab using this tutorial: https://docs.bitnami.com/aws/how-to/create-ci-pipeline/
(without Step 3: Connect Your Project With The GitLab Repository)
So I have generated public and ...I was trying to create integration between Jenkins and GitLab using this tutorial: https://docs.bitnami.com/aws/how-to/create-ci-pipeline/
(without Step 3: Connect Your Project With The GitLab Repository)
So I have generated public and private keys, public was added in GitLab (Settings > SSH Keys) and private key file content was inserted into text area in Jenkins Project settings (Source Code Management > Credentials > SSH Username with private key > Private key) ![Screenshot_1](/uploads/ef8386fdd17fa45cdec36d7132b8a92a/Screenshot_1.png)
After that following error appeared:
![Screenshot_2](/uploads/c1794240497148ce818514365c5bae80/Screenshot_2.png)
what can cause such strange issue? Thanks for help :)https://gitlab.com/gitlab-org/gitlab/-/issues/24114HTTP git functionality unavailable after the upgrade2022-09-07T09:32:52ZEugene M. ZheganinHTTP git functionality unavailable after the upgradeAfter upgrade from 10.x to 11.2.3 my users cannot clone via HTTP. SSH transport works just fine. When using HTTP git client says
[emz@anthe ~]$ git clone http://server.name/namespace/repo.git test
Cloning into 'test'...
Use...After upgrade from 10.x to 11.2.3 my users cannot clone via HTTP. SSH transport works just fine. When using HTTP git client says
[emz@anthe ~]$ git clone http://server.name/namespace/repo.git test
Cloning into 'test'...
Username for 'http://server.name': user
Password for 'http://user@server.name':
fatal: repository 'http://server.name/namespace/repo.git/' not found
The most discouraging thing is that none of the logs mention any errors. The links like https://server.name/namespace/repo.git/info/refs?service=git-upload-pack or https://server.name/namespace/repo.git/info/refs?service=git-upload-pack clearly don't work, they show "Not Found" message and 404 status, but the production log think they were rendered without error:
Started GET "/namespace/repo.git/info/refs?service=git-upload-pack" for 168.63.101.55 at 2018-09-10 21:51:27 +0500
Processing by Projects::GitHttpController#info_refs as HTML
Parameters: {"service"=>"git-upload-pack", "namespace_id"=>"namespace", "project_id"=>"repo.git"}
Completed 200 OK in 458ms (Views: 0.5ms | ActiveRecord: 14.3ms)
Completed 200 OK in 357ms (Views: 1.3ms | ActiveRecord: 37.9ms)
I have checked all the paths - gitlab-shell, gitaly, repositories path and they seem to be okay. I've checked that /home prefix in the configuration files is changed to /usr/home because I'm running gitlab on FreeBSD (and /home is a symlink). So at this point I'm pretty much stuck. This installation used to work while running 10.2.x, so this clearly has something to do with the upgrade (which, to my opinion, went without errors).
Could someone point me at the right direction, because at this time I have read tonnes of similar reports, but the solutions mentioned don't work for me. It would be much easier if there were at least some errors in the logs, but unfortunately there's none.
#### Results of GitLab environment info
<details>
<summary>Expand for output related to GitLab environment info</summary>
<pre>
$ bundle exec rake gitlab:env:info RAILS_ENV=production
System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.4.4p296
Gem Version: 2.7.7
Bundler Version:1.16.4
Rake Version: 12.3.1
Redis Version: 4.0.11
Git Version: 2.18.0
Sidekiq Version:5.2.1
Go Version: go1.11 freebsd/amd64
GitLab information
Version: 11.2.3
Revision: Unknown
Directory: /usr/local/www/gitlab-ce
DB Adapter: mysql2
URL: http://XXXXXXXXXXXXXXX.net
HTTP Clone URL: http://XXXXXXXXXXXXXXX.net/some-group/some-project.git
SSH Clone URL: git@XXXXXXXXXXXXXXX.net:some-group/some-project.git
Using LDAP: yes
Using Omniauth: no
GitLab Shell
Version: 8.1.1
Repository storage paths:
- default: /usr/home/git/repositories
Hooks: /usr/local/share/gitlab-shell/hooks
Git: /usr/local/bin/git
</details>
#### Results of GitLab application Check
<details>
<summary>Expand for output related to the GitLab application check</summary>
<pre>
$ bundle exec rake gitlab:check RAILS_ENV=production
Checking GitLab Shell ...
GitLab Shell version >= 8.1.1 ? ... OK (8.1.1)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
[... repositories are ok with two empty ones, I'm afraid I cannot disclose this info 'cause I'm under NDA ...]
Running /usr/local/share/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /usr/home/git/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Reply by email is disabled in config/gitlab.yml
Checking LDAP ...
Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: cn=ХХХ,ou=users,dc=XXXX,dc=XXXX uid: XXX
[... same story with LDAP usernames and CNs ...]
Checking LDAP ... Finished
Checking GitLab ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... no
Try fixing it:
Install the init script
For more information see:
doc/install/installation.md in section "Install Init Script"
Please fix the error above and rerun the checks.
Init script up-to-date? ... can't check because of previous errors
Projects have namespace: ...
[... namespaces check also went okay ...]
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.4)
Git version >= 2.9.5 ? ... yes (2.18.0)
Git user has default SSH configuration? ... no
Try fixing it:
mkdir ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/dev_id_dsa ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/id_dsa ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/authorized_keys\~ ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/id_dsa.pub ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/svn_id_dsa ~/gitlab-check-backup-1536660944
sudo mv /usr/local/git/.ssh/known_hosts.old ~/gitlab-check-backup-1536660944
For more information see:
doc/ssh/README.md in section "SSH on the GitLab server"
Please fix the error above and rerun the checks.
Active users: ... 160
Checking GitLab ... Finished
</details>
<br/>
I understand that gitlab thinks something is wrong with ~/.ssh directory of the git user itself, but I have the strong impression that the proposed measures will wipe out clean the SSH keys structures and all the users will lose their installed keys. So I decided not to fix this. Furthermore, SSH remains now the only functioning transport, so looks like this is a false positive(?).https://gitlab.com/gitlab-org/gitlab/-/issues/24104`User#authorized_groups` does not return every group the user is authorized t...2023-12-01T13:11:24ZTiago Botelho`User#authorized_groups` does not return every group the user is authorized to seeIf we take a closer look at how [`User#authorized_groups`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/models/user.rb#L645) is implemented we can see that it only returns groups where the user has direct access, or one of the...If we take a closer look at how [`User#authorized_groups`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/models/user.rb#L645) is implemented we can see that it only returns groups where the user has direct access, or one of the user projects belongs to a certain group.
The behavior should instead be:
* `User#authorized_groups` returns *all expanded* groups
* For a sub-group, it will return its parent/s and child groups
This can be done by changing the implementation to make use of the [`Gitlab::GroupHierarchy#all_groups`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/group_hierarchy.rb#L78) method which expands all groups the user has access to. This method is already being used by [`GroupsFinder`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/finders/groups_finder.rb#L47).
We could change the `User#authorized_groups` implementation to something like the following:
```ruby
def authorized_groups
union = Gitlab::SQL::Union
.new([groups.select(:id), authorized_projects.select(:namespace_id)])
groups_for_ancestors = Group.where("namespaces.id IN (#{union.to_sql})")
groups_for_descendants = groups
Gitlab::GroupHierarchy.new(groups_for_ancestors, groups_for_descendants).all_groups
end
```
There is one caveat though, this approach is *extremely inefficient* ([EXPLAIN_authorized_groups__1_.txt](/uploads/198b356bee874c378c9967ec28f04080/EXPLAIN_authorized_groups__1_.txt))
Based on a previous discussion with @DouweM and @yorickpeterse, we previously had a similar problem with the authorized projects, which we solved by making an intermediate table that holds the `authorized_projects` for a user, maybe we could do something like this for the groups as well?Next 1-3 releasesAlex PooleyAlex Pooleyhttps://gitlab.com/gitlab-org/gitlab/-/issues/24103Web IDE doesn't refresh pipelines2019-11-05T18:37:03ZJames Kingjames@momentum.studioWeb IDE doesn't refresh pipelines<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug
For the Enterprise Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
Pipelines don't update in sidebar of Web IDE
### Steps to reproduce
* Open Web IDE
* Create a new commit
* Open the pipelines sidebar, to see the pipeline starting
* Open the log of a pipeline task
### Example Project
*If you're struggling to reproduce, I will make a project later.*
### What is the current *bug* behavior?
The pipeline log doesn't update, it only shows the log up to the point of opening and won't scroll any more output at all.
### What is the expected *correct* behavior?
To update the same as if you're viewing the pipeline task outside of the Web IDE.
### Relevant logs and/or screenshots
N/A
### Output of checks
This bug happens on GitLab.com
#### Results of GitLab environment info
GitLab.com
#### Results of GitLab application Check
GitLab.com
### Possible fixes
*Not sure*https://gitlab.com/gitlab-org/gitlab/-/issues/24102Let the ability to delete wiki entries be managed on a project-by-project basis2019-11-05T18:37:04ZSascha MaiselLet the ability to delete wiki entries be managed on a project-by-project basis### Problem to solve
Normal user (Developer status) cannot delete wiki pages. He can create/edit, but not delete an existing one.
### Further details
Use Case: A student or junior dev is tasked with cleaning up our Wiki and I really don...### Problem to solve
Normal user (Developer status) cannot delete wiki pages. He can create/edit, but not delete an existing one.
### Further details
Use Case: A student or junior dev is tasked with cleaning up our Wiki and I really don't want to grant him maintainer or administrative access.
### Proposal
Allow admin to grant a certain user group (guest/reporter/dev) the ability to delete wiki entries from the General Settings -> Permissions tab. Failing that, allow admin to grant a single user this privilege through whichever means is most easy to implement for you guys?
### What does success look like, and how can we measure that?
Uh, I guess success = my guy can clean up our wiki?
Kidding aside, I don't care if it requires some command line hack or if I can do it easily from the admin panel of the graphical interface. Just let me allow people to delete wiki pages in some way :)
### Links / references