forked from termux/termux-app
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathjitpack.yml
1403 lines (1162 loc) · 67.2 KB
/
jitpack.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
<title>GitLab issues</title>
<link href="/gitlab-org/gitlab/-/issues.atom?feed_token=glft-7e909eeab7fe318fca0ef070e2a4825d83a12cc269bc8493d4a18a8d34485cdb-20940659&label_name=feature%3A%3Aaddition&state=opened" rel="self" type="application/atom+xml"/>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues" rel="alternate" type="text/html"/>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues</id>
<updated>2024-08-21T07:07:27Z</updated>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480135</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480135"/>
<title>Switch from remote_development_agent_configs table to workspaces_agent_configs</title>
<updated>2024-08-21T07:07:27Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/1f037f9cf1dc4e8f713828abd5f86314896c956e2bc1c81b8b0eb2f60ce87ad4?s=80&d=identicon"/>
<author>
<name>Chad Woolley</name>
<email>[email protected]</email>
</author>
<summary>Switch from remote_development_agent_configs table to workspaces_agent_configs</summary>
<description>MR: Pending
## Description
Switch from `remote_development_agent_configs` table to `workspaces_agent_configs`. We need to rename this to reflect the rename of the category from `Remote Development` to `Workspaces`. See Technical Requir...</description>
<content>MR: Pending
## Description
Switch from `remote_development_agent_configs` table to `workspaces_agent_configs`. We need to rename this to reflect the rename of the category from `Remote Development` to `Workspaces`. See Technical Requirements section below for details.
- See https://gitlab.com/groups/gitlab-org/-/epics/14186+ for overview and more context
- See [Related Issues and MRs section in that epic](https://gitlab.com/groups/gitlab-org/-/epics/14186#related-issues-and-mrs) for related issues and MRs
## Acceptance Criteria
- [ ] Table is renamed
- [ ] TODO: Follow-up issue created for deletion of old table in next release
## Technical Requirements
This is an alternate approach to a table rename than that described in https://docs.gitlab.com/ee/development/database/rename_database_tables.html. This is because we want to avoid the need to wait for the next release, but still ensure we accommodate zero-downtime deploys and schema cache concerns. Normally this might be difficult, but it should be possible and safe in our case because of some unique characteristics of this table.
Here is the general plan, for a single MR:
1. Make a first migration for the DDL to create the `workspaces_agent_configs` table.
- It should have an identical schema to the existing `remote_development_agent_configs` table, except that all the fields will be nullable (to save us the work of doing that separately in https://gitlab.com/gitlab-org/gitlab/-/issues/479699+).
2. Make a second migration for the DML to copy all records from the existing `remote_development_agent_configs` to the new `workspaces_agent_configs` table.
3. Make the changes to rename the `RemoteDevelopmentAgentConfig` model and all associated code to `WorkspacesAgentConfig`, so it points to the new table.
## Considerations for zero-downtime deploys
Regarding multi-version / zero-downtime deployments: The old version and the new version of the application will run at the same time in a zero-downtime deployment scenario. Normally, this is a concern and requires triggers for bidirectional syncing. However, that should not be required in this case:
1. The update frequency of these tables is so infrequent, that I think it’s acceptable that we expect no new records will be written during the period of the zero-downtime deploy
2. The nature of this table is that it’s essentially just a mirror of the Gitlab Agent for Kubernetes agent config YAML which lives in git, and we are hooking into that and denormalizing it into this table. So even if we did happen to miss an update, all changes will get picked up and written to the new table on the next update of the config file. And this process is already error prone (i.e. it will fail if any of the YAML updates are valid - that’s why we’re migrating to this table instead of the YAML file for config). Worst case, we just tell users to make any dummy edit/commit to the config file, and it will ensure that all changes are reflected in the table.
## Justification
After looking at the issues getting refined for https://gitlab.com/groups/gitlab-org/-/epics/14872+ and elsewhere, we decided that we should not defer this rename.
Because we are going to continue to be adding many references in the code and also database foreign keys to the `remote_development_agent_config` table, which is just more code cleanup to do in the future.
It also means unnecessary migrations and/or extra code to work around the incorrect name, which we wouldn't have to do otherwise, and also causing confusing discussions. See https://gitlab.com/gitlab-org/gitlab/-/issues/479688#note_2059496100 and https://gitlab.com/gitlab-org/gitlab/-/issues/479461#note_2059401288 for examples.
Thus, this is not a piece of technical debt that we should let drag out, because it will continue compounding.
## Design Requirements
N/A - no UI changes</content>
<milestone>Next 1-3 releases</milestone>
<labels>
<label>Category:Workspaces</label>
<label>analytics instrumentation</label>
<label>devops::create</label>
<label>feature::addition</label>
<label>group::remote development</label>
<label>refined</label>
<label>section::dev</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
<label>workspaces-workflow::unprioritized</label>
</labels>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480089</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480089"/>
<title>Duo Workflow Service infer docker socket from current context</title>
<updated>2024-08-20T23:42:35Z</updated>
<media:thumbnail width="40" height="40" url="https://gitlab.com/uploads/-/system/user/avatar/120073/avatar.png"/>
<author>
<name>Dylan Griffith</name>
<email>[email protected]</email>
</author>
<summary>Duo Workflow Service infer docker socket from current context</summary>
<description>## Problem
Right now we require users to configure the path to their `docker` socket in the VS Code extension when using Duo Workflow.
## Solution
It should be possible to infer the Docker socket the same way the `docker` command does...</description>
<content>## Problem
Right now we require users to configure the path to their `docker` socket in the VS Code extension when using Duo Workflow.
## Solution
It should be possible to infer the Docker socket the same way the `docker` command does.
You can see how this works by looking at these 2 files:
```json
$ cat ~/.docker/config.json | jq .
{
"auths": {},
"credsStore": "osxkeychain",
"currentContext": "rancher-desktop"
}
$ cat ~/.docker/contexts/meta/**/meta.json | jq .
{
"Name": "rancher-desktop",
"Metadata": {
"Description": "Rancher Desktop moby context"
},
"Endpoints": {
"docker": {
"Host": "unix:///Users/dylangriffith/.rd/docker.sock",
"SkipTLSVerify": false
}
}
}
$ ls -l ~/.docker/contexts/meta/**/meta.json
-rw-r--r-- 1 dylangriffith staff 184B 14 Aug 09:19 /Users/dylangriffith/.docker/contexts/meta/<some_hash>/meta.json
$ docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default Current DOCKER_HOST based configuration unix:///var/run/docker.sock
rancher-desktop * Rancher Desktop moby context unix:///Users/dylangriffith/.rd/docker.sock
```
Basically we would do the following:
1. Load all of `~/.docker/contexts/meta/**/meta.json` files into memory and index them by `Name`
2. Read the `currentContext` from `~/.docker/config.json`
3. Match this `currentContext` against the `Name` found in the contexts
4. Use the `Endpoints.docker.Host` from that</content>
<labels>
<label>Category:Duo Workflow</label>
<label>Duo Workflow::LSP</label>
<label>devops::ai-powered</label>
<label>feature::addition</label>
<label>group::ai framework</label>
<label>section::data-science</label>
<label>type::feature</label>
</labels>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480051</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480051"/>
<title>Add pipeline status email changes to audit events</title>
<updated>2024-08-20T18:32:50Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/9d132c6cacb6b4b0cb0cd5dbb7c205aaafb6a6c3c5a6b50c523ae18b38f0b3fe?s=80&d=identicon"/>
<author>
<name>Ben Prescott_</name>
<email></email>
</author>
<summary>Add pipeline status email changes to audit events</summary>
<description>&lt;!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--&gt;
### Proposal
Audit changes to Settings &gt; Integrations &gt; [Pipeline status emails](https://docs.gitlab.com/ee/user/project/...</description>
<content><!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
Audit changes to Settings > Integrations > [Pipeline status emails](https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_emails.html)
I don't see this covered already either searching, nor in https://gitlab.com/groups/gitlab-org/-/epics/474+
<!-- 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/
--></content>
<labels>
<label>Category:Audit Events</label>
<label>GitLab Premium</label>
<label>GitLab Ultimate</label>
<label>audit_events::settings_configuration</label>
<label>customer</label>
<label>devops::foundations</label>
<label>documentation</label>
<label>feature::addition</label>
<label>group::import and integrate</label>
<label>section::core platform</label>
<label>type::feature</label>
</labels>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480047</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480047"/>
<title>Receptive Agents GraphQL API</title>
<updated>2024-08-20T18:20:53Z</updated>
<media:thumbnail width="40" height="40" url="https://gitlab.com/uploads/-/system/user/avatar/12689435/avatar.png"/>
<author>
<name>Timo Furrer</name>
<email>[email protected]</email>
</author>
<summary>Receptive Agents GraphQL API</summary>
<description>Exactly what the title says - we need resolvers and mutations (create and delete) for Receptive Agents.
The services are already in place covered in other issues of https://gitlab.com/groups/gitlab-org/-/epics/12180+</description>
<content>Exactly what the title says - we need resolvers and mutations (create and delete) for Receptive Agents.
The services are already in place covered in other issues of https://gitlab.com/groups/gitlab-org/-/epics/12180+</content>
<milestone>17.4</milestone>
<labels>
<label>analytics instrumentation</label>
<label>backend</label>
<label>devops::deploy</label>
<label>feature::addition</label>
<label>group::environments</label>
<label>section::cd</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480045</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480045"/>
<title>[Frontend] Add link to secret detection configuration page</title>
<updated>2024-08-21T06:08:01Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Frontend] Add link to secret detection configuration page</summary>
<description>### Overview
This issue tracks the ~frontend changes to link the project security configuration page to the secret detection configuration page
### Design
&lt;details&gt;
&lt;summary&gt;Add setting icon with tooltip&lt;/summary&gt;
{width=805 height=235}
</details>
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/479344
### Implementation Plan
* [x] Add setting icon with `GlButton` to the security configuration page
* [x] Add tooltip to the icon
* [ ] Render the icon with the feature flag
* [ ] Link the button to the configuration page
* [ ] Add necessary specs</content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::in dev</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480041</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480041"/>
<title>[Feature Flag] Add feature flag for allowlist</title>
<updated>2024-08-21T01:02:35Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Feature Flag] Add feature flag for allowlist</summary>
<description>## Summary
This issue is to add a new feature flag to roll out the frontend changes
## Owners
- Most appropriate Slack channel to reach out to: `#&lt;slack-channel-of-dri-team&gt;`
- Best individual to reach out to: @&lt;gitlab-username-of-dri...</description>
<content>## Summary
This issue is to add a new feature flag to roll out the frontend changes
## Owners
- Most appropriate Slack channel to reach out to: `#<slack-channel-of-dri-team>`
- Best individual to reach out to: @<gitlab-username-of-dri>
## Expectations
### What are we expecting to happen?
<!-- Describe the expected outcome when rolling out this feature -->
### What can go wrong and how would we detect it?
<!-- Data loss, broken pages, stability/availability impact? -->
<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
## Rollout Steps
Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command.
### Rollout on non-production environments
- Verify the MR with the feature flag is merged to `master` and have been deployed to non-production environments with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
<!-- Delete Incremental roll out if it is not relevant to this deploy -->
- [ ] Deploy the feature flag at a percentage (recommended percentage: 50%) with `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors --dev --pre --staging --staging-ref`
- [ ] Monitor that the error rates did not increase (repeat with a different percentage as necessary).
<!-- End of block for deletes -->
- [ ] Enable the feature globally on non-production environments with `/chatops run feature set <feature-flag-name> true --dev --pre --staging --staging-ref`
- [ ] Verify that the feature works as expected.
The best environment to validate the feature in is [`staging-canary`](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#staging-canary)
as this is the first environment deployed to. Make sure you are [configured to use canary](https://next.gitlab.com/).
- [ ] If the feature flag causes end-to-end tests to fail, disable the feature flag on staging to avoid blocking [deployments](https://about.gitlab.com/handbook/engineering/deployments-and-releases/deployments/).
- See [`#qa-staging` Slack channel](https://gitlab.enterprise.slack.com/archives/CBS3YKMGD) and look for the following messages:
- test kicked off: `Feature flag <feature-flag-name> has been set to true on **gstg**`
- test result: `This pipeline was triggered due to toggling of <feature-flag-name> feature flag`
For assistance with end-to-end test failures, please reach out via the [`#test-platform` Slack channel](https://gitlab.slack.com/archives/C3JJET4Q6). Note that end-to-end test failures on `staging-ref` [don't block deployments](https://about.gitlab.com/handbook/engineering/infrastructure/environments/staging-ref/#how-to-use-staging-ref).
### Specific rollout on production
For visibility, all `/chatops` commands that target production should be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
and cross-posted (with the command results) to the responsible team's Slack channel.
- Ensure that the feature MRs have been deployed to both production and canary with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
- [ ] Depending on the [type of actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors) you are using, pick one of these options:
- For **project-actor**: `/chatops run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss,gitlab-com/www-gitlab-com <feature-flag-name> true`
- For **group-actor**: `/chatops run feature set --group=gitlab-org,gitlab-com <feature-flag-name> true`
- For **user-actor**: `/chatops run feature set --user=<gitlab-username-of-dri> <feature-flag-name> true`
- [ ] Verify that the feature works for the specific actors.
### Preparation before global rollout
- [ ] Set a milestone to this rollout issue to signal for enabling and removing the feature flag when it is stable.
- [ ] Check if the feature flag change needs to be accompanied with a
[change management issue](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process).
Cross link the issue here if it does.
- [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production.
If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the `@sre-oncall` Slack alias.
- [ ] Ensure that documentation exists for the feature, and the [version history text](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#add-version-history-text) has been updated.
- [ ] Leave a comment on [the feature issue](<feature-issue-link>) announcing estimated time when this feature flag will be enabled on GitLab.com.
- [ ] Ensure that any breaking changes have been announced following the [release post process](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes) to ensure GitLab customers are aware.
- [ ] Notify the [`#support_gitlab-com` Slack channel](https://gitlab.slack.com/archives/C4XFU81LG) and your team channel ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)).
- [ ] Ensure that the feature flag rollout plan is reviewed by another developer familiar with the domain.
### Global rollout on production
For visibility, all `/chatops` commands that target production should be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
and cross-posted (with the command results) to the responsible team's Slack channel (`#<slack-channel-of-dri-team>`).
- [ ] (Optional) [Incrementally roll out](https://docs.gitlab.com/ee/development/feature_flags/controls.html#process) the feature on production environment.
- Between every step wait for at least 15 minutes and monitor the appropriate graphs on https://dashboards.gitlab.net.
- Perform **actor-based** rollout: `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
- [ ] Enable the feature globally on production environment: `/chatops run feature set <feature-flag-name> true`
- [ ] Observe appropriate graphs on https://dashboards.gitlab.net and verify that services are not affected.
- [ ] Leave a comment on [the feature issue](<feature-issue-link>) announcing that the feature has been globally enabled.
- [ ] Wait for [at least one day for the verification term](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release).
### (Optional) Release the feature with the feature flag
**WARNING:** This approach has the downside that it makes it difficult for us to
[clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) the flag.
For example, on-premise users could disable the feature on their GitLab instance. But when you
remove the flag at some point, they suddenly see the feature as enabled and they can't roll it back
to the previous behavior. To avoid this potential breaking change, use this approach only for urgent
matters.
<details><summary>See instructions if you're sure about enabling the feature globally through the feature flag definition</summary>
If you're still unsure whether the feature is [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release)
but want to release it in the current milestone, you can change the default state of the feature flag to be enabled.
To do so, follow these steps:
- [ ] Create a merge request with the following changes. Ask for review and merge it.
- [ ] If feature was enabled for various actors, ensure the feature has been enabled globally on production `/chatops run feature get <feature-flag-name>`. If the feature has not been globally enabled then enable the feature globally using: `/chatops run feature set <feature-flag-name> true`
- [ ] Set the `default_enabled` attribute in [the feature flag definition](https://docs.gitlab.com/ee/development/feature_flags/#feature-flag-definition-and-validation) to `true`.
- [ ] Decide [which changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog) is needed.
- [ ] Ensure that the default-enabling MR has been included in the release package.
If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>`
- [ ] Consider cleaning up the feature flag from all environments by running these chatops command in `#production` channel. Otherwise these settings may override the default enabled: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
- [ ] Close [the feature issue](<feature-issue-link>) to indicate the feature will be released in the current milestone.
- [ ] Set the next milestone to this rollout issue for scheduling [the flag removal](#release-the-feature).
- [ ] (Optional) You can [create a separate issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) for scheduling the steps below to [Release the feature](#release-the-feature).
- [ ] Set the title to "[Feature flag] Cleanup `<feature-flag-name>`".
- [ ] Execute the `/copy_metadata <this-rollout-issue-link>` quick action to copy the labels from this rollout issue.
- [ ] Link this rollout issue as a related issue.
- [ ] Close this rollout issue.
</details>
### Release the feature
After the feature has been [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release),
the [clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up)
should be done as soon as possible to permanently enable the feature and reduce complexity in the
codebase.
You can either [create a follow-up issue for Feature Flag Cleanup](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) or use the checklist below in this same issue.
<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
- [ ] Create a merge request to remove the `<feature-flag-name>` feature flag. Ask for review/approval/merge as usual. The MR should include the following changes:
- Remove all references to the feature flag from the codebase.
- Remove the YAML definitions for the feature from the repository.
- Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
- [ ] Ensure that the cleanup MR has been included in the release package.
If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>`
- [ ] Close [the feature issue](<feature-issue-link>) to indicate the feature will be released in the current milestone.
- [ ] Clean up the feature flag from all environments by running these chatops command in `#production` channel: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
- [ ] Close this rollout issue.
## Rollback Steps
- [ ] This feature can be disabled on production by running the following Chatops command:
```
/chatops run feature set <feature-flag-name> false
```
- [ ] Disable the feature flag on non-production environments:
```
/chatops run feature set <feature-flag-name> false --dev --pre --staging --staging-ref
```
- [ ] Delete feature flag from all environments:
```
/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production
```
<!-- Uncomment the appropriate type label
/label ~"type::feature" ~"feature::addition"
/label ~"type::maintenance"
/label ~"type::bug"
--></content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature flag</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
<due_date>2024-09-03</due_date>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480035</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480035"/>
<title>[Frontend] Add delete allowlist modal</title>
<updated>2024-08-21T01:02:35Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Frontend] Add delete allowlist modal</summary>
<description>### Overview
This issue tracks the ~frontend changes to allow users to delete an allowlist.
### Design
&lt;details&gt;
&lt;summary&gt;Delete modals&lt;/summary&gt;
{width=637 height=206}
{width=637 height=206}
{width=645 height=248}
{width=723 height=300}
</details>
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/479344
### Implementation Plan
* [ ] Add a new configurable modal
* [ ] Implement various variant based on allowlist type
* [ ] Add `delete` option to the options list
* [ ] Add specs</content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480034</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480034"/>
<title>[Frontend] Render allowlist details in a drawer</title>
<updated>2024-08-21T01:02:37Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Frontend] Render allowlist details in a drawer</summary>
<description>### Overview
This issue tracks the ~frontend changes to render the allowlist details in a drawer.
### Design
&lt;details&gt;
&lt;summary&gt;Render allowlist item&lt;/summary&gt;
{width=501 h...</description>
<content>### Overview
This issue tracks the ~frontend changes to render the allowlist details in a drawer.
### Design
<details>
<summary>Render allowlist item</summary>
{width=501 height=776}
</details>
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/479344
### Implementation Plan
* [ ] Add ~GraphQL query to fetch the details
* [ ] Render allowlist details in a drawer
* [ ] Make the fields not editable
* [ ] Add specs</content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480031</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480031"/>
<title>[Frontend] Add capability to update an allowlist item</title>
<updated>2024-08-21T01:02:38Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Frontend] Add capability to update an allowlist item</summary>
<description>### Overview
This issue tracks the ~frontend changes to allow users to update an existing allowlist item in the drawer
### Design
&lt;details&gt;
&lt;summary&gt;Update existing item&lt;/summary&gt;
{width=453 height=828}
</details>
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/479344
### Implementation Plan
* [ ] Add edit capability to the existing `GlForm` fields.
* [ ] Add ~GraphQL mutation to update an item
* [ ] Implement the cache to render the updated values
* [ ] Add specs</content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480029</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480029"/>
<title>[Frontend] Add form to create new allowlist item</title>
<updated>2024-08-21T01:02:40Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Frontend] Add form to create new allowlist item</summary>
<description>### Overview
This issue tracks the ~frontend changes to allow users to add new allowlist items using drawer approach.
### Design
&lt;details&gt;
&lt;summary&gt;Add new item&lt;/summary&gt;
{...</description>
<content>### Overview
This issue tracks the ~frontend changes to allow users to add new allowlist items using drawer approach.
### Design
<details>
<summary>Add new item</summary>
{width=394 height=830}
</details>
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/479344
### Implementation Plan
* [ ] Implement new form using `GlForm`
* [ ] Add ~GraphQL mutation to add new item
* [ ] Render the form in the Drawer using `GlDrawer`
* [ ] Add specs</content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480027</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480027"/>
<title>[Frontend] List all Allowlist items in a table with Pagination support</title>
<updated>2024-08-21T01:02:41Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Frontend] List all Allowlist items in a table with Pagination support</summary>
<description>### Overview
This issue tracks the ~frontend changes to display all saved allowlist items.
### Design
&lt;details&gt;
&lt;summary&gt;List of items&lt;/summary&gt;
{width=1213 height=743}
&lt;/...</description>
<content>### Overview
This issue tracks the ~frontend changes to display all saved allowlist items.
### Design
<details>
<summary>List of items</summary>
{width=1213 height=743}
</details>
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/479344
### Implementation Plan
* [ ] Add ~GraphQL query to fetch all allowlist items
* [ ] Display the list in `GlTable` format
* [ ] Implement pagination using `GlPagination` and make necessary changes
* [ ] Add button to add new item
* [ ] Add specs</content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480026</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480026"/>
<title>[Ban AI] Remove Feature Flags for Group, Admin, and Project Duo Settings</title>
<updated>2024-08-20T19:56:22Z</updated>
<media:thumbnail width="40" height="40" url="https://gitlab.com/uploads/-/system/user/avatar/20539920/avatar.png"/>
<author>
<name>Lindsey Shelton</name>
<email></email>
</author>
<summary>[Ban AI] Remove Feature Flags for Group, Admin, and Project Duo Settings</summary>
<description>## Context
We need to remove the following feature flags from the codebase when they have been rolled out 100%:
- `ai_settings_vue_admin`
- `ai_settings_vue_group`
- `ai_settings_vue_project`
:rotating_light: **THIS WORK IS CURRENTLY B...</description>
<content>## Context
We need to remove the following feature flags from the codebase when they have been rolled out 100%:
- `ai_settings_vue_admin`
- `ai_settings_vue_group`
- `ai_settings_vue_project`
:rotating_light: **THIS WORK IS CURRENTLY BLOCKED BY THE FOLLOWING ISSUES:**
- #470584 [Ban AI] Feature Flag Rollout admin and group settings
- #471108 [Ban AI] Feature Flag Rollout project settings
**Associated MRs:**
- [Ban AI remove Duo Admin Settings FF](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163055)
- [Ban AI remove Duo Group Settings FF](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163227)
- [Ban AI remove Duo Project Settings FF](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163218)
## Scope of this issue
- [ ] Remove `ai_settings_vue_admin` feature flag, and references in associated components/specs
- [ ] Remove `ai_settings_vue_group` feature flag, and references in associated components/specs
- [ ] Remove `ai_settings_vue_project` feature flag, and references in associated components/specs</content>
<milestone>17.4</milestone>
<labels>
<label>Deliverable</label>
<label>devops::ai-powered</label>
<label>feature flag</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::ai framework</label>
<label>section::data-science</label>
<label>type::feature</label>
</labels>
<assignees>
<assignee>
<name>Lindsey Shelton</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Lindsey Shelton</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480024</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480024"/>
<title>[Frontend] Add empty state for secret detection configuration</title>
<updated>2024-08-21T01:02:42Z</updated>
<media:thumbnail width="40" height="40" url="https://secure.gravatar.com/avatar/fa1c42243418dc1b1aa7a67c7ffbffb2eb8043a347608a34a7539a0da10aefea?s=80&d=identicon"/>
<author>
<name>Dheeraj Joshi</name>
<email></email>
</author>
<summary>[Frontend] Add empty state for secret detection configuration</summary>
<description>### Overview
This issue tracks the ~frontend changes to introduce the empty state for configuration Secret Detection.
### Design
&lt;details&gt;&lt;summary&gt;Empty state&lt;/summary&gt;
{wid...</description>
<content>### Overview
This issue tracks the ~frontend changes to introduce the empty state for configuration Secret Detection.
### Design
<details><summary>Empty state</summary>
{width=1125 height=760}
</details>
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/479344
### Implementation Plan
* [ ] Add a new breadcrumb option "Secret detection configuration"
* [ ] Add a single tab for "Allowlist"
* [ ] Amend count next to the tab title
* [ ] Add empty state log with description and CTA to add new item
* [ ] Add new specs</content>
<milestone>17.4</milestone>
<labels>
<label>Category:Secret Detection</label>
<label>Deliverable</label>
<label>UX</label>
<label>analytics instrumentation</label>
<label>devops::secure</label>
<label>feature::addition</label>
<label>frontend</label>
<label>group::secret detection</label>
<label>secret detection allowlist</label>
<label>secret push protection</label>
<label>section::sec</label>
<label>type::feature</label>
<label>workflow::ready for development</label>
</labels>
<assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</assignees>
<assignee>
<name>Dheeraj Joshi</name>
<email></email>
</assignee>
</entry>
<entry>
<id>https://gitlab.com/gitlab-org/gitlab/-/issues/480017</id>
<link href="https://gitlab.com/gitlab-org/gitlab/-/issues/480017"/>
<title>Unified Backups: Metadata display and validation command</title>
<updated>2024-08-21T01:02:35Z</updated>
<media:thumbnail width="40" height="40" url="https://gitlab.com/uploads/-/system/user/avatar/2293/avatar.png"/>
<author>
<name>Gabriel Mazetto</name>
<email></email>
</author>
<summary>Unified Backups: Metadata display and validation command</summary>
<description>### Proposal