kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-09-27 09:14:34 +00:00
parent aa04de2d2b
commit 1b9f574b89
21 changed files with 395 additions and 114 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
app/graphql/types/subscription_type.rb
View File

@ -26,6 +26,11 @@ module Types
subscription: Subscriptions::IssuableUpdated,
null: true,
description: 'Triggered when the reviewers of a merge request are updated.'
field :merge_request_merge_status_updated,
subscription: Subscriptions::IssuableUpdated,
null: true,
description: 'Triggered when the merge status of a merge request is updated.'
end
end

6
app/services/issues/create_service.rb
View File

@ -21,6 +21,8 @@ module Issues
end
def execute(skip_system_notes: false)
return error(_('Operation not allowed'), 403) unless @current_user.can?(authorization_action, @project)
@issue = @build_service.execute
handle_move_between_ids(@issue)
@ -94,6 +96,10 @@ module Issues
private
def authorization_action
:create_issue
end
attr_reader :spam_params, :extra_params
def create_escalation_status(issue)

8
app/services/work_items/create_service.rb
View File

@ -16,10 +16,6 @@ module WorkItems
end
def execute
unless @current_user.can?(:create_work_item, @project)
return error(_('Operation not allowed'), :forbidden)
end
result = super
return result if result.error?
@ -45,6 +41,10 @@ module WorkItems
private
def authorization_action
:create_work_item
end
def payload(work_item)
{ work_item: work_item }
end

18
db/post_migrate/20220920135356_tiebreak_user_type_index.rb Normal file
View File

@ -0,0 +1,18 @@
# frozen_string_literal: true
class TiebreakUserTypeIndex < Gitlab::Database::Migration[2.0]
disable_ddl_transaction!
NEW_INDEX_NAME = 'index_users_on_user_type_and_id'
OLD_INDEX_NAME = 'index_users_on_user_type'
def up
add_concurrent_index :users, [:user_type, :id], name: NEW_INDEX_NAME
remove_concurrent_index_by_name :users, OLD_INDEX_NAME
end
def down
add_concurrent_index :users, :user_type, name: OLD_INDEX_NAME
remove_concurrent_index_by_name :users, NEW_INDEX_NAME
end
end

40
db/post_migrate/20220921144258_remove_orphan_group_token_users.rb Normal file
View File

@ -0,0 +1,40 @@
# frozen_string_literal: true
class RemoveOrphanGroupTokenUsers < Gitlab::Database::Migration[2.0]
restrict_gitlab_migration gitlab_schema: :gitlab_main
disable_ddl_transaction!
class MigrationUser < MigrationRecord
include EachBatch
self.table_name = 'users'
scope :project_bots, -> { where(user_type: 6) }
scope :without_memberships, -> { where("NOT EXISTS (SELECT 1 FROM members where members.user_id = users.id)") }
end
class MigrationPersonalAccessToken < MigrationRecord
self.table_name = 'personal_access_tokens'
end
def up
delete_worker = 'DeleteUserWorker'.safe_constantize
MigrationUser.project_bots.each_batch(of: 1000) do |batch|
bot_ids = batch.without_memberships.pluck(:id)
MigrationPersonalAccessToken.where(user_id: bot_ids).delete_all
next unless delete_worker && delete_worker.respond_to?(:perform_async)
bot_ids.each do |bot_id|
delete_worker.perform_async(bot_id, bot_id, skip_authorization: true)
end
end
end
def down
# no-op
end
end

1
db/schema_migrations/20220920135356 Normal file
View File

@ -0,0 +1 @@
477f7b75c7d9b162add500924e5bbd9240ef76f3c56851748af8c6a59d912b7e

1
db/schema_migrations/20220921144258 Normal file
View File

@ -0,0 +1 @@
531758adf94d39b646e47601989f5f969eda8e9cbc2b2d6285826f9704575d3d

2
db/structure.sql
View File

@ -30544,7 +30544,7 @@ CREATE INDEX index_users_on_unconfirmed_email ON users USING btree (unconfirmed_
CREATE UNIQUE INDEX index_users_on_unlock_token ON users USING btree (unlock_token);
CREATE INDEX index_users_on_user_type ON users USING btree (user_type);
CREATE INDEX index_users_on_user_type_and_id ON users USING btree (user_type, id);
CREATE INDEX index_users_on_username ON users USING btree (username);

10
doc/api/feature_flags.md
View File

@ -4,16 +4,16 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Feature Flags API **(FREE)**
# Feature flags API **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9566) in GitLab Premium 12.5.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212318) to GitLab Free in 13.5.
API for accessing resources of [GitLab Feature Flags](../operations/feature_flags.md).
API for accessing resources of [GitLab feature flags](../operations/feature_flags.md).
Users with Developer or higher [permissions](../user/permissions.md) can access Feature Flag API.
Users with Developer or higher [permissions](../user/permissions.md) can access the feature flag API.
## Feature Flags pagination
## Feature flags pagination
By default, `GET` requests return 20 results at a time because the API results
are [paginated](index.md#pagination).
@ -144,7 +144,7 @@ POST /projects/:id/feature_flags
| ------------------- | ---------------- | ---------- | ---------------------------------------------------------------------------------------|
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding). |
| `name` | string | yes | The name of the feature flag. |
| `version` | string | yes | The version of the feature flag. Must be `new_version_flag`. Omit or set to `legacy_flag` to create a Legacy Feature Flag. |
| `version` | string | yes | The version of the feature flag. Must be `new_version_flag`. Omit or set to `legacy_flag` to create a Legacy feature flag. |
| `description` | string | no | The description of the feature flag. |
| `active` | boolean | no | The active state of the flag. Defaults to true. [Supported](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38350) in GitLab 13.3 and later. |
| `strategies` | JSON | no | The feature flag [strategies](../operations/feature_flags.md#feature-flag-strategies). |

2
doc/architecture/blueprints/feature_flags_development/index.md
View File

@ -6,7 +6,7 @@ comments: false
description: 'Internal usage of Feature Flags for GitLab development'
---
# Usage of Feature Flags for GitLab development
# Architectural discussion of feature flags
Usage of feature flags become crucial for the development of GitLab. The
feature flags are a convenient way to ship changes early, and safely rollout

13
doc/development/feature_flags/controls.md
View File

@ -5,12 +5,15 @@ group: Development
info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
---
# Feature flag controls
# Use ChatOps to enable and disable feature flags
## Access
NOTE:
This document explains how to contribute to the development of the GitLab product.
If you want to use feature flags to show and hide functionality in your own applications,
view [this feature flags information](../../operations/feature_flags.md) instead.
To be able to turn on/off features behind feature flags in any of the
GitLab Inc. provided environments such as staging and production, you need to
To turn on/off features behind feature flags in any of the
GitLab-provided environments, like staging and production, you need to
have access to the [ChatOps](../chatops_on_gitlabcom.md) bot. The ChatOps bot
is currently running on the ops instance, which is different from
[GitLab.com](https://gitlab.com) or [`dev.gitlab.org`](https://dev.gitlab.org).
@ -47,7 +50,7 @@ Note that all the examples in that file must be preceded by
If you get an error "Whoops! This action is not allowed. This incident
will be reported." that means your Slack account is not allowed to
change feature flags or you do not [have access](#access).
change feature flags or you do not have access.
### Enabling a feature for pre-production testing

12
doc/development/feature_flags/index.md
View File

@ -8,18 +8,14 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo
# Feature flags in the development of GitLab
NOTE:
The documentation below covers feature flags used by GitLab to deploy its own features, which **is not** the same
as the [feature flags offered as part of the product](../../operations/feature_flags.md).
This document provides guidelines on how to use feature flags
for the development of GitLab to conditionally and/or incrementally enable features
and test them in production/staging.
This document explains how to contribute to the development of the GitLab product.
If you want to use feature flags to show and hide functionality in your own applications,
view [this feature flags information](../../operations/feature_flags.md) instead.
WARNING:
All newly-introduced feature flags should be [disabled by default](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flags-in-gitlab-development).
NOTE:
This document is the subject of continued work as part of an epic to [improve internal usage of Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic.
This document is the subject of continued work as part of an epic to [improve internal usage of feature flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic.
For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, please see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page.

2
doc/development/gitaly.md
View File

@ -219,7 +219,7 @@ as a [CI/CD variable](../ci/variables/index.md).
If you are making changes to the RPC client, such as adding a new endpoint or adding a new
parameter to an existing endpoint, follow the guide for
[Gitaly protobuf specifications](https://gitlab.com/gitlab-org/gitaly/blob/master/proto/README.md). After pushing
[Gitaly protobuf specifications](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/protobuf.md). After pushing
the branch with the changes (`new-feature-branch`, for example):
1. Change the `gitaly` line in the Rails' `Gemfile` to:

245
doc/development/gitlab_flavored_markdown/specification_guide/index.md
View File

@ -76,7 +76,7 @@ to by the acronym GFM, and this document follows that convention as well.
_GitLab_ Flavored Markdown is referred to as GLFM in this document,
to distinguish it from GitHub Flavored Markdown.
Unfortunately, this convention is not followed consistently in the rest
Unfortunately, this convention is not yet followed consistently in the rest
of the documentation or GitLab codebase. In many places, the GFM
acronym is used to refer to _GitLab_ Flavored Markdown. An
[open issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24592) exists to resolve
@ -110,7 +110,7 @@ Here are the HTML-rendered versions of the specifications:
NOTE:
The creation of the
[GitLab Flavored Markdown (GLFM) specification](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/output/spec.html)
[HTML-rendered version of the GitLab Flavored Markdown (GLFM) specification](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/output/spec.html)
file is still pending.
However, GLFM has more complex parsing, rendering, and testing requirements than
@ -167,7 +167,8 @@ Markdown for issues, pull requests, or merge requests within the editor or IDE.
### Markdown examples
Everywhere in the context of the specification and this guide, the term
_examples_ is specifically used to refer to the Markdown + HTML pairs used
_examples_ is specifically used to refer to the convention of using
backtick-delimited Markdown + HTML pairs
to illustrate the canonical parsing (or rendering) behavior of various Markdown source
strings in the standard
[CommonMark specification format](https://spec.commonmark.org/0.30/#example-1).
@ -176,6 +177,9 @@ In this context, it should not be confused with other similar or related meaning
_example_, such as
[RSpec examples](https://relishapp.com/rspec/rspec-core/docs/example-groups/basic-structure-describe-it).
See the section on the [`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd) file
for more details on the backtick-delimited Markdown+HTML example syntax.
### Parsers and renderers
To understand the various ways in which a specification is used, and how it related
@ -206,7 +210,13 @@ _Markdown conformance testing_ refers to the standard testing method used by
all CommonMark Markdown dialects to verify that a specific implementation conforms
to the CommonMark Markdown specification. It is enforced by running the standard
CommonMark tool [`spec_tests.py`](https://github.com/github/cmark-gfm/blob/master/test/spec_tests.py)
against a given `spec.txt` specification and the implementation.
against a given `spec.txt` specification and the implementation, as
[described in the specification itself](https://github.github.com/gfm/#about-this-document)
Conformance testing is _only_ to be run against GLFM [official specification](#official-specifications)
examples, and is _not_ to be run against [internal extension](#internal-extensions) examples.
This is because the internal extension examples may have dependencies on the GitLab environment
or metadata, but the standard CommonMark conformance testing tool does not support this.
NOTE:
`spec_tests.py` may eventually be re-implemented in Ruby, to not have a dependency on Python.
@ -220,7 +230,14 @@ tests which use the fixture data. This fixture data is contained in YAML files.
are generated and updated based on the Markdown examples in the specification,
and the existing GLFM parser and render implementations. They may also be
manually updated as necessary to test-drive incomplete implementations.
Regarding the terminology used here:
Snapshot testing is intended to be comprehensive, so it is run against _all_ examples - both the GLFM
[official specification](#official-specifications) and [internal extension](#internal-extensions) examples.
This means that it uses configuration files to support providing GitLab-specific environment or metadata
which is required by internal extension examples, such
as [`glfm_example_metadata.yml`](#glfm_example_metadatayml).
Regarding the terminology used for Markdown snapshot testing:
<!-- vale gitlab.InclusionCultural = NO -->
@ -303,13 +320,14 @@ implementations:
### Multiple versions of rendered HTML
Both of these GLFM renderer implementations (static and WYSIWYG) produce
HTML which differs from the canonical HTML examples from the specification.
For every Markdown example in the GLFM specification, three
HTML which may differ from the canonical HTML examples in the
<abbr title="GitLab Flavored Markdown">GLFM</abbr> [official specification](#official-specifications).
Therefore, for every Markdown example in the GLFM specification, three
versions of HTML can potentially be rendered from the example:
- Static HTML.
- WYSIWYG HTML.
- Canonical HTML.
- Static HTML
- WYSIWYG HTML
- Canonical HTML
#### Static HTML
@ -319,22 +337,57 @@ added for dynamically creating an issue from a task list item.
The GitLab [Markdown API](../../../api/markdown.md) generates HTML
for a given Markdown string using this method.
The Markdown specified in the [Markdown examples](#markdown-examples) is used to automatically generate HTML in
[`glfm_specification/example_snapshots/html.yml`](#glfm_specificationexample_snapshotshtmlyml) via
[`update-example-snapshots.rb`](#update-example-snapshotsrb-script). These examples are
used when running [Markdown snapshot testing](#markdown-snapshot-testing).
#### WYSIWYG HTML
**WYSIWYG HTML** is HTML produced by the frontend (JavaScript) Content Editor,
which includes parsing and rendering logic. It is used to present an editable document
in the ProseMirror WYSIWYG editor.
Just like static HTML,
the Markdown specified in the [Markdown examples](#markdown-examples) is used to automatically generate HTML in
[`glfm_specification/example_snapshots/html.yml`](#glfm_specificationexample_snapshotshtmlyml) via
[`update-example-snapshots.rb`](#update-example-snapshotsrb-script). These examples are
used when running [Markdown snapshot testing](#markdown-snapshot-testing).
#### Canonical HTML
**Canonical HTML** is the clean, basic version of HTML rendered from Markdown.
**Canonical HTML** is the clean, basic version of HTML rendered from Markdown, with no
unnecessary classes/elements related to styling or any other implementation-specific behavior.
1. For the examples which come from the CommonMark specification and
Its purpose is to support [Markdown conformance testing](#markdown-conformance-testing) against the
GLFM [`spec.txt`](#spectxt).
Always hardcoded and manually curated, the HTML is never automatically generated.
The [Markdown examples](#markdown-examples) specifying it are contained
in different files depending on which [Markdown specification](#various-markdown-specifications)
a given example originally comes from.
Canonical HTML is **_always specified_** for all [Markdown examples](#markdown-examples)
in the CommonMark, <abbr title="GitHub Flavored Markdown">GFM</abbr>, and <abbr title="GitLab Flavored Markdown">GLFM</abbr>
[official specifications](#official-specifications).
However, it is **_never specified_** for GLFM [internal extensions](#internal-extensions) in the [Markdown examples](#markdown-examples).
**This is because the internal extensions are never tested via [Markdown conformance testing](#markdown-conformance-testing).
Therefore, canonical HTML for internal extension examples is never used by any scripts or automated testing.**
Here are more details on the sources of canonical HTML examples:
1. For the examples which are part of the CommonMark specification and
GFM extensions specification, the canonical HTML is the exact identical HTML found in the
GFM `spec.txt` example blocks.
1. For GLFM extensions to the <abbr title="GitHub Flavored Markdown">GFM</abbr> / CommonMark
specification, a `glfm_canonical_examples.txt` [input specification file](#input-specification-files)
contains the Markdown examples and corresponding canonical HTML examples.
[GFM `spec.txt`](https://github.com/github/cmark-gfm/blob/master/test/spec.txt) [Markdown example](#markdown-examples) blocks.
These examples are copied verbatim from the GFM `spec.txt` into the GLFM
version of [`spec.txt`](#spectxt).
1. For the examples which are part of the GLFM [_official specification_](#official-specifications),
the canonical HTML is manually maintained and curated via the examples contained in the
[`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd) [input specification file](#input-specification-files).
1. For the examples which are part of the GLFM [_internal extensions_](#internal-extensions),
the canonical HTML **is never specified**, and **must be left empty in all examples** contained in
the [`glfm_internal_extension_examples.md`](#glfm_internal_extension_examplesmd) [input specification file](#input-specification-files).
### Canonicalization of HTML
@ -342,7 +395,11 @@ The rendered [static HTML](#static-html) and [WYSIWYG HTML](#wysiwyg-html)
from the backend (Ruby) and frontend (JavaScript) renderers usually contains extra styling
or HTML elements, to support specific appearance and behavioral requirements.
Neither the backend nor the frontend rendering logic can directly render the clean, basic canonical HTML.
Neither the backend nor the frontend rendering logic can directly render the clean, basic HTML
which is necessary to perform comparison to the [canonical HTML](#canonical-html)
when running [Markdown conformance testing](#markdown-conformance-testing)
for the [GLFM official specification examples](#glfm_official_specification_examplesmd).
Nor should they be able to, because:
- It's not a direct requirement to support any GitLab application feature.
@ -351,16 +408,9 @@ Nor should they be able to, because:
Instead, the rendered static or WYSIWYG HTML is converted to canonical HTML by a
_canonicalization_ process. This process can strip all the extra styling and behavioral
HTML from the static or WYSIWYG HTML, resulting in canonical HTML which exactly
matches the Markdown + HTML examples in a standard `spec.txt` specification.
matches the canonical HTML examples in a standard `spec.txt` specification.
Use the [`canonicalize-html.rb` script](#canonicalize-htmlrb-script) for this process.
More explanation about this canonicalization process in the sections below.
NOTE:
Some of the static or WYSIWYG HTML examples may not be representable as canonical
HTML. (For example, when they are represented as an image.) In these cases, the Markdown
conformance test for the example can be skipped by setting `skip_update_example_snapshots: true`
for the example in `glfm_specification/input/gitlab_flavored_markdown/glfm_example_status.yml`.
### Normalization
@ -449,7 +499,7 @@ of how the normalizations are specified.
## Goals
Given the constraints above, we have a few goals related to the GLFM
Given all the constraints above, we can summarize the various goals related to the GLFM
specification and testing infrastructure:
1. A canonical `spec.txt` exists, and represents the official specification for
@ -458,17 +508,18 @@ specification and testing infrastructure:
(GFM) specification, just as
<abbr title="GitHub Flavored Markdown">GFM</abbr> is a strict superset
[of the CommonMark specification](https://github.github.com/gfm/#what-is-github-flavored-markdown-).
Therefore, it contains the superset of all canonical Markdown + HTML examples
for CommonMark, GFM, and GLFM.
1. Therefore, it contains the superset of all [Markdown examples](#markdown-examples)
for CommonMark and GFM, as well as the GLFM
[official specification](#official-specifications) and [internal extensions](#internal-extensions).
1. It contains a prose introduction section which is specific to GitLab and GLFM.
1. It contains all other non-introduction sections verbatim from the
GFM
`spec.txt`.
1. It contains a new extra section for the GLFM GitLab-specific extensions,
with both prose and examples describing the extensions.
1. It should be in the standard format which can processed by the standard
CommonMark tools [`spec_tests.py`](https://github.com/github/cmark-gfm/blob/master/test/spec_tests.py),
which is a [script used to run the Markdown conformance tests](https://github.github.com/gfm/#about-this-document)
[GFM specification](#github-flavored-markdown-specification).
1. It contains new, extra sections for all the additional Markdown contained in the GLFM
[official specification](#official-specifications) and [internal extensions](#internal-extensions),
with [Markdown examples](#markdown-examples) and accompanying prose, just like the CommonMark and GFM examples.
1. All its headers and [Markdown examples](#markdown-examples) should be in the standard format which can be processed by the standard
CommonMark tool [`spec_tests.py`](https://github.com/github/cmark-gfm/blob/master/test/spec_tests.py) used to perform
[Markdown conformance testing](#markdown-conformance-testing)
against all examples contained in a `spec.txt`.
1. The GLFM parsers and HTML renderers for
both the static backend (Ruby) and WYSIWYG frontend (JavaScript) implementations
@ -478,9 +529,9 @@ specification and testing infrastructure:
NOTE:
Consistent does not mean that both of these implementations render
to the identical HTML. They each have different implementation-specific additions
to the HTML they render, so therefore their rendered HTML is
["canonicalized"](#canonicalization-of-html) to canonical HTML prior running
the Markdown conformance tests.
to the HTML they render, so their rendered HTML is
["canonicalized"](#canonicalization-of-html) to canonical HTML prior to running
[Markdown conformance testing](#markdown-conformance-testing).
1. For _both_ the static backend (Ruby) and WYSIWYG frontend (JavaScript) implementations,
a set of example snapshots exists in the form of YAML files, which
correspond to every Markdown example in the GLFM `spec.txt`. These example snapshots
@ -552,7 +603,7 @@ them from the corresponding implementation class entry point files under
#### `update-specification.rb` script
The `scripts/glfm/update-specification.rb` script uses specification input files to
The `scripts/glfm/update-specification.rb` script uses [input specification files](#input-specification-files) to
generate and update `spec.txt` (Markdown) and `spec.html` (HTML). The `spec.html` is
generated by passing the generated (or updated) `spec.txt` Markdown to the backend API
for rendering to static HTML:
@ -566,12 +617,13 @@ end
subgraph input:<br/>input specification files
C[ghfm_spec_v_0.29.txt] --> A
D[glfm_intro.txt] --> A
E[glfm_canonical_examples.txt] --> A
E[glfm_official_specification_examples.md] --> A
F[glfm_internal_extension_examples.md] --> A
end
subgraph output:<br/>GLFM specification files
A --> F[spec.txt]
F --> B
B --> G[spec.html]
A --> G[spec.txt]
G --> B
B --> H[spec.html]
end
```
@ -723,13 +775,24 @@ is the GitLab-specific version of the prose in the introduction section of the G
##### `glfm_canonical_examples.txt`
[`glfm_specification/input/gitlab_flavored_markdown/glfm_canonical_examples.txt`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/input/gitlab_flavored_markdown/glfm_canonical_examples.txt)
is the manually updated canonical Markdown+HTML examples for GLFM extensions.
The `glfm_canonical_examples.txt` file is deprecated and no longer exists. It has been replaced by two files:
- It contains examples in the [standard backtick-delimited `spec.txt` format](#various-markdown-specifications),
each of which contain a Markdown example and the corresponding canonical HTML.
- [`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd)
which contains the [GLFM official specification](#official-specifications) examples.
- [`glfm_internal_extension_examples.md`](#glfm_internal_extension_examplesmd)
which contains the [GLFM internal extension](#internal-extensions) examples.
##### `glfm_official_specification_examples.md`
[`glfm_specification/input/gitlab_flavored_markdown/glfm_official_specification_examples.md`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/input/gitlab_flavored_markdown/glfm_official_specification_examples.md)
consists of the manually updated Markdown+HTML examples for the
[GLFM official specification](#official-specifications), and their associated documentation and descriptions.
- It contains [Markdown examples](#markdown-examples) in the
[standard backtick-delimited `spec.txt` format](#various-markdown-specifications),
each of which contains Markdown and the corresponding canonical HTML that should be rendered.
- For all GitLab examples, the "extension" annotation after the backticks should consist of only
`example gitlab`. It does not currently include any additional extension annotations describing
`example`. It does not currently include any additional extension annotations describing
the specific Markdown, unlike the GitHub Flavored Markdown examples, which do include
these additional annotations (such as `example strikethrough`).
- The `update-specification.rb` script inserts it as new sections before the appendix
@ -739,7 +802,7 @@ is the manually updated canonical Markdown+HTML examples for GLFM extensions.
- `H3` header sections must be nested within `H2` header sections. They cannot be
nested directly within `H1` header sections.
`glfm_specification/input/gitlab_flavored_markdown/glfm_canonical_examples.txt` sample entries:
`glfm_specification/input/gitlab_flavored_markdown/glfm_official_specification_examples.md` sample entries:
NOTE:
All lines in this example are prefixed with a `|` character. This prefix helps avoid false
@ -747,21 +810,21 @@ errors when this file is checked by `markdownlint`, and possible errors in other
The actual file should not have these prefixed `|` characters.
```plaintext
|# First GitLab-Specific Section with Examples
|# Section with GLFM official specification examples
|
|## Strong but with two asterisks
|## Strong
|
|```````````````````````````````` example gitlab
|### Strong with two asterisks
|
|```````````````````````````````` example
|**bold**
|.
|<p><strong>bold</strong></p>
|````````````````````````````````
|
|# Second GitLab-Specific Section with Examples
|### Strong with HTML
|
|## Strong but with HTML
|
|```````````````````````````````` example gitlab
|```````````````````````````````` example
|<strong>
|bold
|</strong>
@ -772,6 +835,38 @@ The actual file should not have these prefixed `|` characters.
|````````````````````````````````
```
##### `glfm_internal_extension_examples.md`
[`glfm_specification/input/gitlab_flavored_markdown/glfm_internal_extension_examples.md`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/input/gitlab_flavored_markdown/glfm_internal_extension_examples.md)
consists of the manually updated Markdown examples for the
[GLFM internal extensions](#internal-extensions), and their associated documentation and descriptions.
Its general format is identical to [`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd),
consisting of `H1`, `H2`, or `H3` sections containing [Markdown examples](#markdown-examples) in the
[standard backtick-delimited `spec.txt` format](#various-markdown-specifications).
However, as described in the [canonical HTML section](#canonical-html), only the Markdown portion of each
example is specified, and the HTML portion is left empty, because internal extension examples are
never used for [Markdown conformance testing](#markdown-conformance-testing).
`glfm_specification/input/gitlab_flavored_markdown/glfm_official_specification_examples.md` sample entries:
NOTE:
All lines in this example are prefixed with a `|` character. This prefix helps avoid false
errors when this file is checked by `markdownlint`, and possible errors in other Markdown editors.
The actual file should not have these prefixed `|` characters.
```plaintext
|# Section with GLFM Internal Extension Examples
|
|## Video
|
|```````````````````````````````` example
|![video](video.m4v "video title")
|.
|````````````````````````````````
```
##### `glfm_example_status.yml`
[`glfm_specification/input/gitlab_flavored_markdown/glfm_example_status.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/input/gitlab_flavored_markdown/glfm_example_status.yml)
@ -834,8 +929,8 @@ The following optional entries are supported for each example. They all default
##### `glfm_example_normalizations.yml`
[`glfm_specification/input/gitlab_flavored_markdown/glfm_example_normalizations.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/input/gitlab_flavored_markdown/glfm_example_normalizations.yml)
controls the [normalization](#normalization) process. It allows one or more `regex`/`replacement` pairs
to be specified for a Markdown example.
is used to control the [fixture-based normalization](#fixture-based-normalization) process.
It allows one or more `regex`/`replacement` pairs to be specified for a Markdown example.
- It is manually updated.
- It has a nested structure corresponding to the example and type of entry it refers to.
@ -844,6 +939,11 @@ to be specified for a Markdown example.
- The YAML anchors use a naming convention based on the index number of the example, to
ensure unique anchor names and avoid naming conflicts.
NOTE:
Other approaches to [normalization](#normalization) such as [fixture-based normalization](#fixture-based-normalization)
or [environment-variable-based normalization](#environment-variable-based-normalization) are always preferable to
[fixture-based normalization](#fixture-based-normalization).
`glfm_specification/input/gitlab_flavored_markdown/glfm_example_normalizations.yml` sample entries:
```yaml
@ -924,11 +1024,11 @@ allows control over other aspects of the snapshot example generation process.
#### Output specification files
The `glfm_specification/output` directory contains the CommonMark standard format
`spec.txt` file which represents the canonical GLFM specification which is generated
`spec.txt` file which represents the GLFM specification which is generated
by the `update-specification.rb` script. It also contains the rendered `spec.html`
which is generated based on the `spec.txt` as input.
These output `spec.*` files, which represent the official, canonical GLFM specification,
These output `spec.*` files, which represent the GLFM specification,
are colocated under the same parent folder `glfm_specification` with the other
`input` specification files. They're located here both for convenience, and because they are all
a mix of manually edited and generated files.
@ -942,12 +1042,16 @@ move or copy a hosted version of the rendered HTML `spec.html` version to anothe
[`glfm_specification/output/spec.txt`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/output/spec.txt)
is a Markdown specification file, in the standard format
with prose and Markdown + canonical HTML examples. It is generated or updated by the
`update-specification.rb` script.
with prose and Markdown + canonical HTML examples.
It also serves as input for other scripts such as `update-example-snapshots.rb`
and `run-spec-tests.sh`.
It is generated or updated by the `update-specification.rb` script, using the
[input specification files](#input-specification-files) as input.
See the [`update-specification.rb` script section](#update-specificationrb-script)
for a diagram and more description on this process.
##### spec.html
[`glfm_specification/output/spec.html`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/output/spec.html)
@ -978,14 +1082,14 @@ be manually edited as necessary to help drive the implementations.
[`glfm_specification/example_snapshots/examples_index.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/example_snapshots/examples_index.yml)
is the main list of all
CommonMark, GFM, and GLFM example names, each with a unique canonical name.
CommonMark, GFM, and GLFM example names, each with a uniquely identifying name.
- It is generated from the hierarchical sections and examples in the
GFM `spec.txt` specification.
- For CommonMark and GFM examples,
these sections originally came from the GFM `spec.txt`.
- For GLFM examples, it is generated from `glfm_canonical_examples.txt`, which is
the additional Section 7 in the GLFM `spec.txt`.
- For GLFM examples, it is generated from
[`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd) and [`glfm_internal_extension_examples.md`](#glfm_internal_extension_examplesmd).
- It also contains extra metadata about each example, such as:
1. `spec_txt_example_position` - The position of the example in the generated GLFM `spec.txt` file.
- This value is the index order of each individual Markdown + HTML5 example in the file. It is _not_
@ -1031,8 +1135,8 @@ for each entry in `glfm_specification/example_snapshots/examples_index.yml`
it is generated (or updated) from the standard GFM
`spec.txt` using the `update-example-snapshots.rb` script.
- For GLFM, it is generated (or updated) from the
`glfm_specification/input/gitlab_flavored_markdown/glfm_canonical_examples.txt`
input specification file.
[`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd) and [`glfm_internal_extension_examples.md`](#glfm_internal_extension_examplesmd)
input specification files.
`glfm_specification/example_snapshots/markdown.yml` sample entry:
@ -1051,8 +1155,8 @@ Three types of entries exist, with different HTML for each:
- **Canonical**
- The ["Canonical"](#canonicalization-of-html) HTML.
- For CommonMark and GFM examples, the HTML comes from the examples in `spec.txt`.
- For GLFM examples, it is generated/updated from
`glfm_specification/input/gitlab_flavored_markdown/glfm_canonical_examples.txt`.
- For [GLFM official specification](#official-specifications) examples, it is generated/updated from
[`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd).
- **Static**
- This is the static (backend (Ruby)-generated) HTML for each entry in
`glfm_specification/example_snapshots/examples_index.yml`.
@ -1133,7 +1237,8 @@ This section describes how the scripts can be used to manage the GLFM specificat
### Update the example snapshots and run snapshot tests
1. If you are working on an in-progress feature or bug, make any necessary manual updates to the [input specification files](#input-specification-files). This may include:
1. Updating the canonical Markdown or HTML examples in `glfm_specification/input/gitlab_flavored_markdown/glfm_canonical_examples.txt`.
1. Updating the canonical Markdown or HTML examples in
[`glfm_official_specification_examples.md`](#glfm_official_specification_examplesmd) or [`glfm_internal_extension_examples.md`](#glfm_internal_extension_examplesmd).
1. Updating `glfm_specification/input/gitlab_flavored_markdown/glfm_example_status.yml` to reflect the current status of the examples or tests.
1. Run [`update-specification.rb`](#update-specificationrb-script) to update the `spec.txt` to reflect any changes which were made to the [input specification files](#input-specification-files).
1. Visually inspect and confirm any resulting changes to the [output specification files](#output-specification-files).

32
doc/operations/feature_flags.md
View File

@ -4,21 +4,21 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Feature Flags **(FREE)**
# Feature flags **(FREE)**
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212318) from GitLab Premium to GitLab Free in 13.5.
With Feature Flags, you can deploy your application's new features to production in smaller batches.
With feature flags, you can deploy your application's new features to production in smaller batches.
You can toggle a feature on and off to subsets of users, helping you achieve Continuous Delivery.
Feature flags help reduce risk, allowing you to do controlled testing, and separate feature
delivery from customer launch.
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For an example of feature flags in action, see [GitLab for Deploys, Feature Flags, and Error Tracking](https://www.youtube.com/embed/5tw2p6lwXxo).
For an example of feature flags in action, see [GitLab for deploys, feature flags, and error tracking](https://www.youtube.com/embed/5tw2p6lwXxo).
NOTE:
The Feature Flags GitLab offer as a feature (described in this document) is not the same method
used for the [development of GitLab](../development/feature_flags/index.md).
To contribute to the development of the GitLab product, view
[this feature flag content](../development/feature_flags/index.md) instead.
## How it works
@ -43,7 +43,7 @@ To create and enable a feature flag:
1. Enter a name that starts with a letter and contains only lowercase letters, digits, underscores (`_`),
or dashes (`-`), and does not end with a dash (`-`) or underscore (`_`).
1. Optional. Enter a description (255 characters maximum).
1. Add Feature Flag [**Strategies**](#feature-flag-strategies) to define how the flag should be applied. For each strategy, include the **Type** (defaults to [**All users**](#all-users))
1. Add feature flag [**Strategies**](#feature-flag-strategies) to define how the flag should be applied. For each strategy, include the **Type** (defaults to [**All users**](#all-users))
and **Environments** (defaults to all environments).
1. Select **Create feature flag**.
@ -74,9 +74,9 @@ is 200. For GitLab SaaS, the maximum number is determined by [tier](https://abou
You can apply a feature flag strategy across multiple environments, without defining
the strategy multiple times.
GitLab Feature Flags use [Unleash](https://docs.getunleash.io/) as the feature flag
GitLab feature flags use [Unleash](https://docs.getunleash.io/) as the feature flag
engine. In Unleash, there are [strategies](https://docs.getunleash.io/user_guide/activation_strategy)
for granular feature flag controls. GitLab Feature Flags can have multiple strategies,
for granular feature flag controls. GitLab feature flags can have multiple strategies,
and the supported strategies are:
- [All users](#all-users)
@ -162,7 +162,7 @@ target users. See the [Ruby example](#ruby-application-example) below.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35930) in GitLab 13.1.
Enables the feature for lists of users created [in the Feature Flags UI](#create-a-user-list), or with the [Feature Flag User List API](../api/feature_flag_user_lists.md).
Enables the feature for lists of users created [in the feature flags UI](#create-a-user-list), or with the [feature flag user list API](../api/feature_flag_user_lists.md).
Similar to [User IDs](#user-ids), it uses the Unleash UsersIDs (`userWithId`) activation [strategy](https://docs.getunleash.io/user_guide/activation_strategy#userids).
It's not possible to *disable* a feature for members of a user list, but you can achieve the same
@ -294,9 +294,9 @@ Unleash currently [offers many SDKs for various languages and frameworks](https:
For API content, see:
- [Feature Flags API](../api/feature_flags.md)
- [Feature Flag Specs API](../api/feature_flag_specs.md) (Deprecated and [scheduled for removal](https://gitlab.com/gitlab-org/gitlab/-/issues/213369) in GitLab 14.0.)
- [Feature Flag User Lists API](../api/feature_flag_user_lists.md)
- [Feature flags API](../api/feature_flags.md)
- [Feature flag specs API](../api/feature_flag_specs.md) (Deprecated and [scheduled for removal](https://gitlab.com/gitlab-org/gitlab/-/issues/213369) in GitLab 14.0.)
- [Feature flag user lists API](../api/feature_flag_user_lists.md)
### Golang application example
@ -395,13 +395,13 @@ docker run \
| `UNLEASH_APP_NAME` | The name of the environment the application runs in. For more details, read [Get access credentials](#get-access-credentials). |
| `UNLEASH_API_TOKEN` | Required to start the Unleash Proxy, but not used to connect to GitLab. Can be set to any value. |
## Feature Flag Related Issues **(PREMIUM)**
## Feature flag related issues **(PREMIUM)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36617) in GitLab 13.2.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/251234) in GitLab 13.5.
> - Showing related feature flags in issues [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/220333) in GitLab 14.1.
You can link related issues to a feature flag. In the Feature Flag **Linked issues** section,
You can link related issues to a feature flag. In the feature flag **Linked issues** section,
select the `+` button and input the issue reference number or the full URL of the issue.
The issues then appear in the related feature flag and the other way round.
@ -409,7 +409,7 @@ This feature is similar to the [linked issues](../user/project/issues/related_is
## Performance factors
In general, GitLab Feature Flags can be used in any applications,
In general, GitLab feature flags can be used in any applications,
however, if it's a large application, it could require an additional configuration in advance.
This section explains the performance factors to help your organization to identify
what's needed to be done before using the feature.
@ -418,7 +418,7 @@ Please read [How it works](#how-it-works) section before diving into the details
### Maximum supported clients in application nodes
GitLab accepts client requests as much as possible until it hits the [rate limiting](../security/rate_limits.md).
At the moment, the Feature Flag API falls into **Unauthenticated traffic (from a given IP address)**
At the moment, the feature flag API falls into **Unauthenticated traffic (from a given IP address)**
in the [GitLab.com specific limits](../user/gitlab_com/index.md),
so it's **500 requests per minute**.

1
spec/graphql/types/subscription_type_spec.rb
View File

@ -12,6 +12,7 @@ RSpec.describe GitlabSchema.types['Subscription'] do
issuable_labels_updated
issuable_dates_updated
merge_request_reviewers_updated
merge_request_merge_status_updated
]
expect(described_class).to include_graphql_fields(*expected_fields)

74
spec/migrations/20220921144258_remove_orphan_group_token_users_spec.rb Normal file
View File

@ -0,0 +1,74 @@
# frozen_string_literal: true
require 'spec_helper'
require_migration!
RSpec.describe RemoveOrphanGroupTokenUsers, :migration, :sidekiq_inline do
subject(:migration) { described_class.new }
let(:users) { table(:users) }
let!(:orphan_bot) do
create_bot(username: 'orphan_bot', email: 'orphan_bot@bot.com').tap do |bot|
namespaces.create!(type: 'User', path: 'n1', name: 'n1', owner_id: bot.id)
end
end
let!(:valid_used_bot) do
create_bot(username: 'used_bot', email: 'used_bot@bot.com').tap do |bot|
group = namespaces.create!(type: 'Group', path: 'used_bot_group', name: 'used_bot_group')
members.create!(user_id: bot.id,
source_id: group.id,
member_namespace_id: group.id,
source_type: 'Group',
access_level: 10,
notification_level: 0)
end
end
let!(:different_bot) do
create_bot(username: 'other_bot', email: 'other_bot@bot.com', user_type: 5)
end
let(:personal_access_tokens) { table(:personal_access_tokens) }
let(:members) { table(:members) }
let(:namespaces) { table(:namespaces) }
before do
stub_feature_flags(user_destroy_with_limited_execution_time_worker: false)
end
it 'removes orphan project bot and its tokens', :aggregate_failures do
expect(DeleteUserWorker)
.to receive(:perform_async)
.with(orphan_bot.id, orphan_bot.id, skip_authorization: true)
.and_call_original
migrate!
expect(users.count).to eq 2
expect(personal_access_tokens.count).to eq 2
expect(personal_access_tokens.find_by(user_id: orphan_bot.id)).to eq nil
end
context "when DeleteUserWorker doesn't fit anymore" do
it 'removes project bot tokens only', :aggregate_failures do
allow(DeleteUserWorker).to receive(:respond_to?).and_call_original
allow(DeleteUserWorker).to receive(:respond_to?).with(:perform_async).and_return(false)
migrate!
expect(users.count).to eq 3
expect(personal_access_tokens.count).to eq 2
expect(personal_access_tokens.find_by(user_id: orphan_bot.id)).to eq nil
end
end
private
def create_bot(**params)
users.create!({ projects_limit: 0, state: 'active', user_type: 6 }.merge(params)).tap do |bot|
personal_access_tokens.create!(user_id: bot.id, name: "BOT##{bot.id}")
end
end
end

4
spec/models/integrations/microsoft_teams_spec.rb
View File

@ -85,6 +85,10 @@ RSpec.describe Integrations::MicrosoftTeams do
service.hook_data(issue, 'open')
end
before do
project.add_developer(user)
end
it "calls Microsoft Teams API" do
chat_integration.execute(issues_sample_data)

2
spec/services/alert_management/create_alert_issue_service_spec.rb
View File

@ -81,7 +81,7 @@ RSpec.describe AlertManagement::CreateAlertIssueService do
it 'checks permissions' do
execute
expect(user).to have_received(:can?).with(:create_issue, project)
expect(user).to have_received(:can?).with(:create_issue, project).exactly(2).times
end
context 'with alert severity' do

27
spec/services/issues/create_service_spec.rb
View File

@ -6,7 +6,7 @@ RSpec.describe Issues::CreateService do
include AfterNextHelpers
let_it_be(:group) { create(:group, :crm_enabled) }
let_it_be_with_reload(:project) { create(:project, group: group) }
let_it_be_with_reload(:project) { create(:project, :public, group: group) }
let_it_be(:user) { create(:user) }
let(:spam_params) { double }
@ -34,7 +34,6 @@ RSpec.describe Issues::CreateService do
let(:opts) { { title: '' } }
before_all do
project.add_guest(user)
project.add_guest(assignee)
end
@ -63,6 +62,30 @@ RSpec.describe Issues::CreateService do
due_date: Date.tomorrow }
end
describe 'authorization' do
let_it_be(:project) { create(:project, :private, group: group).tap { |project| project.add_guest(user) } }
let(:opts) { { title: 'private issue', description: 'please fix' } }
context 'when the user is authorized' do
it 'allows the user to create an issue' do
expect(result).to be_success
expect(issue).to be_persisted
end
end
context 'when the user is not authorized' do
let(:user) { create(:user) }
it 'does not allow the user to create an issue' do
expect(result).to be_error
expect(result.errors).to contain_exactly('Operation not allowed')
expect(result.http_status).to eq(403)
expect(issue).to be_nil
end
end
end
it 'works if base work item types were not created yet' do
WorkItems::Type.delete_all

4
spec/support/shared_examples/models/chat_integration_shared_examples.rb
View File

@ -170,6 +170,10 @@ RSpec.shared_examples "chat integration" do |integration_name|
service.hook_data(issue, "open")
end
before do
project.add_developer(user)
end
it_behaves_like "triggered #{integration_name} integration"
end