diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/administration/nfs.md | 20 | ||||
| -rw-r--r-- | doc/development/api_graphql_styleguide.md | 26 | ||||
| -rw-r--r-- | doc/development/code_review.md | 4 | ||||
| -rw-r--r-- | doc/development/documentation/structure.md | 2 | ||||
| -rw-r--r-- | doc/development/snowplow.md | 2 | ||||
| -rw-r--r-- | doc/operations/incident_management/incidents.md | 2 | ||||
| -rw-r--r-- | doc/user/discussions/index.md | 2 | ||||
| -rw-r--r-- | doc/user/group/saml_sso/index.md | 11 | ||||
| -rw-r--r-- | doc/user/project/issues/confidential_issues.md | 2 | ||||
| -rw-r--r-- | doc/user/project/pages/introduction.md | 2 |
10 files changed, 64 insertions, 9 deletions
diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md index 7c80a2a3fe7..d04a86ab4c6 100644 --- a/doc/administration/nfs.md +++ b/doc/administration/nfs.md @@ -189,6 +189,7 @@ Note there are several options that you should consider using: | `nofail` | Don't halt boot process waiting for this mount to become available | `lookupcache=positive` | Tells the NFS client to honor `positive` cache results but invalidates any `negative` cache results. Negative cache results cause problems with Git. Specifically, a `git push` can fail to register uniformly across all NFS clients. The negative cache causes the clients to 'remember' that the files did not exist previously. | `hard` | Instead of `soft`. [Further details](#soft-mount-option). +| `cto` | `cto` is the default option, which you should use. Do not use `nocto`. [Further details](#nocto-mount-option). #### `soft` mount option @@ -225,6 +226,25 @@ the mount point. Use `SIGKILL` (`kill -9`) to deal with hung processes. The `intr` option [stopped working in the 2.6 kernel](https://access.redhat.com/solutions/157873). +#### `nocto` mount option + +Do not use `nocto`. Instead, use `cto`, which is the default. + +When using `nocto`, the dentry cache is always used, up to `acdirmax` seconds (attribute cache time) from the time it's created. + +This results in stale dentry cache issues with multiple clients, where each client can see a different (cached) +version of a directory. + +From the [Linux man page](https://linux.die.net/man/5/nfs), the important parts: + +> If the nocto option is specified, the client uses a non-standard heuristic to determine when files on the server have changed. +> +> Using the nocto option may improve performance for read-only mounts, but should be used only if the data on the server changes only occasionally. + +We have noticed this behavior in an issue about [refs not found after a push](https://gitlab.com/gitlab-org/gitaly/-/issues/2589), +where newly added loose refs can be seen as missing on a different client with a local dentry cache, as +[described in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/326066#note_539436931). + ### A single NFS mount It's recommended to nest all GitLab data directories within a mount, that allows automatic diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index 8bac02c99af..7e4e7007ca2 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -392,6 +392,28 @@ field :blob, type: Types::Snippets::BlobType, This will increment the [`complexity` score](#field-complexity) of the field by `1`. +If a resolver calls Gitaly, it can be annotated with +`BaseResolver.calls_gitaly!`. This passes `calls_gitaly: true` to any +field that uses this resolver. + +For example: + +```ruby +class BranchResolver < BaseResolver + type ::Types::BranchType, null: true + calls_gitaly! + + argument name: ::GraphQL::STRING_TYPE, required: true + + def resolve(name:) + object.branch(name) + end +end +``` + +Then when we use it, any field that uses `BranchResolver` has the correct +value for `calls_gitaly:`. + ### Exposing permissions for a type To expose permissions the current user has on a resource, you can call @@ -1137,9 +1159,10 @@ When using resolvers, they can and should serve as the SSoT for field metadata. All field options (apart from the field name) can be declared on the resolver. These include: -- `type` (this is particularly important, and is planned to be mandatory) +- `type` (required - all resolvers must include a type annotation) - `extras` - `description` +- Gitaly annotations (with `calls_gitaly!`) Example: @@ -1149,6 +1172,7 @@ module Resolvers type Types::MyType, null: true extras [:lookahead] description 'Retrieve a single MyType' + calls_gitaly! end end ``` diff --git a/doc/development/code_review.md b/doc/development/code_review.md index f354d7ccbe9..03ebd333e28 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -252,7 +252,7 @@ After merging, a maintainer should stay as the reviewer listed on the merge requ ### Dogfooding the Reviewers feature -In March 18th 2021, an updated process was put in place aimed at efficiently and consistently dogfooding the Reviewers feature. +On March 18th 2021, an updated process was put in place aimed at efficiently and consistently dogfooding the Reviewers feature. Here is a summary of the changes, also reflected in this section above. @@ -409,6 +409,8 @@ When ready to merge: - **Start a new merge request pipeline with the `Run Pipeline` button in the merge request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).** Note that: - If **[master is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master), + do not merge the merge request** except for + [very specific cases](https://about.gitlab.com/handbook/engineering/workflow/#criteria-for-merging-during-broken-master). For other cases, follow these [handbook instructions](https://about.gitlab.com/handbook/engineering/workflow/#merging-during-broken-master). - If the **latest [Pipeline for Merged Results](../ci/merge_request_pipelines/pipelines_for_merged_results/#pipelines-for-merged-results)** finished less than 2 hours ago, you might merge without starting a new pipeline as the merge request is close diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md index 8d564078ea2..33bfc040bb6 100644 --- a/doc/development/documentation/structure.md +++ b/doc/development/documentation/structure.md @@ -113,7 +113,7 @@ To create an issue: 1. Go to **Issues > List**. 1. In the top right, click **New issue**. 1. Complete the fields. (If you have a reference topic that lists each field, link to it here.) -1. Click **Submit issue**. +1. Click **Create issue**. The issue is created. You can view it by going to **Issues > List**. ``` diff --git a/doc/development/snowplow.md b/doc/development/snowplow.md index 3d566100677..720e2853851 100644 --- a/doc/development/snowplow.md +++ b/doc/development/snowplow.md @@ -314,6 +314,7 @@ Custom event tracking and instrumentation can be added by directly calling the ` | `project` | Project | nil | The project associated with the event. | | `user` | User | nil | The user associated with the event. | | `namespace` | Namespace | nil | The namespace associated with the event. | +| `extra` | Hash | `{}` | Additional keyword arguments are collected into a hash and sent with the event. | Tracking can be viewed as either tracking user behavior, or can be used for instrumentation to monitor and visualize performance over time in an area or aspect of code. @@ -495,6 +496,7 @@ The [`StandardContext`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/g | `namespace_id` | **{dotted-circle}** | integer | | | `environment` | **{check-circle}** | string (max 32 chars) | Name of the source environment, such as `production` or `staging` | | `source` | **{check-circle}** | string (max 32 chars) | Name of the source application, such as `gitlab-rails` or `gitlab-javascript` | +| `extra` | **{dotted-circle}** | JSON | Any additional data associated with the event, in the form of key-value pairs | ### Default Schema diff --git a/doc/operations/incident_management/incidents.md b/doc/operations/incident_management/incidents.md index e4d9a87e39d..078a1a0be08 100644 --- a/doc/operations/incident_management/incidents.md +++ b/doc/operations/incident_management/incidents.md @@ -39,7 +39,7 @@ Incident, you have two options to do this manually. 1. Go to **Issues > List**, and select **New issue**. 1. In the **Type** dropdown, select **Incident**. Only fields relevant to incidents are displayed on the page. -1. Create the incident as needed, and select **Submit issue** to save the +1. Create the incident as needed, and select **Create issue** to save the incident.  diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md index 9020c6e0b91..f622d075ba4 100644 --- a/doc/user/discussions/index.md +++ b/doc/user/discussions/index.md @@ -119,7 +119,7 @@ the unresolved threads.  -Hitting **Submit issue** causes all threads to be marked as resolved and +Hitting **Create issue** causes all threads to be marked as resolved and add a note referring to the newly created issue.  diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md index 6078de0f9e1..da7e9828d48 100644 --- a/doc/user/group/saml_sso/index.md +++ b/doc/user/group/saml_sso/index.md @@ -95,6 +95,7 @@ Please note that the certificate [fingerprint algorithm](../../../integration/sa - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9255) in GitLab 11.11 with ongoing enforcement in the GitLab UI. - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience. - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO. +- [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. With this option enabled, users must go through your group's GitLab single sign-on URL if they wish to access group resources through the UI. Users can't be manually added as members. @@ -104,9 +105,15 @@ However, users are not prompted to sign in through SSO on each visit. GitLab che 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. -We intend to add a similar SSO requirement for [Git and API activity](https://gitlab.com/gitlab-org/gitlab/-/issues/9152). +We intend to add a similar SSO requirement for [API activity](https://gitlab.com/gitlab-org/gitlab/-/issues/9152). -When SSO enforcement is enabled for a group, users can't share a project in the group outside the top-level group, even if the project is forked. +SSO has the following effects when enabled: + +- For groups, users can't share a project in the group outside the top-level group, + even if the project is forked. +- For a Git activity, users must be signed-in through SSO before they can push to or + pull from a GitLab repository. +<!-- Add bullet for API activity when https://gitlab.com/gitlab-org/gitlab/-/issues/9152 is complete --> ## Providers diff --git a/doc/user/project/issues/confidential_issues.md b/doc/user/project/issues/confidential_issues.md index e1918b68ddc..25357a1db0b 100644 --- a/doc/user/project/issues/confidential_issues.md +++ b/doc/user/project/issues/confidential_issues.md @@ -19,7 +19,7 @@ You can make an issue confidential during issue creation or by editing an existing one. When you create a new issue, a checkbox right below the text area is available -to mark the issue as confidential. Check that box and hit the **Submit issue** +to mark the issue as confidential. Check that box and hit the **Create issue** button to create the issue. For existing issues, edit them, check the confidential checkbox and hit **Save changes**. diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md index 277238bfc98..3c3de26d7dd 100644 --- a/doc/user/project/pages/introduction.md +++ b/doc/user/project/pages/introduction.md @@ -295,5 +295,5 @@ The contents of the public directory can be confirmed by [browsing the artifacts Files listed under the public directory can be accessed through the Pages URL for the project. A 404 can also be related to incorrect permissions. If [Pages Access Control](pages_access_control.md) is enabled, and a user -navigates to the Pages URL and receives a 404 reponse, it is possible that the user does not have permission to view the site. +navigates to the Pages URL and receives a 404 response, it is possible that the user does not have permission to view the site. To fix this, verify that the user is a member of the project. |