Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
aa04de2d2b
commit
1b9f574b89
|
@ -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
|
||||
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
|
@ -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
|
|
@ -0,0 +1 @@
|
|||
477f7b75c7d9b162add500924e5bbd9240ef76f3c56851748af8c6a59d912b7e
|
|
@ -0,0 +1 @@
|
|||
531758adf94d39b646e47601989f5f969eda8e9cbc2b2d6285826f9704575d3d
|
|
@ -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);
|
||||
|
||||
|
|
|
@ -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). |
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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**.
|
||||
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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
|
|
@ -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)
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
Loading…
Reference in New Issue