diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-01-26 15:10:19 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-01-26 15:10:19 +0300 |
commit | a1c0b634f78f51389fd3ec390a1803afa3de49a2 (patch) | |
tree | f57fc3000a6e7f2bd271a63018427c8fb9c06c08 /doc | |
parent | db950c5706cdf47f7ccc2e02a4ffd691432ac5dc (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/.vale/gitlab/spelling-exceptions.txt | 3 | ||||
-rw-r--r-- | doc/administration/geo/replication/troubleshooting.md | 4 | ||||
-rw-r--r-- | doc/api/graphql/reference/index.md | 49 | ||||
-rw-r--r-- | doc/development/api_graphql_styleguide.md | 80 | ||||
-rw-r--r-- | doc/development/chaos_endpoints.md | 22 | ||||
-rw-r--r-- | doc/development/gitlab_flavored_markdown/specification_guide/index.md | 106 | ||||
-rw-r--r-- | doc/development/sidekiq/index.md | 12 | ||||
-rw-r--r-- | doc/security/token_overview.md | 17 | ||||
-rw-r--r-- | doc/update/zero_downtime.md | 4 | ||||
-rw-r--r-- | doc/user/group/saml_sso/index.md | 98 | ||||
-rw-r--r-- | doc/user/usage_quotas.md | 10 |
11 files changed, 256 insertions, 149 deletions
diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt index 2ffd42c9390..963c0d8a46d 100644 --- a/doc/.vale/gitlab/spelling-exceptions.txt +++ b/doc/.vale/gitlab/spelling-exceptions.txt @@ -786,6 +786,7 @@ requeued requeues requeuing resolver +resolver's Restlet resync resynced @@ -833,6 +834,7 @@ SBOMs sbt SBT scalers +scalar's scatterplot scatterplots schedulable @@ -1095,6 +1097,7 @@ unrevoke unsanitized unschedule unscoped +unsetting unshare unshared unshares diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index 46d146ac577..fe2ef8139ee 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -66,7 +66,7 @@ Checking Geo ... GitLab Geo is available ... yes GitLab Geo is enabled ... yes This machine's Geo node name matches a database record ... yes, found a secondary node named "Shanghai" -GitLab Geo secondary database is correctly configured ... yes +GitLab Geo tracking database is correctly configured ... yes Database replication enabled? ... yes Database replication working? ... yes GitLab Geo HTTP(S) connectivity ... @@ -339,7 +339,7 @@ sudo gitlab-rake gitlab:geo:check GitLab Geo is available ... yes GitLab Geo is enabled ... yes - GitLab Geo secondary database is correctly configured ... not a secondary node + GitLab Geo tracking database is correctly configured ... not a secondary node Database replication enabled? ... not a secondary node ... Checking Geo ... Finished diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md index 2bfdf0e9d7d..11f4ddac94c 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -97,6 +97,12 @@ This field returns a [connection](#connections). It accepts the four standard [pagination arguments](#connection-pagination-arguments): `before: String`, `after: String`, `first: Int`, `last: Int`. +#### Arguments + +| Name | Type | Description | +| ---- | ---- | ----------- | +| <a id="querycivariablessort"></a>`sort` | [`CiVariableSort`](#civariablesort) | Sort order of results. | + ### `Query.containerRepository` Find a container repository. @@ -13731,7 +13737,6 @@ GPG signature for a signed commit. | <a id="groupallowstalerunnerpruning"></a>`allowStaleRunnerPruning` | [`Boolean!`](#boolean) | Indicates whether to regularly prune stale group runners. Defaults to false. | | <a id="groupautodevopsenabled"></a>`autoDevopsEnabled` | [`Boolean`](#boolean) | Indicates whether Auto DevOps is enabled for all projects within this group. | | <a id="groupavatarurl"></a>`avatarUrl` | [`String`](#string) | Avatar URL of the group. | -| <a id="groupcivariables"></a>`ciVariables` | [`CiGroupVariableConnection`](#cigroupvariableconnection) | List of the group's CI/CD variables. (see [Connections](#connections)) | | <a id="groupcontainerrepositoriescount"></a>`containerRepositoriesCount` | [`Int!`](#int) | Number of container repositories in the group. | | <a id="groupcontainslockedprojects"></a>`containsLockedProjects` | [`Boolean!`](#boolean) | Includes at least one project where the repository size exceeds the limit. | | <a id="groupcrossprojectpipelineavailable"></a>`crossProjectPipelineAvailable` | [`Boolean!`](#boolean) | Indicates if the cross_project_pipeline feature is available for the namespace. | @@ -13825,6 +13830,22 @@ four standard [pagination arguments](#connection-pagination-arguments): | ---- | ---- | ----------- | | <a id="groupboardsid"></a>`id` | [`BoardID`](#boardid) | Find a board by its ID. | +##### `Group.ciVariables` + +List of the group's CI/CD variables. + +Returns [`CiGroupVariableConnection`](#cigroupvariableconnection). + +This field returns a [connection](#connections). It accepts the +four standard [pagination arguments](#connection-pagination-arguments): +`before: String`, `after: String`, `first: Int`, `last: Int`. + +###### Arguments + +| Name | Type | Description | +| ---- | ---- | ----------- | +| <a id="groupcivariablessort"></a>`sort` | [`CiVariableSort`](#civariablesort) | Sort order of results. | + ##### `Group.clusterAgents` Cluster agents associated with projects in the group and its subgroups. @@ -17417,7 +17438,6 @@ Represents a product analytics dashboard widget. | <a id="projectcicdsettings"></a>`ciCdSettings` | [`ProjectCiCdSetting`](#projectcicdsetting) | CI/CD settings for the project. | | <a id="projectciconfigpathordefault"></a>`ciConfigPathOrDefault` | [`String!`](#string) | Path of the CI configuration file. | | <a id="projectcijobtokenscope"></a>`ciJobTokenScope` | [`CiJobTokenScopeType`](#cijobtokenscopetype) | The CI Job Tokens scope of access. | -| <a id="projectcivariables"></a>`ciVariables` | [`CiProjectVariableConnection`](#ciprojectvariableconnection) | List of the project's CI/CD variables. (see [Connections](#connections)) | | <a id="projectcodecoveragesummary"></a>`codeCoverageSummary` | [`CodeCoverageSummary`](#codecoveragesummary) | Code coverage summary associated with the project. | | <a id="projectcomplianceframeworks"></a>`complianceFrameworks` | [`ComplianceFrameworkConnection`](#complianceframeworkconnection) | Compliance frameworks associated with the project. (see [Connections](#connections)) | | <a id="projectcontainerexpirationpolicy"></a>`containerExpirationPolicy` | [`ContainerExpirationPolicy`](#containerexpirationpolicy) | Container expiration policy of the project. | @@ -17647,6 +17667,22 @@ Returns [`CiTemplate`](#citemplate). | ---- | ---- | ----------- | | <a id="projectcitemplatename"></a>`name` | [`String!`](#string) | Name of the CI/CD template to search for. Template must be formatted as `Name.gitlab-ci.yml`. | +##### `Project.ciVariables` + +List of the project's CI/CD variables. + +Returns [`CiProjectVariableConnection`](#ciprojectvariableconnection). + +This field returns a [connection](#connections). It accepts the +four standard [pagination arguments](#connection-pagination-arguments): +`before: String`, `after: String`, `first: Int`, `last: Int`. + +###### Arguments + +| Name | Type | Description | +| ---- | ---- | ----------- | +| <a id="projectcivariablessort"></a>`sort` | [`CiVariableSort`](#civariablesort) | Sort order of results. | + ##### `Project.clusterAgent` Find a single cluster agent by name. @@ -21721,6 +21757,15 @@ Values for sorting runners. | <a id="cirunnerupgradestatusnot_available"></a>`NOT_AVAILABLE` | Upgrade is not available for the runner. | | <a id="cirunnerupgradestatusrecommended"></a>`RECOMMENDED` | Upgrade is available and recommended for the runner. | +### `CiVariableSort` + +Values for sorting variables. + +| Value | Description | +| ----- | ----------- | +| <a id="civariablesortkey_asc"></a>`KEY_ASC` | Sorted by key in ascending order. | +| <a id="civariablesortkey_desc"></a>`KEY_DESC` | Sorted by key in descending order. | + ### `CiVariableType` | Value | Description | diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index 6e5487c827f..0b47a7be7f2 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -32,7 +32,7 @@ with anyone who may work in this part of the codebase in the future. You can fin [Google Slides](https://docs.google.com/presentation/d/1qOTxpkTdHIp1CRjuTvO-aXg0_rUtzE3ETfLUdnBB5uQ/edit) and in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/8e78ea7f326b2ef649e7d7d569c26d56/GraphQL_Deep_Dive__Create_.pdf). Everything covered in this deep dive was accurate as of GitLab 11.9, and while specific -details may have changed since then, it should still serve as a good introduction. +details may have changed after that release, it should still serve as a good introduction. ## GraphiQL @@ -210,8 +210,8 @@ The `iid`, `title` and `description` are _scalar_ GraphQL types. `iid` is a `GraphQL::Types::ID`, a special string type that signifies a unique ID. `title` and `description` are regular `GraphQL::Types::String` types. -Note that the old scalar types `GraphQL:ID`, `GraphQL::INT_TYPE`, `GraphQL::STRING_TYPE`, -`GraphQL:BOOLEAN_TYPE`, and `GraphQL::FLOAT_TYPE` are no longer allowed. Please use `GraphQL::Types::ID`, +The old scalar types `GraphQL:ID`, `GraphQL::INT_TYPE`, `GraphQL::STRING_TYPE`, +`GraphQL:BOOLEAN_TYPE`, and `GraphQL::FLOAT_TYPE` are no longer allowed. Use `GraphQL::Types::ID`, `GraphQL::Types::Int`, `GraphQL::Types::String`, `GraphQL::Types::Boolean`, and `GraphQL::Types::Float`. When exposing a model through the GraphQL API, we do so by creating a @@ -250,7 +250,7 @@ the following reasons: - Changing from a non-nullable field to a nullable field is difficult with a versionless schema Non-nullable fields should only be used when a field is required, very unlikely -to become optional in the future, and very easy to calculate. An example would +to become optional in the future, and straightforward to calculate. An example would be `id` fields. A non-nullable GraphQL schema field is an object type followed by the exclamation point (bang) `!`. Here's an example from the `gitlab_schema.graphql` file: @@ -388,12 +388,12 @@ query($project_path: ID!) { ``` To ensure that we get consistent ordering, we append an ordering on the primary -key, in descending order. This is usually `id`, so we add `order(id: :desc)` +key, in descending order. The primary key is usually `id`, so we add `order(id: :desc)` to the end of the relation. A primary key _must_ be available on the underlying table. #### Shortcut fields -Sometimes it can seem easy to implement a "shortcut field", having the resolver return the first of a collection if no parameters are passed. +Sometimes it can seem straightforward to implement a "shortcut field", having the resolver return the first of a collection if no parameters are passed. These "shortcut fields" are discouraged because they create maintenance overhead. They need to be kept in sync with their canonical field, and deprecated or modified if their canonical field changes. Use the functionality the framework provides unless there is a compelling reason to do otherwise. @@ -692,7 +692,7 @@ Global IDs, so as such they are coupled to model names. When we rename a model, its Global ID changes. If the Global ID is used as an _argument_ type anywhere in the schema, then the Global ID -change would normally constitute a breaking change. +change would typically constitute a breaking change. To continue to support clients using the old Global ID argument, we add a deprecation to `Gitlab::GlobalId::Deprecations`. @@ -763,24 +763,24 @@ support for the former argument style, remove the `Deprecation`: DEPRECATIONS = [].freeze ``` -During the deprecation period the API will accept either of these formats for the argument value: +During the deprecation period, the API accepts either of these formats for the argument value: - `"gid://gitlab/PrometheusService/1"` - `"gid://gitlab/Integrations::Prometheus/1"` -The API will also accept these types in the query signature for the argument: +The API also accepts these types in the query signature for the argument: - `PrometheusServiceID` - `IntegrationsPrometheusID` NOTE: -Although queries that use the old type (`PrometheusServiceID` in this example) will be -considered valid and executable by the API, validator tools will consider them to be invalid. -This is because we are deprecating using a bespoke method outside of the +Although queries that use the old type (`PrometheusServiceID` in this example) are +considered valid and executable by the API, validator tools consider them to be invalid. +They are considered invalid because we are deprecating using a bespoke method outside of the [`@deprecated` directive](https://spec.graphql.org/June2018/#sec--deprecated), so validators are not aware of the support. -The documentation will mention that the old Global ID style is now deprecated. +The documentation mentions that the old Global ID style is now deprecated. ## Mark schema items as Alpha @@ -897,7 +897,7 @@ An example of the use of a union for this purpose is Field names can be mapped to hash data keys using the `hash_key:` keyword if needed. -For example, given the following simple JSON data: +For example, given the following JSON data: ```json { @@ -1054,7 +1054,7 @@ the objects in question. To find objects to display in a field, we can add resolvers to `app/graphql/resolvers`. -Arguments can be defined within the resolver in the same way as in a mutation. +Arguments can be defined in the resolver in the same way as in a mutation. See the [Mutation arguments](#object-identifier-arguments) section. To limit the amount of queries performed, we can use [BatchLoader](graphql_guide/batchloader.md). @@ -1098,7 +1098,7 @@ application: - Services in mutations to apply operations. - Loaders (batch-aware finders) specific to queries. -Note that there is never any reason to use batching in a mutation. Mutations are +There is never any reason to use batching in a mutation. Mutations are executed in series, so there are no batching opportunities. All values are evaluated eagerly as soon as they are requested, so batching is unnecessary overhead. If you are writing: @@ -1134,7 +1134,7 @@ the entire field should resolve to `null`. ### Deriving resolvers (`BaseResolver.single` and `BaseResolver.last`) -For some simple use cases, we can derive resolvers from others. +For some use cases, we can derive resolvers from others. The main use case for this is one resolver to find all items, and another to find one specific one. For this, we supply convenience methods: @@ -1179,7 +1179,7 @@ class JobsResolver < BaseResolver end ``` -Here we have a simple resolver for getting pipeline jobs. The `name` argument is +Here we have a resolver for getting pipeline jobs. The `name` argument is optional when getting a list, but required when getting a single job. If there are multiple arguments, and neither can be made required, we can use @@ -1327,7 +1327,7 @@ class MyThingResolver < BaseResolver end ``` -For an example of real world use, please +For an example of real world use, see [`ResolvesMergeRequests`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/graphql/resolvers/concerns/resolves_merge_requests.rb). ### Negated arguments @@ -1450,7 +1450,7 @@ It's acceptable to have both fine-grained mutations and coarse-grained mutations that too many fine-grained mutations can lead to organizational challenges in maintainability, code comprehensibility, and testing. Each mutation requires a new class, which can lead to technical debt. -It also means the schema becomes very big, and we want users to easily navigate our schema. +It also means the schema becomes very big, which can make it difficult for users to navigate our schema. As each new mutation also needs tests (including slower request integration tests), adding mutations slows down the test suite. @@ -1730,7 +1730,7 @@ two fields: `errors: [String]`, and `thing: ThingType`. The specific nature of the `thing` itself is irrelevant to these examples, as we are considering the errors. -There are three states a mutation response can be in: +The three states a mutation response can be in are: - [Success](#success) - [Failure (relevant to the user)](#failure-relevant-to-the-user) @@ -1776,11 +1776,11 @@ Examples of this include: - Model validation errors: the user may need to change the inputs. - Permission errors: the user needs to know they cannot do this, they may need to request permission or sign in. -- Problems with application state that prevent the user's action, for example: merge conflicts, the resource was locked, and so on. +- Problems with the application state that prevent the user's action (for example, merge conflicts or a locked resource). Ideally, we should prevent the user from getting this far, but if they do, they need to be told what is wrong, so they understand the reason for the failure and -what they can do to achieve their intent, even if that is as simple as retrying the +what they can do to achieve their intent. For example, they might only need to retry the request. It is possible to return *recoverable* errors alongside mutation data. For example, if @@ -1803,7 +1803,7 @@ In this case there is no `data`: } ``` -This is the result of raising an error during the mutation. In our implementation, +This results from raising an error during the mutation. In our implementation, the messages of argument errors and validation errors are returned to the client, and all other `StandardError` instances are caught, logged and presented to the client with the message set to `"Internal server error"`. See [`GraphqlController`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/graphql_controller.rb) for details. @@ -1832,7 +1832,7 @@ needs of the _user_ from the needs of the _client_. > _Never catch an error unless the user needs to know about it._ If the user does need to know about it, communicate with frontend developers -to make sure the error information we are passing back is useful. +to make sure the error information we are passing back is relevant and serves a purpose. See also the [frontend GraphQL guide](../development/fe_guide/graphql.md#handling-errors). @@ -1875,7 +1875,7 @@ process, read [merge request !42588](https://gitlab.com/gitlab-org/gitlab/-/merg We use subscriptions to push updates to clients. We use the [Action Cable implementation](https://graphql-ruby.org/subscriptions/action_cable_implementation) to deliver the messages over websockets. -When a client subscribes to a subscription, we store their query in-memory within Puma workers. Then when the subscription is triggered, +When a client subscribes to a subscription, we store their query in-memory in Puma workers. Then when the subscription is triggered, the Puma workers execute the stored GraphQL queries and push the results to the clients. NOTE: @@ -1897,7 +1897,7 @@ This class runs during the initial subscription request and subsequent updates. You should implement the `#authorized?` method of the subscription class so that the initial subscription and subsequent updates are authorized. When a user is not authorized, you should call the `unauthorized!` helper so that execution is halted and the user is unsubscribed. Returning `false` -results in redaction of the response but we leak information that some updates are happening. This is due to a +results in redaction of the response, but we leak information that some updates are happening. This leakage is due to a [bug in the GraphQL gem](https://github.com/rmosolgo/graphql-ruby/issues/3390). ### Triggering subscriptions @@ -1913,7 +1913,7 @@ To learn more, visit [GraphQL pagination](graphql_guide/pagination.md). For validations of single arguments, use the [`prepare` option](https://github.com/rmosolgo/graphql-ruby/blob/master/guides/fields/arguments.md) -as normal. +as usual. Sometimes a mutation or resolver may accept a number of optional arguments, but we still want to validate that at least one of the optional @@ -1969,8 +1969,8 @@ field :created_at, Types::TimeType, null: true, description: 'Timestamp of when ## Testing For testing mutations and resolvers, consider the unit of -test a full GraphQL request, not a call to a resolver. The reasons for this are -that we want to avoid lots of coupling to the framework, since this makes +test a full GraphQL request, not a call to a resolver. This allows us to +avoid tight coupling to the framework because such coupling makes upgrades to dependencies much more difficult. You should: @@ -2034,7 +2034,7 @@ When adding a query, you can use the `a working graphql query` shared example to renders valid results. You can construct a query including all available fields using the `GraphqlHelpers#all_graphql_fields_for` -helper. This makes it easy to add a test rendering all possible fields for a query. +helper. This makes it more straightforward to add a test rendering all possible fields for a query. If you're adding a field to a query that supports pagination and sorting, visit [Testing](graphql_guide/pagination.md#testing) for details. @@ -2176,11 +2176,11 @@ end `spec/requests/api/graphql/ci/pipeline_spec.rb` regardless of the query being used to fetch the pipeline data. -- There can be possible cyclic dependencies within our GraphQL types. +- There can be possible cyclic dependencies in our GraphQL types. See [Adding field with resolver on a Type causes "Can't determine the return type " error on a different Type](https://github.com/rmosolgo/graphql-ruby/issues/3974#issuecomment-1084444214) and [Fix unresolved name due to cyclic definition](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84202/diffs#diff-content-32d14251082fd45412e1fdbf5820e62d157e70d2). - In particular, this can happen with `connection_type`. Normally we might use the following in a resolver: + In particular, this can happen with `connection_type`. Typically we might use the following in a resolver: ```ruby type Types::IssueType.connection_type, null: true @@ -2226,8 +2226,8 @@ end type "Types::IssueConnection", null: true ``` - Only use this style if you are having spec failures. This is not intended to be a new - pattern that we use. This issue should disappear after we've upgraded to `2.x`. + Only use this style if you are having spec failures. We should not typically + use this pattern. This issue should disappear after we've upgraded to `2.x`. - There can be instances where a spec fails because the class is not loaded correctly. It relates to the @@ -2268,8 +2268,8 @@ end See [this merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87295#note_946174036) for some discussion. - Only use this style if you are having spec failures. This is not intended to be a new - pattern that we use. This issue may disappear after we've upgraded to `2.x`. + Only use this style if you are having spec failures. We should not typically use this pattern. + This issue may disappear after we've upgraded to `2.x`. - When testing resolvers using `GraphqlHelpers#resolve`, arguments for the resolver can be handled two ways. @@ -2299,8 +2299,8 @@ end ``` The use of `:internal_prepared` was added as a bridge for the - [GraphQL gem](https://graphql-ruby.org) upgrade. Testing resolvers directly will be - [removed eventually](https://gitlab.com/gitlab-org/gitlab/-/issues/363121), + [GraphQL gem](https://graphql-ruby.org) upgrade. Testing resolvers directly will + [eventually be removed](https://gitlab.com/gitlab-org/gitlab/-/issues/363121), and writing unit tests for resolvers/mutations is [already deprecated](#writing-unit-tests-deprecated) @@ -2341,7 +2341,7 @@ Queries and mutations are limited by depth, complexity, and recursion to protect server resources from overly ambitious or malicious queries. These values can be set as defaults and overridden in specific queries as needed. The complexity values can be set per object as well, and the final query complexity is -evaluated based on how many objects are being returned. This is useful +evaluated based on how many objects are being returned. This can be used for objects that are expensive (such as requiring Gitaly calls). For example, a conditional complexity method in a resolver: diff --git a/doc/development/chaos_endpoints.md b/doc/development/chaos_endpoints.md index 008c3700253..196ec14bffa 100644 --- a/doc/development/chaos_endpoints.md +++ b/doc/development/chaos_endpoints.md @@ -12,7 +12,7 @@ As [Werner Vogels](https://twitter.com/Werner), the CTO at Amazon Web Services, <!-- vale gitlab.Spelling = NO --> -As a developer, it's as important to consider the failure modes in which your software may operate as much as normal operation. Doing so can mean the difference between a minor hiccup leading to a scattering of `500` errors experienced by a tiny fraction of users, and a full site outage that affects all users for an extended period. +As a developer, it's as important to consider the failure modes in which your software may operate as much as typical operation. Doing so can mean the difference between a minor hiccup leading to a scattering of `500` errors experienced by a tiny fraction of users, and a full site outage that affects all users for an extended period. To paraphrase [Tolstoy](https://en.wikipedia.org/wiki/Anna_Karenina_principle), _all happy servers are alike, but all failing servers are failing in their own way_. Luckily, there are ways we can attempt to simulate these failure modes, and the chaos endpoints are tools for assisting in this process. @@ -65,8 +65,8 @@ GET /-/chaos/leakmem?memory_mb=1024&duration_s=50&async=true | Attribute | Type | Required | Description | | ------------ | ------- | -------- | ------------------------------------------------------------------------------------ | -| `memory_mb` | integer | no | How much memory, in MB, should be leaked. Defaults to 100MB. | -| `duration_s` | integer | no | Minimum duration_s, in seconds, that the memory should be retained. Defaults to 30s. | +| `memory_mb` | integer | no | How much memory, in MB, should be leaked. Defaults to 100 MB. | +| `duration_s` | integer | no | Minimum duration_s, in seconds, that the memory should be retained. Defaults to 30 s. | | `async` | boolean | no | Set to true to leak memory in a Sidekiq background worker process | ```shell @@ -79,7 +79,7 @@ curl "http://localhost:3000/-/chaos/leakmem?memory_mb=1024&duration_s=10&token=s This endpoint attempts to fully use a single core, at 100%, for the given period. -Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds). +Depending on your rack server setup, your request may timeout after a predetermined period (typically 60 seconds). ```plaintext GET /-/chaos/cpu_spin @@ -89,7 +89,7 @@ GET /-/chaos/cpu_spin?duration_s=50&async=true | Attribute | Type | Required | Description | | ------------ | ------- | -------- | --------------------------------------------------------------------- | -| `duration_s` | integer | no | Duration, in seconds, that the core is used. Defaults to 30s | +| `duration_s` | integer | no | Duration, in seconds, that the core is used. Defaults to 30 s | | `async` | boolean | no | Set to true to consume CPU in a Sidekiq background worker process | ```shell @@ -103,7 +103,7 @@ curl "http://localhost:3000/-/chaos/cpu_spin?duration_s=60&token=secret" This endpoint attempts to fully use a single core, and interleave it with DB request, for the given period. This endpoint can be used to model yielding execution to another threads when running concurrently. -Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds). +Depending on your rack server setup, your request may timeout after a predetermined period (typically 60 seconds). ```plaintext GET /-/chaos/db_spin @@ -113,8 +113,8 @@ GET /-/chaos/db_spin?duration_s=50&async=true | Attribute | Type | Required | Description | | ------------ | ------- | -------- | --------------------------------------------------------------------------- | -| `interval_s` | float | no | Interval, in seconds, for every DB request. Defaults to 1s | -| `duration_s` | integer | no | Duration, in seconds, that the core is used. Defaults to 30s | +| `interval_s` | float | no | Interval, in seconds, for every DB request. Defaults to 1 s | +| `duration_s` | integer | no | Duration, in seconds, that the core is used. Defaults to 30 s | | `async` | boolean | no | Set to true to perform the operation in a Sidekiq background worker process | ```shell @@ -137,7 +137,7 @@ GET /-/chaos/sleep?duration_s=50&async=true | Attribute | Type | Required | Description | | ------------ | ------- | -------- | ---------------------------------------------------------------------- | -| `duration_s` | integer | no | Duration, in seconds, that the request sleeps for. Defaults to 30s | +| `duration_s` | integer | no | Duration, in seconds, that the request sleeps for. Defaults to 30 s | | `async` | boolean | no | Set to true to sleep in a Sidekiq background worker process | ```shell @@ -170,7 +170,7 @@ curl "http://localhost:3000/-/chaos/kill?token=secret" ## Quit This endpoint simulates the unexpected death of a worker process using the `QUIT` signal. -Unlike `KILL`, the `QUIT` signal will also attempt to write a core dump. +Unlike `KILL`, the `QUIT` signal also attempts to write a core dump. See [core(5)](https://man7.org/linux/man-pages/man5/core.5.html) for more information. ```plaintext @@ -191,7 +191,7 @@ curl "http://localhost:3000/-/chaos/quit?token=secret" This endpoint triggers a GC run on the worker handling the request and returns its worker ID plus GC stats as JSON. This is mostly useful when running Puma in standalone mode, since -otherwise the worker handling the request will not be known upfront. +otherwise the worker handling the request cannot be known upfront. Endpoint: diff --git a/doc/development/gitlab_flavored_markdown/specification_guide/index.md b/doc/development/gitlab_flavored_markdown/specification_guide/index.md index 79a4ac9b49a..806ac3837bf 100644 --- a/doc/development/gitlab_flavored_markdown/specification_guide/index.md +++ b/doc/development/gitlab_flavored_markdown/specification_guide/index.md @@ -514,29 +514,30 @@ of how the normalizations are specified. 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 - GLFM, which meets these requirements: - 1. The spec is a strict superset of the GitHub Flavored Markdown +1. There is an official specification and single source of truth for how GLFM should render Markdown to HTML. + This source of truth is represented by three Markdown files: + 1. [`ghfm_spec_v_?.??.md`](#github-flavored-markdown-specification) for the CommonMark + GFM examples. + 1. [`glfm_official_specification.md`](#glfm_official_specificationmd) for the GLFM official examples. + 1. [`glfm_internal_extensions.md`](#glfm_internal_extensionsmd) for the GLFM internal extensions. +1. This official specification meets these requirements: + 1. The specification is a strict superset of the GitHub Flavored Markdown (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-). 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 specification](#github-flavored-markdown-specification). - 1. It contains new, extra sections for all the additional Markdown contained in the GLFM + 1. It contains sections and examples 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 + with [Markdown examples](#markdown-examples) and any accompanying prose, just like the CommonMark and GFM examples. + 1. All 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 support _consistent_ rendering of all canonical Markdown + HTML examples in the - GLFM `spec.txt` specification, as verified by `spec_tests.py`. + specification, as verified by [`run-spec-tests.sh`](#run-spec-testssh-script). NOTE: Consistent does not mean that both of these implementations render @@ -616,26 +617,41 @@ them from the corresponding implementation class entry point files under #### `update-specification.rb` script 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: +generate and update Markdown and HTML output files for the +[`spec.txt`](#spectxt) and [`spec.html`](#spechtml) +[output specification files](#output-specification-files) as well as the +[`snapshot_spec.md`](#snapshot_specmd) and [`snapshot_spec.html`](#snapshot_spechtml) +[output example snapshot files](#output-example-snapshot-files). + +The HTML files are created by passing the generated (or updated) Markdown to the backend API +for rendering to HTML. + +```mermaid +graph LR +subgraph script: + S{update-specification.rb} +end +subgraph input - markdown files + I1[glfm_official_specification.md - GLFM official specification examples] --> S +end +subgraph output - specification files + S --> O1[spec.txt - GLFM official specification examples] + S --> O2[spec.html - GLFM official specification examples] +end +``` ```mermaid graph LR subgraph script: - A{update-specification.rb} - A --> B{Backend Markdown API} + S{update-specification.rb} end -subgraph input:<br/>input specification files - C[ghfm_spec_v_0.29.md] --> A - D[glfm_intro.md] --> A - E[glfm_official_specification.md] --> A - F[glfm_internal_extensions.md] --> A +subgraph input - markdown files + I1[ghfm_spec_v_0.29.md - CommonMark and GHFM specification examples] --> S + I2[glfm_internal_extensions.md - GLFM internal extension examples] --> S end -subgraph output:<br/>GLFM specification files - A --> G[spec.txt] - G --> B - B --> H[spec.html] +subgraph output - example snapshot files + S --> O1[snapshot_spec.md - CommonMark, GHFM, GLFM internal extension examples] + S --> O2[snapshot_spec.html - CommonMark, GHFM, GLFM internal extension examples] end ``` @@ -655,7 +671,8 @@ script, which expects canonical HTML, against the GitLab renderer implementation `scripts/glfm/run-spec-tests.sh` is a convenience shell script which runs conformance specs via the CommonMark standard `spec_tests.py` script, -which uses the `glfm_specification/output_spec/spec.txt` file and `scripts/glfm/canonicalize-html.rb` +which uses the `ghfm_spec_v_0.29.md` and `glfm_specification/output_spec/spec.txt` files +with the `scripts/glfm/canonicalize-html.rb` helper script to test the GLFM renderer implementations' support for rendering Markdown specification examples to canonical HTML. @@ -669,7 +686,8 @@ subgraph scripts: end end subgraph input - D[spec.txt GLFM specification] --> C + D1[ghfm_spec_v_0.29.md GLFM specification] --> C + D2[spec.txt GLFM specification] --> C E((GLFM static<br/>renderer implementation)) --> B F((GLFM WYSIWYG<br/>renderer implementation)) --> B end @@ -680,22 +698,28 @@ end #### `update-example-snapshots.rb` script -The `scripts/glfm/update-example-snapshots.rb` script uses the GLFM -`glfm_specification/output_spec/spec.txt` specification file and the -`glfm_specification/input/gitlab_flavored_markdown/glfm_example_status.yml` -file to create and update the [example snapshot](#output-example-snapshot-files) -YAML files: +The `scripts/glfm/update-example-snapshots.rb` script creates and updates the +[example snapshot](#output-example-snapshot-files) YAML files. + +Its inputs are: + +- The `glfm_specification/output_spec/snapshot_spec.md` file, which contains the + superset of all CommonMark, GFM, and GLFM official and internal examples. +- The `glfm_specification/input/gitlab_flavored_markdown/glfm_example_*.yml` YAML files, which + contain metadata to control how to generate the example snapshot files. ```mermaid graph LR subgraph script: A{update-example-snapshots.rb} end -subgraph input:<br/>input specification file - B[spec.txt] --> A - C[glfm_example_status.yml] --> A +subgraph input: markdown input specification files + B1[snapshot_spec.md] --> A + C1[glfm_example_status.yml] --> A + C2[glfm_example_normalizations.yml] --> A + C3[glfm_example_metadata.yml] --> A end -subgraph output:<br/>example snapshot files +subgraph output: YAML example snapshot files A --> E[examples_index.yml] A --> F[markdown.yml] A --> G[html.yml] @@ -736,15 +760,15 @@ end subgraph script: A{run-snapshopt-tests.sh} -->|invokes| B end +subgraph output:<br/>test results/output + B --> H[rspec+jest output] +end subgraph input:<br/>YAML C[examples_index.yml] --> B D[markdown.yml] --> B E[html.yml] --> B F[prosemirror_json.yml] --> B end -subgraph output:<br/>test results/output - B --> H[rspec+jest output] -end ``` #### `verify-all-generated-files-are-up-to-date.rb` script @@ -1111,8 +1135,12 @@ move or copy a hosted version of the rendered HTML `spec.html` version to anothe is a Markdown specification file, in the standard format with prose and Markdown + canonical HTML examples. +In the GLFM specification, `spex.txt` only contains the official specifiaction examples from +[`glfm_official_specification.md`](#glfm_official_specificationmd). It does not contain +the internal extension examples from [`glfm_internal_extensions.md`](#glfm_internal_extensionsmd). + It also serves as input for other scripts such as -`run-spec-tests.sh`. +[`run-spec-tests.sh`](#run-spec-testssh-script). It is generated or updated by the `update-specification.rb` script, using the [input specification files](#input-specification-files) as input. diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md index f4f98641d39..565317c4939 100644 --- a/doc/development/sidekiq/index.md +++ b/doc/development/sidekiq/index.md @@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Sidekiq guides We use [Sidekiq](https://github.com/mperham/sidekiq) as our background -job processor. These guides are for writing jobs that will work well on +job processor. These guides are for writing jobs that works well on GitLab.com and be consistent with our existing worker classes. For information on administering GitLab, see [configuring Sidekiq](../../administration/sidekiq/index.md). @@ -74,7 +74,7 @@ A lower retry count may be applicable if any of the below apply: 1. The worker is not idempotent and running it multiple times could leave the system in an inconsistent state. For example, a worker that posts a system note and then performs an action: if the second step - fails and the worker retries, the system note will be posted again. + fails and the worker retries, the system note is posted again. 1. The worker is a cronjob that runs frequently. For example, if a cron job runs every hour, then we don't need to retry beyond an hour because we don't need two of the same job running at once. @@ -156,7 +156,7 @@ queues in a namespace (technically: all queues prefixed with the namespace name) when a namespace is provided instead of a simple queue name in the `--queue` (`-q`) option, or in the `:queues:` section in `config/sidekiq_queues.yml`. -Note that adding a worker to an existing namespace should be done with care, as +Adding a worker to an existing namespace should be done with care, as the extra jobs take resources away from jobs from workers that were already there, if the resources available to the Sidekiq process handling the namespace are not adjusted appropriately. @@ -195,9 +195,9 @@ can read the number or type of provided arguments. GitLab stores Sidekiq jobs and their arguments in Redis. To avoid excessive memory usage, we compress the arguments of Sidekiq jobs -if their original size is bigger than 100KB. +if their original size is bigger than 100 KB. -After compression, if their size still exceeds 5MB, it raises an +After compression, if their size still exceeds 5 MB, it raises an [`ExceedLimitError`](https://gitlab.com/gitlab-org/gitlab/-/blob/f3dd89e5e510ea04b43ffdcb58587d8f78a8d77c/lib/gitlab/sidekiq_middleware/size_limiter/exceed_limit_error.rb#L8) error when scheduling the job. @@ -227,6 +227,6 @@ tests should be placed in `spec/workers`. ## Interacting with Sidekiq Redis and APIs -The application should minimise interaction with of any `Sidekiq.redis` and Sidekiq [APIs](https://github.com/mperham/sidekiq/blob/main/lib/sidekiq/api.rb). Such interactions in generic application logic should be abstracted to a [Sidekiq middleware](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/sidekiq_middleware) for re-use across teams. By decoupling application logic from Sidekiq's datastore, it allows for greater freedom when horizontally scaling the GitLab background processing setup. +The application should minimise interaction with of any `Sidekiq.redis` and Sidekiq [APIs](https://github.com/mperham/sidekiq/blob/main/lib/sidekiq/api.rb). Such interactions in generic application logic should be abstracted to a [Sidekiq middleware](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/sidekiq_middleware) for re-use across teams. By decoupling application logic from Sidekiq datastore, it allows for greater freedom when horizontally scaling the GitLab background processing setup. Some exceptions to this rule would be migration-related logic or administration operations. diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md index 470fdba3aef..a36d72f128d 100644 --- a/doc/security/token_overview.md +++ b/doc/security/token_overview.md @@ -107,6 +107,23 @@ triggering the job. The job token is secured by its short life-time and limited scope. It could possibly be leaked if multiple jobs run on the same machine ([like with the shell runner](https://docs.gitlab.com/runner/security/#usage-of-shell-executor)). On Docker Machine runners, configuring [`MaxBuilds=1`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersmachine-section) is recommended to make sure runner machines only ever run one build and are destroyed afterwards. This may impact performance, as provisioning machines takes some time. +## Other tokens + +### Feed token + +Each user has a long-lived feed token that does not expire. This token allows authentication for: + +- RSS readers to load a personalized RSS feed. +- Calendar applications to load a personalized calendar. + +This token is visible in those feed URLs. You cannot use this token to access any other data. + +Anyone who has your token can read activity and issue RSS feeds or your calendar feed as if they were you, including confidential issues. If that happens, [reset the token](../user/profile/contributions_calendar.md#reset-the-user-activity-feed-token). + +### Incoming email token + +Each user has a long-lived incoming email token that does not expire. This token allows a user to [create a new issue by email](../user/project/issues/create_issues.md#by-sending-an-email), and is included in that user's personal project-specific email addresses. You cannot use this token to access any other data. Anyone who has your token can create issues and merge requests as if they were you. If that happens, reset the token. + ## Available scopes This table shows available scopes per token. Scopes can be limited further on token creation. diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md index a849033c3e5..bb5cd195e5d 100644 --- a/doc/update/zero_downtime.md +++ b/doc/update/zero_downtime.md @@ -636,7 +636,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate ``` -1. If this deploy node is normally used to serve requests or process jobs, +1. If this deploy node is used to serve requests or process jobs, then you may return it to service at this point. - To serve requests, add the deploy node to the load balancer. @@ -706,7 +706,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo ``` -1. If this deploy node is normally used to serve requests or perform +1. If this deploy node is used to serve requests or perform background processing, then you may return it to service at this point. - To serve requests, add the deploy node to the load balancer. diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md index fcb02e76095..89536269305 100644 --- a/doc/user/group/saml_sso/index.md +++ b/doc/user/group/saml_sso/index.md @@ -121,34 +121,39 @@ It can also help to compare the XML response from your provider with our [exampl > - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9152) in GitLab 13.11 with enforcing open SSO session to use Git if this setting is switched on. > - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/339888) in GitLab 14.7 to not enforce SSO checks for Git activity originating from CI/CD jobs. > - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/215155) in GitLab 15.5 [with a flag](../../../administration/feature_flags.md) named `transparent_sso_enforcement` to include transparent enforcement even when SSO enforcement is not enabled. Disabled on GitLab.com. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/375788) in GitLab 15.8 by enabling transparent SSO by default on GitLab.com. FLAG: -On self-managed GitLab, transparent SSO enforcement is unavailable. On GitLab.com, see the [Transparent SSO rollout](https://gitlab.com/gitlab-org/gitlab/-/issues/375788) issue for the current status. +On self-managed GitLab, transparent SSO enforcement is unavailable. An +[issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/382917) to add +transparent SSO enforcement to self-managed GitLab. +On GitLab.com, transparent SSO enforcement is available by default. To turn off +transparent SSO, ask a support or production team to enable the +`transparent_sso_enforcement_override` feature flag for a specific customer +group. -SSO is enforced when users access groups and projects in the organization's group hierarchy. Users can view other groups and projects without SSO sign in. +#### Transparent SSO enforcement -SSO is enforced for each user with an existing SAML identity when the following is enabled: +By default, transparent SSO enforcement is enabled in GitLab.com. This means SSO is enforced: -- SAML SSO. -- The `:transparent_sso_enforcement` feature flag. +- When users access groups and projects in the organization's + group hierarchy. Users can view other groups and projects without SSO sign in. +- For each user with an existing SAML identity. + +When transparent SSO enforcement is enabled, users: + +- Are not prompted to sign in through SSO on each visit. GitLab checks + whether a user has authenticated through SSO. If the user last signed in more + than 24 hours ago, GitLab prompts the user to sign in again through SSO. +- Without SAML identities are not required to use SSO unless **Enforce + SSO-only authentication for web activity for this group** is enabled. A user has a SAML identity if one or both of the following are true: - They have signed in to GitLab by using their GitLab group's single sign-on URL. - They were provisioned by SCIM. -Users without SAML identities are not required to use SSO unless explicit enforcement is enabled. - -When the **Enforce SSO-only authentication for web activity for this group** option is enabled, all users must access GitLab by using their GitLab group's single sign-on URL to access group resources, -regardless of whether they have an existing SAML identity. -Users also cannot be added as new members manually. -Users with the Owner role can use the standard sign in process to make necessary changes to top-level group settings. - -However, users are not prompted to sign in through SSO on each visit. GitLab checks whether a user -has authenticated through SSO. If it's been more than 1 day since the last sign-in, GitLab -prompts the user to sign in again through SSO. - -When the transparent SSO enforcement feature flag is enabled, SSO is enforced as follows: +With transparent SSO enabled, SSO is enforced as follows: | Project/Group visibility | Enforce SSO setting | Member with identity | Member without identity | Non-member or not signed in | |--------------------------|---------------------|--------------------| ------ |------------------------------| @@ -157,36 +162,45 @@ When the transparent SSO enforcement feature flag is enabled, SSO is enforced as | Public | Off | Enforced | Not enforced | Not enforced | | Public | On | Enforced | Enforced | Not enforced | -An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/297389) to add a similar SSO requirement for API and GitLab Pages activities. - -SSO enforcement has the following effects when enabled: +An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/297389) to add a similar SSO requirement for API activity. -- For groups, users can't share a project in the group outside the top-level group, - even if the project is forked. -- For Git activity over SSH and HTTPS, users must have at least one active session signed-in through SSO before they can push to or - pull from a GitLab repository. -- Git activity originating from CI/CD jobs do not have the SSO check enforced. -- Credentials that are not tied to regular users (for example, project and group access tokens, and deploy keys) do not have the SSO check enforced. -- Users must be signed-in through SSO before they can pull images using the [Dependency Proxy](../../packages/dependency_proxy/index.md). -- When the **Enforce SSO-only authentication for Git and Dependency Proxy activity for this group** option is enabled, any API endpoint that involves Git activity is under SSO - enforcement. For example, creating or deleting a branch, commit, or tag. - -When SSO is enforced, users are not immediately revoked. If the user: +#### SSO-only for web activity enforcement -- Is signed out, they cannot access the group after being removed from the identity provider. -- Has an active session, they can continue accessing the group for up to 24 hours until the identity - provider session times out. +When the **Enforce SSO-only authentication for web activity for this group** option is enabled: -### Selectively enable and disable transparent SSO enforcement +- All users must access GitLab by using their GitLab group's single sign-on URL + to access group resources, regardless of whether they have an existing SAML + identity. +- SSO is enforced when users access groups and projects in the organization's + group hierarchy. Users can view other groups and projects without SSO sign in. +- Users cannot be added as new members manually. +- Users with the Owner role can use the standard sign in process to make + necessary changes to top-level group settings. -There are two feature flags associated with this feature to allow precise control. If a customer has a problem with transparent SSO on GitLab.com, GitLab can help troubleshoot and override the feature flag as necessary. +SSO enforcement for web activity has the following effects when enabled: -**`transparent_sso_enforcement`:** This feature flag should only be enabled or disabled by the Authentication and Authorization group -or in the case of a serious and widespread issue affecting many groups or users. See [issue 375788](https://gitlab.com/gitlab-org/gitlab/-/issues/375788) for the current GitLab.com rollout status. - -**`transparent_sso_enforcement_override`:** When the `transparent_sso_enforcement` feature flag is enabled, support or production teams can -turn off transparent SSO by enabling this feature flag for a specific customer group. **Enabling** this feature flag -disables transparent SSO enforcement. +- For groups, users cannot share a project in the group outside the top-level + group, even if the project is forked. +- For Git activity over SSH and HTTPS, users must have at least one active + session signed-in through SSO before they can push to or + pull from a GitLab repository. +- Git activity originating from CI/CD jobs do not have the SSO check enforced. +- Credentials that are not tied to regular users (for example, project and group + access tokens, and deploy keys) do not have the SSO check enforced. +- Users must be signed-in through SSO before they can pull images using the + [Dependency Proxy](../../packages/dependency_proxy/index.md). +- When the **Enforce SSO-only authentication for Git and Dependency Proxy + activity for this group** option is enabled, any API endpoint that involves + Git activity is under SSO enforcement. For example, creating or deleting a + branch, commit, or tag. + +When SSO for web activity is enforced, non-SSO group members do not lose access +immediately. If the user: + +- Has an active session, they can continue accessing the group for up to 24 + hours until the identity provider session times out. +- Is signed out, they cannot access the group after being removed from the + identity provider. ## Providers diff --git a/doc/user/usage_quotas.md b/doc/user/usage_quotas.md index c6c27f36618..18eac74cd96 100644 --- a/doc/user/usage_quotas.md +++ b/doc/user/usage_quotas.md @@ -66,8 +66,8 @@ Depending on your role, to manage your transfer usage you can [reduce Container ## Project storage limit -Projects on GitLab SaaS have a 10GB storage limit on their Git repository and LFS storage. -After namespace-level storage limits are applied, the project limit will be removed. A namespace has either a namespace-level storage limit or a project-level storage limit, but not both. +Projects on GitLab SaaS have a 10 GB storage limit on their Git repository and LFS storage. +After namespace-level storage limits are applied, the project limit is removed. A namespace has either a namespace-level storage limit or a project-level storage limit, but not both. When a project's repository and LFS reaches the quota, the project is locked. You cannot push changes to a locked project. To monitor the size of each @@ -122,7 +122,7 @@ available decreases. All projects remain unlocked because 40 GB purchased storag ## Namespace storage limit Namespaces on GitLab SaaS have a storage limit. For more information, see our [pricing page](https://about.gitlab.com/pricing/). -This limit is not visible on the **Usage quotas** page, but will be prior to the limit being [applied](#namespace-storage-limit-application-schedule). Self-managed deployments are not affected. +This limit is not visible on the **Usage quotas** page, but is prior to the limit being [applied](#namespace-storage-limit-application-schedule). Self-managed deployments are not affected. Storage types that add to the total namespace storage are: @@ -142,10 +142,10 @@ To prevent exceeding the namespace storage quota, you can: - Reduce storage consumption by following the suggestions in the [Manage Your Storage Usage](#manage-your-storage-usage) section of this page. - Apply for [GitLab for Education](https://about.gitlab.com/solutions/education/join/), [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/join/), or [GitLab for Startups](https://about.gitlab.com/solutions/startups/) if you meet the eligibility requirements. - Consider using a [self-managed instance](../subscriptions/self_managed/index.md) of GitLab which does not have these limits on the free tier. -- [Purchase additional storage](../subscriptions/gitlab_com/index.md#purchase-more-storage-and-transfer) units at $60/year for 10GB of storage. +- [Purchase additional storage](../subscriptions/gitlab_com/index.md#purchase-more-storage-and-transfer) units at $60/year for 10 GB of storage. - [Start a trial](https://about.gitlab.com/free-trial/) or [upgrade to GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) which include higher limits and features that enable growing teams to ship faster without sacrificing on quality. - [Talk to an expert](https://page.gitlab.com/usage_limits_help.html) to learn more about your options and ask questions. ### Namespace storage limit application schedule -Information on when namespace-level storage limits will be applied is available on these FAQ pages for the [Free](https://about.gitlab.com/pricing/faq-efficient-free-tier/#storage-limits-on-gitlab-saas-free-tier) and [Paid](https://about.gitlab.com/pricing/faq-paid-storage-transfer/) tier. +Information on when namespace-level storage limits are applied is available on these FAQ pages for the [Free](https://about.gitlab.com/pricing/faq-efficient-free-tier/#storage-limits-on-gitlab-saas-free-tier) and [Paid](https://about.gitlab.com/pricing/faq-paid-storage-transfer/) tier. |