diff options
155 files changed, 604 insertions, 354 deletions
diff --git a/.rubocop_todo/rspec/return_from_stub.yml b/.rubocop_todo/rspec/return_from_stub.yml index 898bd367ada..99da72936c6 100644 --- a/.rubocop_todo/rspec/return_from_stub.yml +++ b/.rubocop_todo/rspec/return_from_stub.yml @@ -2,25 +2,6 @@ # Cop supports --autocorrect. RSpec/ReturnFromStub: Exclude: - - 'ee/spec/controllers/admin/geo/nodes_controller_spec.rb' - - 'ee/spec/controllers/groups/billings_controller_spec.rb' - - 'ee/spec/controllers/groups/group_members_controller_spec.rb' - - 'ee/spec/controllers/profiles/billings_controller_spec.rb' - - 'ee/spec/controllers/projects/branches_controller_spec.rb' - - 'ee/spec/features/account_recovery_regular_check_spec.rb' - - 'ee/spec/features/admin/groups/admin_changes_plan_spec.rb' - - 'ee/spec/features/burndown_charts_spec.rb' - - 'ee/spec/features/groups/group_settings_spec.rb' - - 'ee/spec/features/merge_trains/two_merge_requests_on_train_spec.rb' - - 'ee/spec/features/projects/integrations/user_activates_jira_spec.rb' - - 'ee/spec/features/projects/milestones/milestone_spec.rb' - - 'ee/spec/features/projects/new_project_spec.rb' - - 'ee/spec/features/projects/pipelines/legacy_pipeline_spec.rb' - - 'ee/spec/features/projects/pipelines/pipeline_spec.rb' - - 'ee/spec/features/projects/settings/ee/service_desk_setting_spec.rb' - - 'ee/spec/features/promotion_spec.rb' - - 'ee/spec/graphql/mutations/projects/set_locked_spec.rb' - - 'ee/spec/helpers/application_helper_spec.rb' - 'ee/spec/helpers/ee/auth_helper_spec.rb' - 'ee/spec/helpers/ee/ci/pipelines_helper_spec.rb' - 'ee/spec/helpers/ee/groups_helper_spec.rb' diff --git a/app/views/admin/application_settings/_git_lfs_limits.html.haml b/app/views/admin/application_settings/_git_lfs_limits.html.haml index b8970a5bcf1..638984ae97a 100644 --- a/app/views/admin/application_settings/_git_lfs_limits.html.haml +++ b/app/views/admin/application_settings/_git_lfs_limits.html.haml @@ -15,4 +15,4 @@ = f.label :throttle_authenticated_git_lfs_period_in_seconds, _('Authenticated Git LFS rate limit period in seconds'), class: 'gl-font-weight-bold' = f.number_field :throttle_authenticated_git_lfs_period_in_seconds, class: 'form-control gl-form-input' - = f.submit _('Save changes'), class: "gl-button btn btn-confirm", data: { qa_selector: 'save_changes_button' } + = f.submit _('Save changes'), pajamas_button: true, data: { qa_selector: 'save_changes_button' } diff --git a/app/views/admin/application_settings/_grafana.html.haml b/app/views/admin/application_settings/_grafana.html.haml index 7f305b9ad9c..e2a53106cec 100644 --- a/app/views/admin/application_settings/_grafana.html.haml +++ b/app/views/admin/application_settings/_grafana.html.haml @@ -11,4 +11,4 @@ = f.text_field :grafana_url, class: 'form-control gl-form-input', placeholder: '/-/grafana' %span.form-text.text-muted#support_help_block= _('URL of the Grafana instance to link to from the Metrics Dashboard menu item.') - = f.submit _('Save changes'), class: "gl-button btn btn-confirm" + = f.submit _('Save changes'), pajamas_button: true diff --git a/app/views/admin/application_settings/_mailgun.html.haml b/app/views/admin/application_settings/_mailgun.html.haml index 1604419869c..fb15f6e79a5 100644 --- a/app/views/admin/application_settings/_mailgun.html.haml +++ b/app/views/admin/application_settings/_mailgun.html.haml @@ -19,4 +19,4 @@ = f.label :mailgun_signing_key, _('Mailgun HTTP webhook signing key'), class: 'label-light' = f.text_field :mailgun_signing_key, class: 'form-control gl-form-input' - = f.submit _('Save changes'), class: 'gl-button btn btn-confirm' + = f.submit _('Save changes'), pajamas_button: true diff --git a/app/views/admin/application_settings/_plantuml.html.haml b/app/views/admin/application_settings/_plantuml.html.haml index 5c86ce8dbfb..42f289d87b2 100644 --- a/app/views/admin/application_settings/_plantuml.html.haml +++ b/app/views/admin/application_settings/_plantuml.html.haml @@ -22,4 +22,4 @@ .form-text.text-muted = _('The hostname of your PlantUML server.') - = f.submit _('Save changes'), class: "gl-button btn btn-confirm" + = f.submit _('Save changes'), pajamas_button: true diff --git a/app/views/admin/application_settings/_runner_registrars_form.html.haml b/app/views/admin/application_settings/_runner_registrars_form.html.haml index e7c72fb1dac..08486a808bf 100644 --- a/app/views/admin/application_settings/_runner_registrars_form.html.haml +++ b/app/views/admin/application_settings/_runner_registrars_form.html.haml @@ -13,4 +13,4 @@ checked_value: type, unchecked_value: nil - = f.submit _('Save changes'), class: "gl-button btn btn-confirm" + = f.submit _('Save changes'), pajamas_button: true diff --git a/app/views/admin/applications/index.html.haml b/app/views/admin/applications/index.html.haml index b603c7e5f49..a92bad5e601 100644 --- a/app/views/admin/applications/index.html.haml +++ b/app/views/admin/applications/index.html.haml @@ -14,11 +14,13 @@ .gl-max-w-full.gl-m-auto %h1.h4.gl-font-size-h-display= s_('AdminArea|No applications found') - = link_to _('New application'), new_admin_application_path, class: 'btn gl-button btn-confirm' + = render Pajamas::ButtonComponent.new(href: new_admin_application_path, variant: :confirm) do + = s_('New application') - else %hr - %p= link_to _('New application'), new_admin_application_path, class: 'gl-button btn btn-confirm' + = render Pajamas::ButtonComponent.new(href: new_admin_application_path, variant: :confirm) do + = s_('New application') .table-responsive %table.b-table.gl-table.gl-w-full{ role: 'table' } diff --git a/data/deprecations/templates/example.yml b/data/deprecations/templates/example.yml index 0109b6e9f13..619810f1e7e 100644 --- a/data/deprecations/templates/example.yml +++ b/data/deprecations/templates/example.yml @@ -16,7 +16,7 @@ # # REQUIRED FIELDS # -- title: "Deprecated in favor of option" # (required) Actionable title. e.g., The `confidential` field for a `Note` is deprecated. Use `internal` instead. +- title: "Feature A is deprecated" # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "The maximum number of characters in a job name will be limited to 250." announcement_milestone: "XX.YY" # (required) The milestone when this feature was first announced as deprecated. announcement_date: "YYYY-MM-DD" # (required) The date of the milestone release when this feature was first announced as deprecated. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post. removal_milestone: "XX.YY" # (required) The milestone when this feature is planned to be removed @@ -28,18 +28,18 @@ body: | # (required) Do not modify this line, instead modify the lines below. <!-- START OF BODY COMMENT - This area supports markdown. Delete this entire comment and replace it with your markdown content. + Be clear and concise. Give a brief explanation of the details or reasons for the change. - Deprecations must be actionable. + Additionally, deprecations and other planned changes should be actionable, so add details that explain what users need to do to address the change. For example: - Use terms such as "deprecated in favor of" or "use X instead." + - "Use the `internal` keyword instead of `confidential`." + - "Reduce the number of characters in all jobs to be 250 characters or less." + - "Give an expiration date to any access tokens that have no expiration date." + - "Stop using the `omniauth_crowd` gem. It will be removed and will not be replaced." - For example: + When ready, assign to your tech writer for review. They will run `bin/rake gitlab:docs:compile_deprecations` to update the deprecations doc, then merge. - - The `confidential` field for a `Note` is deprecated. Use `internal` instead. - - The `merge_status` field in the merge request API has been deprecated in favor of `detailed_merge_status`. - - When ready, assign to your tech writer for review. When ready, they will run `bin/rake gitlab:docs:compile_deprecations` to update the deprecations doc, then merge. + This area supports markdown. Delete this entire comment and replace it with your markdown content. END OF BODY COMMENT --> # diff --git a/db/structure.sql b/db/structure.sql index 33a9f13eddf..c0da93eccbf 100644 --- a/db/structure.sql +++ b/db/structure.sql @@ -14624,20 +14624,6 @@ CREATE SEQUENCE dast_sites_id_seq ALTER SEQUENCE dast_sites_id_seq OWNED BY dast_sites.id; -CREATE TABLE dependency_proxy_blob_states ( - verification_started_at timestamp with time zone, - verification_retry_at timestamp with time zone, - verified_at timestamp with time zone, - dependency_proxy_blob_id bigint NOT NULL, - verification_state smallint DEFAULT 0 NOT NULL, - verification_retry_count smallint DEFAULT 0 NOT NULL, - verification_checksum bytea, - verification_failure text, - CONSTRAINT check_8e4f76fffe CHECK ((char_length(verification_failure) <= 255)) -); - -COMMENT ON TABLE dependency_proxy_blob_states IS '{"owner":"group::geo","description":"Geo-specific table to store the verification state of DependencyProxy::Blob objects"}'; - CREATE TABLE dependency_list_exports ( id bigint NOT NULL, created_at timestamp with time zone NOT NULL, @@ -14659,6 +14645,20 @@ CREATE SEQUENCE dependency_list_exports_id_seq ALTER SEQUENCE dependency_list_exports_id_seq OWNED BY dependency_list_exports.id; +CREATE TABLE dependency_proxy_blob_states ( + verification_started_at timestamp with time zone, + verification_retry_at timestamp with time zone, + verified_at timestamp with time zone, + dependency_proxy_blob_id bigint NOT NULL, + verification_state smallint DEFAULT 0 NOT NULL, + verification_retry_count smallint DEFAULT 0 NOT NULL, + verification_checksum bytea, + verification_failure text, + CONSTRAINT check_8e4f76fffe CHECK ((char_length(verification_failure) <= 255)) +); + +COMMENT ON TABLE dependency_proxy_blob_states IS '{"owner":"group::geo","description":"Geo-specific table to store the verification state of DependencyProxy::Blob objects"}'; + CREATE TABLE dependency_proxy_blobs ( id integer NOT NULL, group_id integer NOT NULL, diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt index ed3e2e62250..7835270d4bd 100644 --- a/doc/.vale/gitlab/spelling-exceptions.txt +++ b/doc/.vale/gitlab/spelling-exceptions.txt @@ -1,40 +1,53 @@ accessor accessors ACLs +Adafruit +Airbnb +Airtable Akismet Alertmanager Algolia Alibaba +aliuid Aliyun allowlist allowlisted allowlisting allowlists AlmaLinux +AMIs anonymization anonymized Ansible Anthos +Anycast Apdex API APIs Apparmor +Appetize approvers +Appsec architected architecting archiver Arel arity +Arkose armhf +ARNs Artifactory Asana Asciidoctor asdf Assembla +Astro +async Atlassian -auditable auditability +auditable Auth0 +authenticator Authentiq Authy autocomplete @@ -45,18 +58,22 @@ autogenerated autoloaded autoloader autoloading +automatable autoscale autoscaled autoscaler +autoscalers autoscales autoscaling awardable awardables Axios Ayoa +AZs Azure B-tree backfilling +backfills backport backported backporting @@ -66,11 +83,15 @@ backtraced backtraces backtracing badging +balancer Bamboo Bazel +bcrypt +Beamer Bhyve Bitbucket Bitnami +Bittrex blockquote blockquoted blockquotes @@ -78,6 +99,7 @@ blockquoting boolean booleans Bootsnap +bot Bottlerocket browsable bugfix @@ -93,15 +115,23 @@ bundlers burndown burnup burstable +CA cacheable Caddy +callout +callouts callstack callstacks +camelCase Camo canonicalization canonicalized captcha +CAPTCHAs +Capybara Casdoor +CDNs +CE CentOS Ceph Certbot @@ -119,31 +149,51 @@ checksummable checksummed checksumming Chemlab +chipset +chipsets +CIDRs Citrix Citus +Civo +Cleartext +Clickhouse +CLIs +Clojars clonable Cloudwatch clusterized +CMake CMK CMKs +CNAs +CNs Cobertura Codeception +Codecov +codenames Codepen +CodeSandbox Cognito +Coinbase colocate colocated colocating +CommonMark compilable composable composables Conda +config +Configs Consul Contentful Corosync +corpuses Coursier CPU CPUs cron +crond cronjob cronjobs crons @@ -154,31 +204,53 @@ crosslinking crosslinks Crossplane Crowdin +Crypto +CSSComb CSV +CSVs +CTAs +CTEs +CUnit customappsso +CVEs +CWEs cybersecurity +CycloneDX Dangerfile +DAST +Databricks Datadog datasource datasources +datastore +datastores +datestamp datetime +DBeaver Debian +debloating +decodable Decompressor decryptable +dedupe deduplicate deduplicated deduplicates deduplicating deduplication +delegators deliverables +denormalization denormalize denormalized denormalizes denormalizing +dentry denylist denylisted denylisting denylists +Depesz deployer deployers deprovision @@ -192,14 +264,20 @@ deserialization deserialize deserializers deserializes +desynchronized +Dev DevOps Dhall +dialogs disambiguates discoverability dismissable Disqus Distroless Divio +DLE +DNs +Docker Dockerfile Dockerfiles Dockerize @@ -208,22 +286,37 @@ Dockerizing dogfood dogfooding dogfoods +DOMPurify dotenv +doublestar downvoted downvotes Dpl +dput Dreamweaver +DRIs +DSLs +Dynatrace Ecto eden +EGit ElastiCache Elasticsearch +Eleventy enablement +Encrypt enqueued enqueues +enricher +enrichers enum enums +Enviroments +ESLint ESXi ETag +ETags +Etsy Excon exfiltration ExifTool @@ -234,36 +327,49 @@ failovers failsafe Falco falsy +Fanout Fargate fastlane +Fastly Fastzip favicon favorited +ffaker Figma Filebeat +Filestore +Finicity +Finnhub Fio firewalled firewalling fixup Flamegraph +flamegraphs Flawfinder +Flickr Flowdock Fluentd +Flutterwave Flycheck Forgerock formatters Fortinet +FQDNs +FreshBooks +frontend Fugit fuzzer +fuzzing Gantt Gbps Gemfile Gemnasium Gemojione Getter -getters Getters gettext +GIDs Git Gitaly Gitea @@ -273,19 +379,24 @@ gitlabsos Gitleaks Gitpod Gitter +GLab globals +globbing Gmail Godep +Golang Gollum Google goroutine goroutines Gosec +GPUs Gradle Grafana Grafonnet gravatar Grype +GUIs Gzip Hackathon Haml @@ -293,6 +404,7 @@ HAProxy hardcode hardcoded hardcodes +HashiCorp Haswell heatmap heatmaps @@ -300,6 +412,8 @@ Helm Helmfile Heroku Herokuish +heuristical +hexdigest Hexo HipChat hostname @@ -308,23 +422,34 @@ hotfix hotfixed hotfixes hotfixing +hotspots http https +hyperparameter +hyperparameters +iCalendar iCloud idempotence idmapper Iglu +IIFEs Immer inclusivity +inflector +inflectors Ingress initializer initializers +injective innersource innersourcing +inodes interdependencies interdependency interruptible +inviter IPs +IPython irker issuables Istio @@ -335,10 +460,14 @@ JavaScript Jenkins Jenkinsfile Jira +Jitsu jq jQuery +JRuby +JSDoc jsdom Jsonnet +JUnit JupyterHub JWT JWTs @@ -347,6 +476,7 @@ kanban kanbans kaniko Karma +KCachegrind Kerberos Keycloak keyset @@ -364,14 +494,19 @@ Kubecost kubectl Kubernetes Kubesec +Kucoin Kustomize +kwargs Laravel +LaunchDarkly ldapsearch Lefthook Leiningen libFuzzer +Libgcrypt Libravatar liveness +lockfile lockfiles Lodash Lograge @@ -382,9 +517,13 @@ lookahead lookaheads lookbehind lookbehinds +Lookbook lookups loopback +Lua Lucene +macOS +Mailchimp Maildir Mailgun Mailroom @@ -407,9 +546,12 @@ Memorystore mergeability mergeable metaprogramming +metric's +microformat Microsoft middleware middlewares +migratable migratus minikube MinIO @@ -423,6 +565,8 @@ mitigations mitmproxy mixin mixins +MLFlow +Mmap mockup mockups ModSecurity @@ -431,6 +575,7 @@ monorepo monorepos monospace MRs +MSBuild multiline mutex nameserver @@ -441,45 +586,66 @@ namespaces namespacing namespacings Nanoc +NAT +navigations negatable Netlify +NGINX +ngrok +njsscan Nokogiri nosniff noteable noteables npm +NuGet nullability nullable Nurtch +NVMe nyc OAuth Octokit offboarded offboarding offboards +OIDs +OKRs Okta OmniAuth onboarding OpenID OpenShift Opsgenie +Opstrace +ORMs OS OSs outdent Overcommit Packagist +packfile +packfiles +Packwerk +paginator parallelization parallelizations passthrough +passthroughs passwordless Patroni +PDFs performant PgBouncer +pgFormatter pgLoader +pgMustard Phabricator phaser phasers phpenv +PHPUnit +PIDs pipenv Pipfile Pipfiles @@ -490,25 +656,34 @@ polyfill polyfills pooler postfixed +Postgres postgres.ai PostgreSQL +Praefect's +prebuild +prebuilds precompile precompiled preconfigure preconfigured preconfigures +prefetch +prefetching prefill prefilled prefilling prefills preload +preloaded preloading preloads prepend prepended prepending prepends +prepopulate prepopulated +presentationals Prettifier Pritaly Priyanka @@ -525,7 +700,10 @@ pseudocode pseudonymization pseudonymized pseudonymizer +Pulumi Puma +Pumble +PyPI pytest Python Qualys @@ -534,6 +712,7 @@ Quicktime Rackspace Raspbian rbenv +rbspy rbtrace Rclone Rdoc @@ -549,6 +728,7 @@ rebase rebased rebases rebasing +rebinding reCAPTCHA recoverability Redcarpet @@ -561,8 +741,13 @@ referer referers reflog reflogs +refname refspec refspecs +regexes +Rego +reimplementation +reimplemented reindex reindexed reindexes @@ -572,15 +757,19 @@ reinitializing relicensing remediations renderers +renderless replicables -rpcs repmgr repmgrd +reposts repurposing +requestee +requesters requeue requeued requeues requeuing +resolver Restlet resync resynced @@ -594,10 +783,15 @@ reusability reverified reverifies reverify +reviewee +RIs roadmap roadmaps +rock rollout rollouts +routable +RPCs RSpec rsync rsynced @@ -607,6 +801,8 @@ Rubinius Rubix RuboCop Rubular +RubyGems +Rugged ruleset rulesets runbook @@ -617,15 +813,21 @@ runtimes Salesforce sandboxing sanitization +SBOMs sbt scalers scatterplot scatterplots +schedulable Schemastore scriptable scrollable +SDKs +segmentations SELinux Semgrep +Sendbird +Sendinblue Sendmail Sentry serializer @@ -634,10 +836,13 @@ serializing serverless setuptools severities +SFCs sharded sharding +SHAs shfmt Shimo +Shippo Shopify Sidekiq Silverlight @@ -647,10 +852,14 @@ skippable skopeo Slack Slackbot +SLAs +SLIs Slony +SLOs smartcard smartcards snapshotting +Snowplow Snyk Sobelow Solargraph @@ -660,10 +869,14 @@ Spamcheck spammable sparkline sparklines +Speedscope spidering Splunk SpotBugs +Squarespace +SREs SSDs +SSGs Stackdriver Stackprof starrer @@ -679,6 +892,7 @@ subchart subcharts subcommand subcommands +subcomponent subfolder subfolders subgraph @@ -691,6 +905,7 @@ sublicense sublicensed sublicenses sublicensing +submodule subnet subnets subnetting @@ -707,15 +922,20 @@ subtask subtasks subtest subtests +subtransaction +subtransactions subtree subtrees sudo +sunsetting supercookie supercookies +supergroup superset supersets supertype supertypes +SVGs swappiness swimlane swimlanes @@ -725,8 +945,12 @@ syscall syscalls syslog systemd +tablespace +tablespaces tanuki +taskscaler tcpdump +teardown templated Thanos Thoughtbot @@ -737,7 +961,9 @@ timeboxed timeboxes timeboxing timecop -tiptap +timelog +timelogs +Tiptap todos tokenizer Tokenizers @@ -747,6 +973,7 @@ toolchain toolchains toolkit toolkits +toolset tooltip tooltips transactionally @@ -755,6 +982,7 @@ transpiled transpiles transpiling Trello +Trendline triaged triages triaging @@ -763,10 +991,13 @@ Truststore truthy Twilio Twitter +Typeform TypeScript TZInfo Ubuntu Udemy +UI +UIDs unapplied unapprove unapproved @@ -780,6 +1011,8 @@ unassign unassigning unassigns unban +unbans +uncached uncheck unchecked unchecking @@ -788,6 +1021,7 @@ uncomment uncommented uncommenting uncordon +underperforming unencode unencoded unencoder @@ -813,6 +1047,7 @@ unoptimized unoptimizes unoptimizing unpatched +unpause unprioritized unprotect unprotected @@ -825,6 +1060,7 @@ unpublish unpublished unpublishes unpublishing +unpullable unpushed unreferenced unregister @@ -835,6 +1071,7 @@ unresolve unresolved unresolving unreviewed +unrevoke unsanitized unschedule unscoped @@ -866,10 +1103,14 @@ upstreams upvote upvoted upvotes +urgencies URIs +URL +UUIDs Vagrantfile validator validators +vCPUs vendored vendoring versionless @@ -877,9 +1118,12 @@ viewport viewports virtualized virtualizing +Vite VMs +VPCs Vue Vuex +waitlist walkthrough walkthroughs WebdriverIO @@ -899,17 +1143,22 @@ wireframing Wireshark Wordpress Workato +workstream worktree worktrees Worldline Xcode Xeon +XPath +Yandex YouTrack ytt Yubico Zabbix +ZAProxy Zeitwerk Zendesk ZenTao zsh Zstandard +Zuora diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md index 870578898f9..9d9de193220 100644 --- a/doc/administration/auth/ldap/ldap-troubleshooting.md +++ b/doc/administration/auth/ldap/ldap-troubleshooting.md @@ -411,7 +411,7 @@ the following are true: If all the above are true and the users are still not getting access, [run a manual group sync](#sync-all-groups) in the rails console and [look through the output](#example-console-output-after-a-group-sync) to see what happens when -GitLab syncs the `admin_group`. +GitLab syncs the `admin_group`. #### Sync now button stuck in the UI @@ -659,7 +659,7 @@ end You can then [run a UserSync](#sync-all-users) **(PREMIUM SELF)** to sync the latest DN for each of these users. -## Could not authenticate you from ldapmain because "Unknown provider" +## `Could not authenticate you from Ldapmain because "Unknown provider"` You can receive the following error when authenticating with an LDAP server: diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md index dfa8d09e6ef..a78350d9dba 100644 --- a/doc/administration/geo/disaster_recovery/index.md +++ b/doc/administration/geo/disaster_recovery/index.md @@ -174,7 +174,7 @@ Use `gitlab-ctl geo promote` instead. #### Promoting a **secondary** site with multiple nodes running GitLab 14.5 and later -1. SSH to every Sidekiq, PostgresSQL, and Gitaly node in the **secondary** site and run one of the following commands: +1. SSH to every Sidekiq, PostgreSQL, and Gitaly node in the **secondary** site and run one of the following commands: - To promote the node on the secondary site to primary: @@ -252,7 +252,7 @@ do this manually. #### Promoting a **secondary** site with a Patroni standby cluster running GitLab 14.5 and later -1. SSH to every Sidekiq, PostgresSQL, and Gitaly node in the **secondary** site and run one of the following commands: +1. SSH to every Sidekiq, PostgreSQL, and Gitaly node in the **secondary** site and run one of the following commands: - To promote the secondary site to primary: @@ -364,7 +364,7 @@ with the **secondary** site: sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote ``` -1. SSH to every Sidekiq, PostgresSQL, and Gitaly node in the **secondary** site and run one of the following commands: +1. SSH to every Sidekiq, PostgreSQL, and Gitaly node in the **secondary** site and run one of the following commands: - To promote the secondary site to primary: diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md index 05b7b38a51f..cef0101dd40 100644 --- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md +++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md @@ -228,7 +228,7 @@ follow these steps to avoid unnecessary data loss: ### Promoting the **secondary** site running GitLab 14.5 and later -1. SSH to every Sidekiq, PostgresSQL, and Gitaly node in the **secondary** site and run one of the following commands: +1. SSH to every Sidekiq, PostgreSQL, and Gitaly node in the **secondary** site and run one of the following commands: - To promote the secondary site to primary: diff --git a/doc/administration/geo/replication/location_aware_git_url.md b/doc/administration/geo/replication/location_aware_git_url.md index dbe543f5a62..460de5f3232 100644 --- a/doc/administration/geo/replication/location_aware_git_url.md +++ b/doc/administration/geo/replication/location_aware_git_url.md @@ -104,7 +104,7 @@ on the external URL of the current host. For example: You can customize the: -- SSH remote URL to use the location-aware `git.example.com`. To do so, change the SSH remote URL's +- SSH remote URL to use the location-aware `git.example.com`. To do so, change the SSH remote URL host by setting `gitlab_rails['gitlab_ssh_host']` in `gitlab.rb` of web nodes. - HTTP remote URL as shown in [Custom Git clone URL for HTTP(S)](../../../user/admin_area/settings/visibility_and_access_controls.md#customize-git-clone-url-for-https). diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index f794ea6745f..31477bf2919 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -1476,7 +1476,7 @@ Failed to contact primary https://primary.domain.com/namespace/push_test.git\\nE The partial failover to a secondary Geo *site* may be the result of a temporary/transient issue. Therefore, first attempt to run the promote command again. -1. SSH into every Sidekiq, PostgresSQL, Gitaly, and Rails node in the **secondary** site and run one of the following commands: +1. SSH into every Sidekiq, PostgreSQL, Gitaly, and Rails node in the **secondary** site and run one of the following commands: - To promote the secondary site to primary: @@ -1495,7 +1495,7 @@ The partial failover to a secondary Geo *site* may be the result of a temporary/ If the above steps are **not successful**, proceed through the next steps: -1. SSH to every Sidekiq, PostgresSQL, Gitaly and Rails node in the **secondary** site and perform the following operations: +1. SSH to every Sidekiq, PostgreSQL, Gitaly and Rails node in the **secondary** site and perform the following operations: - Create a `/etc/gitlab/gitlab-cluster.json` file with the following content: diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 6e2b334a6b4..c24664d87f0 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -689,7 +689,7 @@ To see if GitLab can access the repository file system directly, we use the foll - Gitaly ensures that the file system has a metadata file in its root with a UUID in it. - Gitaly reports this UUID to GitLab by using the `ServerInfo` RPC. -- GitLab Rails tries to read the metadata file directly. If it exists, and if the UUID's match, +- GitLab Rails tries to read the metadata file directly. If it exists, and if the UUIDs match, assume we have direct access. Direct Git access is: diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index fd490e3b627..9cc93b21ae9 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -1456,7 +1456,7 @@ To migrate existing clusters: 1. On the Praefect nodes, configure the election strategy in `/etc/gitlab/gitlab.rb` with `praefect['failover_election_strategy'] = 'per_repository'`. - 1. Run `gitlab-ctl reconfigure && gitlab-ctl start` to reconfigure and start the Praefects. + 1. Run `gitlab-ctl reconfigure && gitlab-ctl start` to reconfigure and start the Praefect nodes. - If downtime is unacceptable: diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md index 8c05e4ad611..cec18960dfd 100644 --- a/doc/administration/gitaly/reference.md +++ b/doc/administration/gitaly/reference.md @@ -159,7 +159,7 @@ sum(rate(gitaly_catfile_cache_total{type="hit"}[5m])) / sum(rate(gitaly_catfile_ ### `gitaly-ruby` A Gitaly process uses one or more `gitaly-ruby` helper processes to -execute RPC's implemented in Ruby instead of Go. The `[gitaly-ruby]` +execute RPCs implemented in Ruby instead of Go. The `[gitaly-ruby]` section of the configuration file contains settings for these helper processes. These processes are known to occasionally suffer from memory leaks. diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md index 95b3064c4d6..814575caf50 100644 --- a/doc/administration/housekeeping.md +++ b/doc/administration/housekeeping.md @@ -76,7 +76,7 @@ based on the size of the repository: Gitaly does this to offset the fact that optimizing those data structures takes more time the bigger they get. It is especially important in large -monorepositories (which receive a lot of traffic) to avoid optimizing them too +monorepos (which receive a lot of traffic) to avoid optimizing them too frequently. ## Running housekeeping tasks diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md index 65a077cb652..a1522ccac31 100644 --- a/doc/administration/integration/terminal.md +++ b/doc/administration/integration/terminal.md @@ -64,8 +64,8 @@ detail below. ## Enabling and disabling terminal support NOTE: -AWS Classic Load Balancers (CLBs) do not support web sockets. -If you want web terminals to work, use AWS Network Load Balancers (NLBs). +AWS Classic Load Balancers do not support web sockets. +If you want web terminals to work, use AWS Network Load Balancers. Read [AWS Elastic Load Balancing Product Comparison](https://aws.amazon.com/elasticloadbalancing/features/#compare) for more information. diff --git a/doc/administration/logs/index.md b/doc/administration/logs/index.md index 53661c202e1..efe91e944b7 100644 --- a/doc/administration/logs/index.md +++ b/doc/administration/logs/index.md @@ -85,24 +85,24 @@ except those captured by `runit`. | Log type | Managed by logrotate | Managed by svlogd/runit | |:------------------------------------------------|:------------------------|:------------------------| -| [Alertmanager Logs](#alertmanager-logs) | **{dotted-circle}** No | **{check-circle}** Yes | -| [Crond Logs](#crond-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [Alertmanager logs](#alertmanager-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [crond logs](#crond-logs) | **{dotted-circle}** No | **{check-circle}** Yes | | [Gitaly](#gitaly-logs) | **{check-circle}** Yes | **{check-circle}** Yes | | [GitLab Exporter for Omnibus](#gitlab-exporter) | **{dotted-circle}** No | **{check-circle}** Yes | -| [GitLab Pages Logs](#pages-logs) | **{check-circle}** Yes | **{check-circle}** Yes | +| [GitLab Pages logs](#pages-logs) | **{check-circle}** Yes | **{check-circle}** Yes | | GitLab Rails | **{check-circle}** Yes | **{dotted-circle}** No | -| [GitLab Shell Logs](#gitlab-shelllog) | **{check-circle}** Yes | **{dotted-circle}** No | -| [Grafana Logs](#grafana-logs) | **{dotted-circle}** No | **{check-circle}** Yes | -| [LogRotate Logs](#logrotate-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [GitLab Shell logs](#gitlab-shelllog) | **{check-circle}** Yes | **{dotted-circle}** No | +| [Grafana logs](#grafana-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [LogRotate logs](#logrotate-logs) | **{dotted-circle}** No | **{check-circle}** Yes | | [Mailroom](#mail_room_jsonlog-default) | **{check-circle}** Yes | **{check-circle}** Yes | | [NGINX](#nginx-logs) | **{check-circle}** Yes | **{check-circle}** Yes | -| [PostgreSQL Logs](#postgresql-logs) | **{dotted-circle}** No | **{check-circle}** Yes | -| [Praefect Logs](#praefect-logs) | **{dotted-circle}** Yes | **{check-circle}** Yes | -| [Prometheus Logs](#prometheus-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [PostgreSQL logs](#postgresql-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [Praefect logs](#praefect-logs) | **{dotted-circle}** Yes | **{check-circle}** Yes | +| [Prometheus logs](#prometheus-logs) | **{dotted-circle}** No | **{check-circle}** Yes | | [Puma](#puma-logs) | **{check-circle}** Yes | **{check-circle}** Yes | -| [Redis Logs](#redis-logs) | **{dotted-circle}** No | **{check-circle}** Yes | -| [Registry Logs](#registry-logs) | **{dotted-circle}** No | **{check-circle}** Yes | -| [Workhorse Logs](#workhorse-logs) | **{check-circle}** Yes | **{check-circle}** Yes | +| [Redis logs](#redis-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [Registry logs](#registry-logs) | **{dotted-circle}** No | **{check-circle}** Yes | +| [Workhorse logs](#workhorse-logs) | **{check-circle}** Yes | **{check-circle}** Yes | ## `production_json.log` @@ -491,7 +491,7 @@ are logged to this file. For example: } ``` -## Sidekiq Logs +## Sidekiq logs NOTE: In Omnibus GitLab `12.10` or earlier, the Sidekiq log is at `/var/log/gitlab/gitlab-rails/sidekiq.log`. @@ -671,7 +671,7 @@ I, [2015-02-13T06:17:00.679433 #9291] INFO -- : Moving existing hooks directory User clone/fetch activity using SSH transport appears in this log as `executing git command <gitaly-upload-pack...`. -## Gitaly Logs +## Gitaly logs This file is in `/var/log/gitlab/gitaly/current` and is produced by [runit](http://smarden.org/runit/). `runit` is packaged with Omnibus GitLab and a brief explanation of its purpose @@ -698,7 +698,7 @@ This file is at `/var/log/gitlab/gitaly/gitaly_hooks.log` and is produced by `gitaly-hooks` command. It also contains records about failures received during processing of the responses from GitLab API. -## Puma Logs +## Puma logs ### `puma_stdout.log` @@ -981,11 +981,11 @@ can be used. } ``` -## Registry Logs +## Registry logs For Omnibus GitLab installations, Container Registry logs are in `/var/log/gitlab/registry/current`. -## NGINX Logs +## NGINX logs For Omnibus GitLab installations, NGINX logs are in: @@ -1004,7 +1004,7 @@ Below is the default GitLab NGINX access log format: $remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" ``` -## Pages Logs +## Pages logs For Omnibus GitLab installations, Pages logs are in `/var/log/gitlab/gitlab-pages/current`. @@ -1033,50 +1033,50 @@ For example: } ``` -## Mattermost Logs +## Mattermost logs For Omnibus GitLab installations, Mattermost logs are in these locations: - `/var/log/gitlab/mattermost/mattermost.log` - `/var/log/gitlab/mattermost/current` -## Workhorse Logs +## Workhorse logs For Omnibus GitLab installations, Workhorse logs are in `/var/log/gitlab/gitlab-workhorse/current`. -## PostgreSQL Logs +## PostgreSQL logs For Omnibus GitLab installations, PostgreSQL logs are in `/var/log/gitlab/postgresql/current`. -## Prometheus Logs +## Prometheus logs For Omnibus GitLab installations, Prometheus logs are in `/var/log/gitlab/prometheus/current`. -## Redis Logs +## Redis logs For Omnibus GitLab installations, Redis logs are in `/var/log/gitlab/redis/current`. -## Alertmanager Logs +## Alertmanager logs For Omnibus GitLab installations, Alertmanager logs are in `/var/log/gitlab/alertmanager/current`. <!-- vale gitlab.Spelling = NO --> -## Crond Logs +## crond logs For Omnibus GitLab installations, crond logs are in `/var/log/gitlab/crond/`. <!-- vale gitlab.Spelling = YES --> -## Grafana Logs +## Grafana logs For Omnibus GitLab installations, Grafana logs are in `/var/log/gitlab/grafana/current`. -## LogRotate Logs +## LogRotate logs For Omnibus GitLab installations, `logrotate` logs are in `/var/log/gitlab/logrotate/current`. -## GitLab Monitor Logs +## GitLab Monitor logs For Omnibus GitLab installations, GitLab Monitor logs are in `/var/log/gitlab/gitlab-monitor/`. @@ -1089,7 +1089,7 @@ For Omnibus GitLab installations, GitLab Exporter logs are in `/var/log/gitlab/g For Omnibus GitLab installations, GitLab agent server logs are in `/var/log/gitlab/gitlab-kas/current`. -## Praefect Logs +## Praefect logs For Omnibus GitLab installations, Praefect logs are in `/var/log/gitlab/praefect/`. diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md index a273c6da7aa..ececa12f3ad 100644 --- a/doc/administration/postgresql/replication_and_failover.md +++ b/doc/administration/postgresql/replication_and_failover.md @@ -608,7 +608,7 @@ Here is a list and description of each machine and the assigned IP: All passwords are set to `toomanysecrets`. Do not use this password or derived hashes and the `external_url` for GitLab is `http://gitlab.example.com`. -After the initial configuration, if a failover occurs, the PostgresSQL leader node changes to one of the available secondaries until it is failed back. +After the initial configuration, if a failover occurs, the PostgreSQL leader node changes to one of the available secondaries until it is failed back. #### Example recommended setup for Consul servers diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 2020f7c0c42..f4cd9deb8f3 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -189,7 +189,7 @@ CI pipelines alike. As such, large repositories come with notable cost and typically will require more resources to handle, significantly so in some cases. It's therefore **strongly** recommended then to review large repositories -to ensure they maintain good repo health and reduce their size wherever possible. +to ensure they maintain good health and reduce their size wherever possible. NOTE: If best practices aren't followed and large repositories are present on the environment, diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 79772ad720c..60fa7c8595d 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -189,7 +189,7 @@ CI pipelines alike. As such, large repositories come with notable cost and typically will require more resources to handle, significantly so in some cases. It's therefore **strongly** recommended then to review large repositories -to ensure they maintain good repo health and reduce their size wherever possible. +to ensure they maintain good health and reduce their size wherever possible. NOTE: If best practices aren't followed and large repositories are present on the environment, diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index 1acae93f764..b83a6dcd36e 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -125,7 +125,7 @@ CI pipelines alike. As such, large repositories come with notable cost and typically will require more resources to handle, significantly so in some cases. It's therefore **strongly** recommended then to review large repositories -to ensure they maintain good repo health and reduce their size wherever possible. +to ensure they maintain good health and reduce their size wherever possible. NOTE: If best practices aren't followed and large repositories are present on the environment, diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 3c63fef8ea2..a8bcb2ee7bf 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -195,7 +195,7 @@ CI pipelines alike. As such, large repositories come with notable cost and typically will require more resources to handle, significantly so in some cases. It's therefore **strongly** recommended then to review large repositories -to ensure they maintain good repo health and reduce their size wherever possible. +to ensure they maintain good health and reduce their size wherever possible. NOTE: If best practices aren't followed and large repositories are present on the environment, diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 9b425199220..63cca955a57 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -189,7 +189,7 @@ CI pipelines alike. As such, large repositories come with notable cost and typically will require more resources to handle, significantly so in some cases. It's therefore **strongly** recommended then to review large repositories -to ensure they maintain good repo health and reduce their size wherever possible. +to ensure they maintain good health and reduce their size wherever possible. NOTE: If best practices aren't followed and large repositories are present on the environment, diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 3b66e9130bd..a5f2ed4db9c 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -192,7 +192,7 @@ CI pipelines alike. As such, large repositories come with notable cost and typically will require more resources to handle, significantly so in some cases. It's therefore **strongly** recommended then to review large repositories -to ensure they maintain good repo health and reduce their size wherever possible. +to ensure they maintain good health and reduce their size wherever possible. NOTE: If best practices aren't followed and large repositories are present on the environment, diff --git a/doc/administration/sidekiq/index.md b/doc/administration/sidekiq/index.md index d0cb124236c..b40a1f0ba1d 100644 --- a/doc/administration/sidekiq/index.md +++ b/doc/administration/sidekiq/index.md @@ -383,7 +383,7 @@ If you use [SAML Group Sync](../../user/group/saml_sso/group_sync.md), you must ## Disable Rugged -Calls into Rugged, Ruby bindings for `libgit2`, [lock the Sidekiq processes's GVL](https://silverhammermba.github.io/emberb/c/#c-in-ruby-threads), +Calls into Rugged, Ruby bindings for `libgit2`, [lock the Sidekiq processes (GVL)](https://silverhammermba.github.io/emberb/c/#c-in-ruby-threads), blocking all jobs on that worker from proceeding. If Rugged calls performed by Sidekiq are slow, this can cause significant delays in background task processing. diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md index 451e1666bd2..c29513ad253 100644 --- a/doc/administration/troubleshooting/postgresql.md +++ b/doc/administration/troubleshooting/postgresql.md @@ -104,7 +104,7 @@ or `statement_timeout`, but to leave the third setting at 60 seconds. Setting `idle_in_transaction` protects the database from sessions potentially hanging for days. There's more discussion in [the issue relating to introducing this timeout on GitLab.com](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/1053). -PostgresSQL defaults: +PostgreSQL defaults: - `statement_timeout = 0` (never) - `idle_in_transaction_session_timeout = 0` (never) @@ -188,7 +188,7 @@ To temporarily change the statement timeout: ### Database is not accepting commands to avoid wraparound data loss -This error likely means that AUTOVACUUM is failing to complete its run: +This error likely means that `autovacuum` is failing to complete its run: ```plaintext ERROR: database is not accepting commands to avoid wraparound data loss in database "gitlabhq_production" diff --git a/doc/api/dora/metrics.md b/doc/api/dora/metrics.md index d902f5eb91f..4374d1dde95 100644 --- a/doc/api/dora/metrics.md +++ b/doc/api/dora/metrics.md @@ -103,7 +103,7 @@ parameter: |:---------------------------|:-----------------------------------| | `change_failure_rate` | The number of incidents divided by the number of deployments during the time period. Available only for production environment. | | `deployment_frequency` | The number of successful deployments during the time period. | -| `lead_time_for_changes` | The median number of seconds between the merge of the merge request (MR) and the deployment of the MR's commits for all MRs deployed during the time period. | +| `lead_time_for_changes` | The median number of seconds between the merge of the merge request (MR) and the deployment of the MR commits for all MRs deployed during the time period. | | `time_to_restore_service` | The median number of seconds an incident was open during the time period. Available only for production environment. | NOTE: diff --git a/doc/api/graphql/audit_report.md b/doc/api/graphql/audit_report.md index 2f96bc5ecdd..5529f0b872a 100644 --- a/doc/api/graphql/audit_report.md +++ b/doc/api/graphql/audit_report.md @@ -20,13 +20,13 @@ The query includes: - [`pageInfo`](#pageinfo) - [`nodes`](#nodes) -## pageInfo +## `pageInfo` This contains the data needed to implement pagination. GitLab uses cursor-based [pagination](getting_started.md#pagination). For more information, see [Pagination](https://graphql.org/learn/pagination/) in the GraphQL documentation. -## nodes +## `nodes` In a GraphQL query, `nodes` is used to represent a collection of [`nodes` on a graph](https://en.wikipedia.org/wiki/Vertex_(graph_theory)). In this case, the collection of nodes is a collection of `User` objects. For each one, diff --git a/doc/api/graphql/users_example.md b/doc/api/graphql/users_example.md index 96bbeeb2d06..9d223f9e618 100644 --- a/doc/api/graphql/users_example.md +++ b/doc/api/graphql/users_example.md @@ -20,13 +20,13 @@ The query includes: - [`pageInfo`](#pageinfo) - [`nodes`](#nodes) -## pageInfo +## `pageInfo` This contains the data needed to implement pagination. GitLab uses cursor-based [pagination](getting_started.md#pagination). For more information, see [Pagination](https://graphql.org/learn/pagination/) in the GraphQL documentation. -## nodes +## `nodes` In a GraphQL query, `nodes` is used to represent a collection of [`nodes` on a graph](https://en.wikipedia.org/wiki/Vertex_(graph_theory)). In this case, the collection of nodes is a collection of `User` objects. For each one, diff --git a/doc/api/integrations.md b/doc/api/integrations.md index d64c67e1402..a6090228af2 100644 --- a/doc/api/integrations.md +++ b/doc/api/integrations.md @@ -1181,7 +1181,7 @@ Parameters: | --------- | ---- | -------- | ----------- | | `api_url` | string | true | Prometheus API Base URL. For example, `http://prometheus.example.com/`. | | `google_iap_audience_client_id` | string | false | Client ID of the IAP secured resource (looks like IAP_CLIENT_ID.apps.googleusercontent.com) | -| `google_iap_service_account_json` | string | false | `credentials.json` file for your service account, like { "type": "service_account", "project_id": ... } | +| `google_iap_service_account_json` | string | false | `credentials.json` file for your service account, like { `"type": "service_account", "project_id": ... }` | ### Disable Prometheus integration diff --git a/doc/api/issue_links.md b/doc/api/issue_links.md index 253be9109c7..ce3d26f1c08 100644 --- a/doc/api/issue_links.md +++ b/doc/api/issue_links.md @@ -178,7 +178,7 @@ POST /projects/:id/issues/:issue_iid/links | `issue_iid` | integer | yes | The internal ID of a project's issue | | `target_project_id` | integer/string | yes | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) of a target project | | `target_issue_iid` | integer/string | yes | The internal ID of a target project's issue | -| `link_type` | string | no | The type of the relation ("relates_to", "blocks", "is_blocked_by"), defaults to "relates_to"). | +| `link_type` | string | no | The type of the relation (`relates_to`, `blocks`, `is_blocked_by`), defaults to `relates_to`). | ```shell curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/4/issues/1/links?target_project_id=5&target_issue_iid=1" diff --git a/doc/api/templates/gitlab_ci_ymls.md b/doc/api/templates/gitlab_ci_ymls.md index b7048795313..29ee93c4e45 100644 --- a/doc/api/templates/gitlab_ci_ymls.md +++ b/doc/api/templates/gitlab_ci_ymls.md @@ -5,9 +5,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -# GitLab CI YAMLs API **(FREE)** +# GitLab CI YAML API **(FREE)** -In GitLab, there is an API endpoint available to work with GitLab CI/CD YAMLs. For more +In GitLab, there is an API endpoint available to work with GitLab CI/CD YAML. For more information on CI/CD pipeline configuration in GitLab, see the [configuration reference documentation](../../ci/yaml/index.md). diff --git a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md index 71f7af62785..8baac2e0c14 100644 --- a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md +++ b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md @@ -75,7 +75,7 @@ incidents, over the last couple of months, for example: - S2: 2022-04-12 [Transactions detected that have been running for more than 10m](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6821) - S2: 2022-04-06 [Database contention plausibly caused by excessive `ci_builds` reads](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6773) - S2: 2022-03-18 [Unable to remove a foreign key on `ci_builds`](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6642) -- S2: 2022-10-10 [The queuing_queries_duration SLI apdex violating SLO](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/7852#note_1130123525) +- S2: 2022-10-10 [The `queuing_queries_duration` SLI apdex violating SLO](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/7852#note_1130123525) We have approximately 50 `ci_*` prefixed database tables, and some of them would benefit from partitioning. diff --git a/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md b/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md index 5e091046b07..0be565fec1c 100644 --- a/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md +++ b/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md @@ -432,7 +432,7 @@ What was done? - We control specs from main application using environment variable `TEST_WEB_ENGINE` - We added new CI job that will run `engines/web_engine/spec` tests separately using `TEST_WEB_ENGINE` environment variable. - We added new CI job that will run `engines/web_engine/ee/spec` tests separately using `TEST_WEB_ENGINE` environment variable. - - We are running all whitebox frontend tests with `TEST_WEB_ENGINE=true` + - We are running all white box frontend tests with `TEST_WEB_ENGINE=true` #### Results @@ -498,7 +498,7 @@ Cons: - It is harder to implement GraphQL subscriptions as in case of Sidekiq as we need another way to pass subscriptions - `api_v4` paths can be used in some services that are used by Sidekiq (for example `api_v4_projects_path`) -- url_helpers paths are used in models and services, that could be used by Sidekiq (for example `Gitlab::Routing.url_helpers.project_pipelines_path` is used by [ExpirePipelineCacheService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/expire_pipeline_cache_service.rb#L20) in [ExpirePipelineCacheWorker](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/expire_pipeline_cache_worker.rb#L18)) +- `url_helpers` paths are used in models and services, that could be used by Sidekiq (for example `Gitlab::Routing.url_helpers.project_pipelines_path` is used by [ExpirePipelineCacheService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/expire_pipeline_cache_service.rb#L20) in [ExpirePipelineCacheWorker](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/expire_pipeline_cache_worker.rb#L18)) #### Example: GraphQL diff --git a/doc/architecture/blueprints/container_registry_metadata_database/index.md b/doc/architecture/blueprints/container_registry_metadata_database/index.md index 63e27286756..6f70004f299 100644 --- a/doc/architecture/blueprints/container_registry_metadata_database/index.md +++ b/doc/architecture/blueprints/container_registry_metadata_database/index.md @@ -316,7 +316,7 @@ All GitLab Rails features dependent on a specific version of the registry should This is already done to determine whether a tag should be deleted using the new tag delete feature (only available in the GitLab Container Registry v2.8.1+) or the old method. In this case, GitLab Rails sends an `OPTIONS` request to the registry tag route to determine whether the `DELETE` method is supported or not. -Alternatively, and as the universal long-term solution, we need to determine the registry vendor, version, and supported features (the last two are only applicable if the vendor is GitLab) and persist it in the GitLab Rails database. This information can then be used in realtime to toggle features or fallback to alternative methods, if possible. The initial implementation of this approach was introduced as part of [#204839](https://gitlab.com/gitlab-org/gitlab/-/issues/204839). Currently, it's only used for metrics purposes. Further improvements are required to guarantee that the version information is kept up to date in self-managed instances, where the registry may be hot swapped. +Alternatively, and as the universal long-term solution, we need to determine the registry vendor, version, and supported features (the last two are only applicable if the vendor is GitLab) and persist it in the GitLab Rails database. This information can then be used in real time to toggle features or fallback to alternative methods, if possible. The initial implementation of this approach was introduced as part of [#204839](https://gitlab.com/gitlab-org/gitlab/-/issues/204839). Currently, it's only used for metrics purposes. Further improvements are required to guarantee that the version information is kept up to date in self-managed instances, where the registry may be hot swapped. ##### Release and Deployment diff --git a/doc/architecture/blueprints/image_resizing/index.md b/doc/architecture/blueprints/image_resizing/index.md index 97bf520105a..99a7c4ae144 100644 --- a/doc/architecture/blueprints/image_resizing/index.md +++ b/doc/architecture/blueprints/image_resizing/index.md @@ -38,7 +38,7 @@ sequenceDiagram Content image resizing is a more complex problem to tackle. There are no set size restrictions and there are additional features or requirements to consider. - Dynamic WebP support - the WebP format typically achieves an average of 30% more compression than JPEG without the loss of image quality. More details are in [this Google Comparative Study](https://developers.google.com/speed/webp/docs/c_study) -- Extract first image of GIF's so we can prevent from loading 10 MB pixels +- Extract first GIF image so we can prevent from loading 10 MB pixels - Check Device Pixel Ratio to deliver nice images on High DPI screens - Progressive image loading, similar to what is described in [this article about how to build a progressive image loader](https://www.sitepoint.com/how-to-build-your-own-progressive-image-loader/) - Resizing recommendations (for example, size and clarity) diff --git a/doc/architecture/blueprints/pods/pods-feature-ci-runners.md b/doc/architecture/blueprints/pods/pods-feature-ci-runners.md index b204ab3455f..b75515a916f 100644 --- a/doc/architecture/blueprints/pods/pods-feature-ci-runners.md +++ b/doc/architecture/blueprints/pods/pods-feature-ci-runners.md @@ -101,7 +101,7 @@ We can pick a design where all runners are always registered and local to a give - In this model we would require the above endpoints to be scoped to a Pod in some way or made routable. It might be via prefixing them, adding additional Pod parameter, or providing much more robust way to decode runner token and match it to Pod. -- If routable token is used, we could move away from cryptographical random stored in +- If routable token is used, we could move away from cryptographic random stored in database to rather prefer to use JWT tokens that would encode - The Admin Area showing registered Runners would have to be scoped to a Pod diff --git a/doc/architecture/blueprints/pods/pods-feature-container-registry.md b/doc/architecture/blueprints/pods/pods-feature-container-registry.md index 954a9c29417..d47913fbc2a 100644 --- a/doc/architecture/blueprints/pods/pods-feature-container-registry.md +++ b/doc/architecture/blueprints/pods/pods-feature-container-registry.md @@ -121,7 +121,7 @@ but this might be desired approach. ## 4. Evaluation -There do not seem any theorethical problems with running GitLab Container Registry in a Pod. +There do not seem any theoretical problems with running GitLab Container Registry in a Pod. Service seems that can be easily made routable to work well. The practical complexities are around managing complex service from infrastructure side. diff --git a/doc/architecture/blueprints/pods/proposal-stateless-router-with-buffering-requests.md b/doc/architecture/blueprints/pods/proposal-stateless-router-with-buffering-requests.md index d90df985da2..ab19b652f93 100644 --- a/doc/architecture/blueprints/pods/proposal-stateless-router-with-buffering-requests.md +++ b/doc/architecture/blueprints/pods/proposal-stateless-router-with-buffering-requests.md @@ -166,7 +166,7 @@ graph TD; 1. A new column `routes.pod_id` is added to `routes` table 1. A new Router service exists to choose which pod to route a request to. 1. A new concept will be introduced in GitLab called an organization and a user can select a "default organization" and this will be a user level setting. The default organization is used to redirect users away from ambiguous routes like `/dashboard` to organization scoped routes like `/organizations/my-organization/-/dashboard`. Legacy users will have a special default organization that allows them to keep using global resources on `Pod US0`. All existing namespaces will initially move to this public organization. -1. If a pod receives a request for a `routes.pod_id` that it does not own it returns a `302` with `X-Gitlab-Pod-Redirect` header so that the router can send the request to the correct pod. The correct pod can also set a header `X-Gitlab-Pod-Cache` which contains information about how this request should be cached to remember the pod. For example if the request was `/gitlab-org/gitlab` then the header would encode `/gitlab-org/* => Pod US0` (ie. any requests starting with `/gitlab-org/` can always be routed to `Pod US0` +1. If a pod receives a request for a `routes.pod_id` that it does not own it returns a `302` with `X-Gitlab-Pod-Redirect` header so that the router can send the request to the correct pod. The correct pod can also set a header `X-Gitlab-Pod-Cache` which contains information about how this request should be cached to remember the pod. For example if the request was `/gitlab-org/gitlab` then the header would encode `/gitlab-org/* => Pod US0` (for example, any requests starting with `/gitlab-org/` can always be routed to `Pod US0` 1. When the pod does not know (from the cache) which pod to send a request to it just picks a random pod within it's region 1. Writes to `gitlab_users` and `gitlab_routes` are sent to a primary PostgreSQL server in our `US` region but reads can come from replicas in the same region. This will add latency for these writes but we expect they are infrequent relative to the rest of GitLab. @@ -176,7 +176,7 @@ All users will get a new column `users.default_organization` which they can control in user settings. We will introduce a concept of the `GitLab.com Public` organization. This will be set as the default organization for all existing users. This organization will allow the user to see data from all namespaces in -`Pod US0` (ie. our original GitLab.com instance). This behavior can be invisible to +`Pod US0` (for example, our original GitLab.com instance). This behavior can be invisible to existing users such that they don't even get told when they are viewing a global page like `/dashboard` that it's even scoped to an organization. @@ -195,7 +195,7 @@ frustrating and painful so to avoid this we will decompose and share all Admin A settings in the `gitlab_admin` schema. This should be safe (similar to other shared schemas) because these receive very little write traffic. -In cases where different pods need different settings (eg. the +In cases where different pods need different settings (for example, the Elasticsearch URL), we will either decide to use a templated format in the relevant `application_settings` row which allows it to be dynamic per pod. Alternatively if that proves difficult we'll introduce a new table @@ -241,7 +241,7 @@ keeping settings in sync for all pods. 1. Data in `gitlab_users` and `gitlab_routes` databases must be replicated in all regions which may be an issue for certain types of compliance. 1. The router cache may need to be very large if we get a wide variety of URLs - (ie. long tail). In such a case we may need to implement a 2nd level of + (for example, long tail). In such a case we may need to implement a 2nd level of caching in user cookies so their frequently accessed pages always go to the right pod the first time. 1. Having shared database access for `gitlab_users` and `gitlab_routes` @@ -363,7 +363,7 @@ sequenceDiagram 1. User is in Europe so DNS resolves to the router in Europe 1. The router does not have `/my-company/*` cached yet so it chooses randomly `Pod EU1` 1. `Pod EU1` redirects them through a login flow -1. Stil they request `/my-company/my-project` without the router cache, so the router chooses a random pod `Pod EU1` +1. Still they request `/my-company/my-project` without the router cache, so the router chooses a random pod `Pod EU1` 1. `Pod EU1` does not have `/my-company`, but it knows that it lives in `Pod EU0` so it redirects the router to `Pod EU0` 1. `Pod EU0` returns the correct response as well as setting the cache headers for the router `/my-company/* => Pod EU0` 1. The router now caches and remembers any request paths matching `/my-company/*` should go to `Pod EU0` @@ -499,7 +499,7 @@ allowed to use legacy global functionality like `/dashboard` to see data across namespaces located on `Pod US0`. The rails backend also knows that the default pod to render any ambiguous routes like `/dashboard` is `Pod US0`. Lastly the user will be allowed to navigate to organizations on another pod like `/my-organization` but when they do the -user will see a message indicating that some data may be missing (eg. the +user will see a message indicating that some data may be missing (for example, the MRs/Issues/Todos) counts. #### Navigates to `/gitlab-org/gitlab` while not logged in diff --git a/doc/architecture/blueprints/rate_limiting/index.md b/doc/architecture/blueprints/rate_limiting/index.md index 22eb9a16824..22709a90cee 100644 --- a/doc/architecture/blueprints/rate_limiting/index.md +++ b/doc/architecture/blueprints/rate_limiting/index.md @@ -50,7 +50,7 @@ vision of our next rate limiting and policies enforcement architecture. - Finding what limits are defined requires performing a codebase audit. - We don't have a good way to expose limits to satellite services like Registry. - We enforce a number of different policies via opaque external systems - (Pipeline Validation Service, Bouncer, Watchtower, Cloudflare, Haproxy). + (Pipeline Validation Service, Bouncer, Watchtower, Cloudflare, HAProxy). - There is not standardized way to define policies in a way consistent with defining limits. - It is difficult to understand when a user is approaching a limit threshold. - There is no way to automatically notify a user when they are approaching thresholds. @@ -112,7 +112,7 @@ quota and by a policy. code. Decoupled policy definitions allow logic to be shared across multiple services and/or "hot-loaded" at runtime without releasing a new version of the application. - _Example:_ decode and verify a JWT, determine whether the user has access to the - given resource based on the JWT's scopes and claims + given resource based on the JWT scopes and claims - _Example:_ deny access based on group-level constraints (such as IP allowlist, SSO, and 2FA) across all services @@ -362,7 +362,7 @@ hierarchy. Choosing a proper solution will require a thoughtful research. b. Develop YAML model for limits. c. Build Rails SDK. d. Create examples showcasing usage of the new rate limits SDK. -**Phase 3**: Team Fanout of Rails SDK - Stage Groups +**Phase 3**: Team fan out of Rails SDK - Stage Groups a. Individual stage groups begin using the SDK built in Phase 2 for new limit and policies. b. Stage groups begin replacing historical adhoc limit implementations with the SDK. c. Provides means to monitor and observe the progress of the replacement effort. Ideally this is broken down to the `feature_category` level to drive group-level buy-in -- Owning Team. @@ -373,7 +373,7 @@ hierarchy. Choosing a proper solution will require a thoughtful research. **Phase 5**: SDK for Satellite Services - Owning Team a. Build Golang SDK. c. Create examples showcasing usage of the new rate limits SDK. -**Phase 6**: Team Fanout for Satellite Services - Stage Groups +**Phase 6**: Team fan out for Satellite Services - Stage Groups a. Individual stage groups being using the SDK built in Phase 5 for new limit and policies. b. Stage groups begin replacing historical adhoc limit implementations with the SDK. diff --git a/doc/architecture/blueprints/runner_scaling/index.md b/doc/architecture/blueprints/runner_scaling/index.md index 9d69f97841a..8eb6bfd2551 100644 --- a/doc/architecture/blueprints/runner_scaling/index.md +++ b/doc/architecture/blueprints/runner_scaling/index.md @@ -234,7 +234,7 @@ them each separately. etc... This information is very provider specific. - **VM lifecycle management**. Multiple machines will be created and a system must keep track of which machines belong to this executor. Typically - a cloud provider will have a way to manage a set of homogenous machines. + a cloud provider will have a way to manage a set of homogeneous machines. E.g. GCE Instance Group. The basic operations are increase, decrease and usually delete a specific machine. - **VM autoscaling**. In addition to low-level lifecycle management, @@ -372,7 +372,7 @@ provide a context and an environment in which a build will be executed by one of the Custom Executors. There are multiple solutions to implementing a custom provider abstraction. We -can use raw Go plugins, Hashcorp's Go Plugin, HTTP interface or gRPC based +can use raw Go plugins, HashiCorp's Go Plugin, HTTP interface or gRPC based facade service. There are many solutions, and we want to choose the most optimal one. In order to do that, we will describe the solutions in a separate document, define requirements and score the solution accordingly. This will @@ -390,11 +390,11 @@ Rationale: [Description of the Custom Executor Provider proposal](https://gitlab We can introduce a more simple version of the `Machine` abstraction in the form of a "Fleeting" interface. Fleeting provides a low-level interface to -a homogenous VM group which allows increasing and decreasing the set size +a homogeneous VM group which allows increasing and decreasing the set size as well as consuming a VM from within the set. Plugins for cloud providers and other VM sources are implemented via the -Hashicorp go-plugin library. This is in practice gRPC over STDIN/STDOUT +HashiCorp go-plugin library. This is in practice gRPC over STDIN/STDOUT but other wire protocols can be used also. In order to make use of the new interface, the autoscaling logic is pulled diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md index 39f45471021..84797029c4c 100644 --- a/doc/ci/directed_acyclic_graph/index.md +++ b/doc/ci/directed_acyclic_graph/index.md @@ -38,10 +38,10 @@ It has a pipeline that looks like the following: | build | test | deploy | | ----- | ---- | ------ | -| build_a | test_a | deploy_a | -| build_b | test_b | deploy_b | -| build_c | test_c | deploy_c | -| build_d | test_d | deploy_d | +| `build_a` | `test_a` | `deploy_a` | +| `build_b` | `test_b` | `deploy_b` | +| `build_c` | `test_c` | `deploy_c` | +| `build_d` | `test_d` | `deploy_d` | Using a DAG, you can relate the `_a` jobs to each other separately from the `_b` jobs, and even if service `a` takes a very long time to build, service `b` doesn't diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md index 7208caaccae..66369cec3b1 100644 --- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md +++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md @@ -256,7 +256,7 @@ NOTE: If you're using a Vault instance provided by HashiCorp Cloud Platform, you need to export the `VAULT_NAMESPACE` variable. Its default value is `admin`. - + The following job is able to authenticate using the `myproject-production` role and read secrets under `/secret/myproject/production/`: @@ -279,14 +279,14 @@ read_secrets: - echo $PASSWORD ``` - + ### Limit token access to Vault secrets You can control `CI_JOB_JWT` access to Vault secrets by using Vault protections and GitLab features. For example, restrict the token by: -- Using Vault [bound_claims](https://developer.hashicorp.com/vault/docs/auth/jwt#bound-claims) +- Using Vault [bound claims](https://developer.hashicorp.com/vault/docs/auth/jwt#bound-claims) for specific groups using `group_claim`. - Hard coding values for Vault bound claims based on the `user_login` and `user_email` of specific users. diff --git a/doc/ci/examples/index.md b/doc/ci/examples/index.md index 361061d0d75..c8ad653e41f 100644 --- a/doc/ci/examples/index.md +++ b/doc/ci/examples/index.md @@ -33,7 +33,7 @@ The following table lists examples with step-by-step tutorials that are containe | npm with semantic-release | [Publish npm packages to the GitLab Package Registry using semantic-release](semantic-release.md). | | PHP with Laravel, Envoy | [Test and deploy Laravel applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md). | | PHP with npm, SCP | [Running Composer and npm scripts with deployment via SCP in GitLab CI/CD](deployment/composer-npm-deploy.md). | -| PHP with PHPunit, `atoum` | [Testing PHP projects](php.md). | +| PHP with PHPUnit, `atoum` | [Testing PHP projects](php.md). | | Secrets management with Vault | [Authenticating and Reading Secrets With HashiCorp Vault](authenticating-with-hashicorp-vault/index.md). | ### Contributed examples diff --git a/doc/ci/runners/configure_runners.md b/doc/ci/runners/configure_runners.md index b2035868c06..d3ff4051a8e 100644 --- a/doc/ci/runners/configure_runners.md +++ b/doc/ci/runners/configure_runners.md @@ -62,7 +62,7 @@ How this feature works: With some [runner executors](https://docs.gitlab.com/runner/executors/), if you can run a job on the runner, you can get full access to the file system, and thus any code it runs as well as the token of the runner. With shared runners, this means that anyone -that runs jobs on the runner, can access anyone else's code that runs on the +that runs jobs on the runner, can access another user's code that runs on the runner. In addition, because you can get access to the runner token, it is possible @@ -903,7 +903,7 @@ The default is the number of CPUs available, but given the memory ramifications, setting. `FASTZIP_EXTRACTOR_CONCURRENCY` controls how many files are decompressed at once. Files from a zip archive can natively -be read from concurrency, so no additional memory is allocated in additional to what the decompressor requires. This +be read from concurrency, so no additional memory is allocated in addition to what the decompressor requires. This defaults to the number of CPUs available. ## Clean up stale runners **(ULTIMATE)** diff --git a/doc/ci/testing/fail_fast_testing.md b/doc/ci/testing/fail_fast_testing.md index 58471a626da..b1bc44a0a37 100644 --- a/doc/ci/testing/fail_fast_testing.md +++ b/doc/ci/testing/fail_fast_testing.md @@ -12,7 +12,7 @@ For applications that use RSpec for running tests, we've introduced the `Verify/ [template to run subsets of your test suite](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Verify/FailFast.gitlab-ci.yml), based on the changes in your merge request. -The template uses the [test_file_finder (`tff`) gem](https://gitlab.com/gitlab-org/ci-cd/test_file_finder/) +The template uses the [`test_file_finder` (`tff`) gem](https://gitlab.com/gitlab-org/ci-cd/test_file_finder/) that accepts a list of files as input, and returns a list of spec (test) files that it believes to be relevant to the input files. diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md index 87ebff74600..02bc1417148 100644 --- a/doc/ci/troubleshooting.md +++ b/doc/ci/troubleshooting.md @@ -362,7 +362,7 @@ To [prevent duplicate pipelines](jobs/job_control.md#avoid-duplicate-pipelines), [`workflow: rules`](yaml/index.md#workflow) or rewrite your rules to control which pipelines can run. -### Console workaround if job using resource_group gets stuck **(FREE SELF)** +### Console workaround if job using `resource_group` gets stuck **(FREE SELF)** ```ruby # find resource group by name diff --git a/doc/ci/yaml/artifacts_reports.md b/doc/ci/yaml/artifacts_reports.md index 7e4968fe91e..e12786f06ce 100644 --- a/doc/ci/yaml/artifacts_reports.md +++ b/doc/ci/yaml/artifacts_reports.md @@ -150,16 +150,16 @@ GitLab can display the results of one or more reports in: > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360766) in GitLab 15.3 This report is a Software Bill of Materials describing the components of a project -following the [cyclonedx](https://cyclonedx.org/docs/1.4) protocol format. +following the [CycloneDX](https://cyclonedx.org/docs/1.4) protocol format. -You can specify multiple cyclonedx reports per job. These can be either supplied +You can specify multiple CycloneDX reports per job. These can be either supplied as a list of filenames, a filename pattern, or both: - List of filenames: `cyclonedx: [gl-sbom-npm-npm.cdx.json, gl-sbom-bundler-gem.cdx.json]`. - A filename pattern: `cyclonedx: gl-sbom-*.json`. - Combination of both of the above: `cyclonedx: [gl-sbom-*.json, my-cyclonedx.json]`. -Below is an example of a job exposing cyclonedx artifacts: +Below is an example of a job exposing CycloneDX artifacts: ```yaml artifacts: diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index 75020e25b57..925f948e118 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -170,7 +170,7 @@ See also: - [Exposing Global IDs](#exposing-global-ids). - [Mutation arguments](#object-identifier-arguments). -- [Deprecating Global IDs](#deprecate-global-ids). +- [Deprecating Global IDs](#deprecate-global-ids). We have a custom scalar type (`Types::GlobalIDType`) which should be used as the type of input and output arguments when the value is a `GlobalID`. The benefits @@ -2263,7 +2263,7 @@ end 1. 95% of the resolver specs use arguments that are Ruby objects, as opposed to when using the GraphQL API only strings and integers are used. This works fine in most cases. - 1. If your resolver takes arguments that use a `prepare` proc, such as a resolver that accepts timeframe + 1. If your resolver takes arguments that use a `prepare` proc, such as a resolver that accepts time frame arguments (`TimeFrameArguments`), you must pass the `arg_style: :internal_prepared` parameter into the `resolve` method. This tells the code to convert the arguments into strings and integers and pass them through regular argument handling, ensuring that the `prepare` proc is called correctly. diff --git a/doc/development/approval_rules.md b/doc/development/approval_rules.md index 3e911bb082b..312bf2b1bb7 100644 --- a/doc/development/approval_rules.md +++ b/doc/development/approval_rules.md @@ -221,7 +221,7 @@ It is responsible for parsing `approval_rules_attributes` parameter to: - Filter the group IDs whether they are visible to user. - Identify the `any_approver` rule. - Append hidden groups to it when specified. -- Append user defined inapplicable (rules that does not apply to MR's target +- Append user defined inapplicable (rules that do not apply to the merge request's target branch) approval rules. ## Flow diff --git a/doc/development/architecture.md b/doc/development/architecture.md index a641bf7d208..5eb1dcc3208 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -624,7 +624,7 @@ Mattermost is an open source, private cloud, Slack-alternative from <https://mat - Layer: Core Service (Data) - GitLab.com: [Storage Architecture](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#storage-architecture) -MinIO is an object storage server released under the GNU AGPL v3.0. It is compatible with Amazon S3 cloud storage service. It is best suited for storing unstructured data such as photos, videos, log files, backups, and container / VM images. Size of an object can range from a few KBs to a maximum of 5TB. +MinIO is an object storage server released under the GNU AGPL v3.0. It is compatible with Amazon S3 cloud storage service. It is best suited for storing unstructured data such as photos, videos, log files, backups, and container / VM images. Size of an object can range from a few KB to a maximum of 5 TB. #### NGINX diff --git a/doc/development/cascading_settings.md b/doc/development/cascading_settings.md index 1a0f0ec5b5f..1919807b81f 100644 --- a/doc/development/cascading_settings.md +++ b/doc/development/cascading_settings.md @@ -153,7 +153,7 @@ Renders the label for a checkbox setting. [`_setting_label_fieldset.html.haml`](https://gitlab.com/gitlab-org/gitlab/-/blob/c2736823b8e922e26fd35df4f0cd77019243c858/app/views/shared/namespaces/cascading_settings/_setting_label_fieldset.html.haml) -Renders the label for a fieldset setting. +Renders the label for a `fieldset` setting. | Local | Description | Type | Required (default value) | |:-----------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------------|:-------------------------| diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 209e971c952..93ff10a4132 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -155,7 +155,7 @@ with [domain expertise](#domain-experts). | `~frontend` changes (*1*) | [Frontend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_frontend). | | `~UX` user-facing changes (*3*) | [Product Designer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_UX). Refer to the [design and user interface guidelines](contributing/design.md) for details. | | Adding a new JavaScript library (*1*) | - [Frontend foundations member](https://about.gitlab.com/direction/manage/foundations/) if the library significantly increases the [bundle size](https://gitlab.com/gitlab-org/frontend/playground/webpack-memory-metrics/-/blob/master/doc/report.md).<br/>- A [legal department member](https://about.gitlab.com/handbook/legal/) if the license used by the new library hasn't been approved for use in GitLab.<br/><br/>More information about license compatibility can be found in our [GitLab Licensing and Compatibility documentation](licensing.md). | -| A new dependency or a file system change | - [Distribution team member](https://about.gitlab.com/company/team/). See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/development/enablement/systems/distribution/#how-to-work-with-distribution) for more details.<br/>- For Rubygems, request an [AppSec review](gemfile.md#request-an-appsec-review). | +| A new dependency or a file system change | - [Distribution team member](https://about.gitlab.com/company/team/). See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/development/enablement/systems/distribution/#how-to-work-with-distribution) for more details.<br/>- For RubyGems, request an [AppSec review](gemfile.md#request-an-appsec-review). | | `~documentation` or `~UI text` changes | [Technical writer](https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments) based on assignments in the appropriate [DevOps stage group](https://about.gitlab.com/handbook/product/categories/#devops-stages). | | Changes to development guidelines | Follow the [review process](development_processes.md#development-guidelines-review) and get the approvals accordingly. | | End-to-end **and** non-end-to-end changes (*4*) | [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors). | diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md index 52503f2d9c8..b568809ea4e 100644 --- a/doc/development/dangerbot.md +++ b/doc/development/dangerbot.md @@ -132,7 +132,7 @@ have had the chance to add to `helper.labels_to_add`. #### Shared rules and plugins If the rule or plugin you implement can be useful for other projects, think about -upstreaming them to the [`gitlab-dangerfiles`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-dangerfiles) project. +adding them upstream to the [`gitlab-dangerfiles`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-dangerfiles) project. #### Enable Danger on a project diff --git a/doc/development/database/adding_database_indexes.md b/doc/development/database/adding_database_indexes.md index 053747bac8c..f784d161ced 100644 --- a/doc/development/database/adding_database_indexes.md +++ b/doc/development/database/adding_database_indexes.md @@ -354,7 +354,7 @@ Use the asynchronous index helpers on your local environment to test changes for For very large tables, index destruction can be a challenge to manage. While `remove_concurrent_index` removes indexes in a way that does not block normal traffic, it can still be problematic if index destruction runs for -during autovacuum. Necessary database operations like `autovacuum` cannot run, and +during `autovacuum`. Necessary database operations like `autovacuum` cannot run, and the deployment process on GitLab.com is blocked while waiting for index destruction to finish. diff --git a/doc/development/database/avoiding_downtime_in_migrations.md b/doc/development/database/avoiding_downtime_in_migrations.md index 0b4897507de..5b6886b8a41 100644 --- a/doc/development/database/avoiding_downtime_in_migrations.md +++ b/doc/development/database/avoiding_downtime_in_migrations.md @@ -483,7 +483,7 @@ for batched background migration: To monitor the health of the database, use these additional metrics: -- [PostgreSQL Tuple Statistics](https://dashboards.gitlab.net/d/000000167/postgresql-tuple-statistics?orgId=1&refresh=1m): if you see high rate of updates for the tables being actively converted, or increasing percentage of dead tuples for this table, it might mean that autovacuum cannot keep up. +- [PostgreSQL Tuple Statistics](https://dashboards.gitlab.net/d/000000167/postgresql-tuple-statistics?orgId=1&refresh=1m): if you see high rate of updates for the tables being actively converted, or increasing percentage of dead tuples for this table, it might mean that `autovacuum` cannot keep up. - [PostgreSQL Overview](https://dashboards.gitlab.net/d/000000144/postgresql-overview?orgId=1): if you see high system usage or transactions per second (TPS) on the primary database server, it might mean that the migration is causing problems. ### Prometheus metrics @@ -504,8 +504,8 @@ If the migration has not completed, the subsequent steps fail anyway. By checkin aim to have more helpful error message. 1. Create indexes using the `bigint` columns that match the existing indexes using the `integer` column ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L28-34)). -1. Create foreign keys (FK) using the `bigint` columns that match the existing FKs using the -`integer` column. Do this both for FK referencing other tables, and FKs that reference the table +1. Create foreign keys (FK) using the `bigint` columns that match the existing FK using the +`integer` column. Do this both for FK referencing other tables, and FK that reference the table that is being migrated ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L36-43)). 1. Inside a transaction, swap the columns: 1. Lock the tables involved. To reduce the chance of hitting a deadlock, we recommended to do this in parent to child order ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L47)). @@ -514,7 +514,7 @@ that is being migrated ([see an example](https://gitlab.com/gitlab-org/gitlab/-/ 1. Swap the defaults ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L59-62)). 1. Swap the PK constraint (if any) ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L64-68)). 1. Remove old indexes and rename new ones ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L70-72)). - 1. Remove old FKs (if still present) and rename new ones ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L74)). + 1. Remove old foreign keys (if still present) and rename new ones ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L74)). See example [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66088), and [migration](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb). diff --git a/doc/development/database/background_migrations.md b/doc/development/database/background_migrations.md index fe62bbc6b14..d805686e84d 100644 --- a/doc/development/database/background_migrations.md +++ b/doc/development/database/background_migrations.md @@ -412,7 +412,7 @@ When looking at the batch execution time versus the delay time, the execution ti should fit comfortably within the delay time for a few reasons: - To allow for a variance in query times. -- To allow autovacuum to catch up after periods of high churn. +- To allow `autovacuum` to catch up after periods of high churn. Never try to optimize by fully filling the delay window even if you are confident the queries themselves have no timing variance. diff --git a/doc/development/database/database_debugging.md b/doc/development/database/database_debugging.md index 31355ef9707..edc35dd95e8 100644 --- a/doc/development/database/database_debugging.md +++ b/doc/development/database/database_debugging.md @@ -107,7 +107,7 @@ The new connection should be working now. Use these instructions for exploring the GitLab database while developing with the GDK: 1. Install or open [Visual Studio Code](https://code.visualstudio.com/download). -1. Install the [PostgreSQL VSCode Extension](https://marketplace.visualstudio.com/items?itemName=ckolkman.vscode-postgres). +1. Install the [PostgreSQL VS Code Extension](https://marketplace.visualstudio.com/items?itemName=ckolkman.vscode-postgres). 1. In Visual Studio Code select **PostgreSQL Explorer** in the left toolbar. 1. In the top bar of the new window, select `+` to **Add Database Connection**, and follow the prompts to fill in the details: 1. **Hostname**: the path to the PostgreSQL folder in your GDK directory (for example `/dev/gitlab-development-kit/postgresql`). diff --git a/doc/development/database/efficient_in_operator_queries.md b/doc/development/database/efficient_in_operator_queries.md index 0f65dcfef9e..8badc4fb9d3 100644 --- a/doc/development/database/efficient_in_operator_queries.md +++ b/doc/development/database/efficient_in_operator_queries.md @@ -126,8 +126,7 @@ For very large groups the database queries can easily time out, causing HTTP 500 ## Optimizing ordered `IN` queries -In the talk -["How to teach an elephant to dance rock'n'roll"](https://www.youtube.com/watch?v=Ha38lcjVyhQ), +In the talk ["How to teach an elephant to dance rock'n'roll"](https://www.youtube.com/watch?v=Ha38lcjVyhQ), Maxim Boguk demonstrated a technique to optimize a special class of ordered `IN` queries, such as our ordered group-level queries. @@ -918,11 +917,11 @@ the `LIMIT` is reached or no more data can be found. Here's an outline of the steps we take in the recursive CTE query (expressing the steps in SQL is non-trivial but is explained next): -1. Sort the initial resultset according to the `ORDER BY` clause. +1. Sort the initial `resultset` according to the `ORDER BY` clause. 1. Pick the top cursor to fetch the record, this is our first record. In the example, this cursor would be (`2020-01-05`, `3`) for `project_id=9`. 1. We can use (`2020-01-05`, `3`) to fetch the next issue respecting the `ORDER BY` clause -`project_id=9` filter. This produces an updated resultset. +`project_id=9` filter. This produces an updated `resultset`. | `project_ids` | `created_at_values` | `id_values` | | ------------- | ------------------- | ----------- | @@ -931,7 +930,7 @@ this cursor would be (`2020-01-05`, `3`) for `project_id=9`. | 10 | 2020-01-15 | 7 | | **9** | **2020-01-06** | **6** | -1. Repeat 1 to 3 with the updated resultset until we have fetched `N=20` records. +1. Repeat 1 to 3 with the updated `resultset` until we have fetched `N=20` records. ### Initializing the recursive CTE query diff --git a/doc/development/database/keyset_pagination.md b/doc/development/database/keyset_pagination.md index 21bce41012e..42d7458b45a 100644 --- a/doc/development/database/keyset_pagination.md +++ b/doc/development/database/keyset_pagination.md @@ -159,7 +159,7 @@ configuration is necessary: - Function-based ordering. - Ordering with a custom tie-breaker column, like `iid`. -These order objects can be defined in the model classes as normal ActiveRecord scopes, there is no special behavior that prevents using these scopes elsewhere (kaminari, background jobs). +These order objects can be defined in the model classes as normal ActiveRecord scopes, there is no special behavior that prevents using these scopes elsewhere (Kaminari, background jobs). ### `NULLS LAST` ordering diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md index 962cd2602bc..a618a1ffdee 100644 --- a/doc/development/database/loose_foreign_keys.md +++ b/doc/development/database/loose_foreign_keys.md @@ -134,7 +134,7 @@ scripts/decomposition/generate-loose-foreign-key -c ci_job_token_project_scope_l ``` To swap all the foreign keys (all having `_id` appended), but not create a new branch (only commit -the changes) and not create rspecs, run: +the changes) and not create RSpec tests, run: ```shell scripts/decomposition/generate-loose-foreign-key -c --no-branch --no-rspec _id diff --git a/doc/development/database/pagination_performance_guidelines.md b/doc/development/database/pagination_performance_guidelines.md index 0f98b50d95c..b06839979da 100644 --- a/doc/development/database/pagination_performance_guidelines.md +++ b/doc/development/database/pagination_performance_guidelines.md @@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Pagination performance guidelines -The following document gives a few ideas for improving the pagination (sorting) performance. These apply both on [offset](pagination_guidelines.md#offset-pagination) and [keyset](pagination_guidelines.md#keyset-pagination) paginations. +The following document gives a few ideas for improving the pagination (sorting) performance. These apply both on [offset](pagination_guidelines.md#offset-pagination) and [keyset](pagination_guidelines.md#keyset-pagination) pagination. ## Tie-breaker column diff --git a/doc/development/database/polymorphic_associations.md b/doc/development/database/polymorphic_associations.md index f3c9bf1276f..bb7eb46b448 100644 --- a/doc/development/database/polymorphic_associations.md +++ b/doc/development/database/polymorphic_associations.md @@ -98,10 +98,10 @@ AND source_id = 4 Instead such a table should be broken up into separate tables. For example, you may end up with 4 tables in this case: -- project_members -- group_members -- pending_project_members -- pending_group_members +- `project_members` +- `group_members` +- `pending_project_members` +- `pending_group_members` This makes querying data trivial. For example, to get the members of a group you'd run: diff --git a/doc/development/database/understanding_explain_plans.md b/doc/development/database/understanding_explain_plans.md index fff9d755e9a..094bd6b346f 100644 --- a/doc/development/database/understanding_explain_plans.md +++ b/doc/development/database/understanding_explain_plans.md @@ -826,4 +826,4 @@ A more extensive guide on understanding query plans can be found in the [presentation](https://public.dalibo.com/exports/conferences/_archives/_2012/201211_explain/understanding_explain.pdf) from [Dalibo.org](https://www.dalibo.com/en/). -Depesz's blog also has a good [section](https://www.depesz.com/tag/unexplainable/) dedicated to query plans. +The Depesz blog also has a good [section](https://www.depesz.com/tag/unexplainable/) dedicated to query plans. diff --git a/doc/development/database_review.md b/doc/development/database_review.md index 7fbc48af91c..e66be062986 100644 --- a/doc/development/database_review.md +++ b/doc/development/database_review.md @@ -150,7 +150,7 @@ Include in the MR description: - Write the raw SQL in the MR description. Preferably formatted nicely with [pgFormatter](https://sqlformat.darold.net) or - [paste.depesz.com](https://paste.depesz.com) and using regular quotes + <https://paste.depesz.com> and using regular quotes <!-- vale gitlab.NonStandardQuotes = NO --> (for example, `"projects"."id"`) and avoiding smart quotes (for example, `“projects”.“id”`). <!-- vale gitlab.NonStandardQuotes = YES --> diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md index f51197575b2..cd87704dda3 100644 --- a/doc/development/documentation/styleguide/index.md +++ b/doc/development/documentation/styleguide/index.md @@ -158,7 +158,7 @@ also aid in consistency, which is important for localization. All GitLab documentation is written using [Markdown](https://en.wikipedia.org/wiki/Markdown). The [documentation website](https://docs.gitlab.com) uses [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown), -a "flavored" Kramdown engine to render pages from Markdown to HTML. The use of Kramdown's +a "flavored" Kramdown engine to render pages from Markdown to HTML. The use of Kramdown features is limited by our linters, so, use regular Markdown and follow the rules in the linked style guide. You can't use Kramdown-specific markup (for example, `{:.class}`). @@ -396,8 +396,12 @@ when published. Example: ### Emphasis +<!-- vale gitlab.Spelling = NO --> + Use **bold** rather than italic to provide emphasis. GitLab uses a sans-serif font and italic text does not stand out as much as it would in a serif font. For details, see [Butterick's Practical Typography guide on bold or italic](https://practicaltypography.com/bold-or-italic.html). +<!-- vale gitlab.Spelling = YES --> + You can use italics when you are introducing a term for the first time. Otherwise, use bold. - Use double asterisks (`**`) to mark a word or text in bold (`**bold**`). diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index 8ddc4c21af9..cef42c56bb0 100644 --- a/doc/development/elasticsearch.md +++ b/doc/development/elasticsearch.md @@ -113,9 +113,9 @@ Uses a [Pattern Capture token filter](https://www.elastic.co/guide/en/elasticsea Patterns: -- `"(\\p{Ll}+|\\p{Lu}\\p{Ll}+|\\p{Lu}+)"`: captures CamelCased and lowedCameCased strings as separate tokens +- `"(\\p{Ll}+|\\p{Lu}\\p{Ll}+|\\p{Lu}+)"`: captures CamelCase and lowerCamelCase strings as separate tokens - `"(\\d+)"`: extracts digits -- `"(?=([\\p{Lu}]+[\\p{L}]+))"`: captures CamelCased strings recursively. For example: `ThisIsATest` => `[ThisIsATest, IsATest, ATest, Test]` +- `"(?=([\\p{Lu}]+[\\p{L}]+))"`: captures CamelCase strings recursively. For example: `ThisIsATest` => `[ThisIsATest, IsATest, ATest, Test]` - `'"((?:\\"|[^"]|\\")*)"'`: captures terms inside quotes, removing the quotes - `"'((?:\\'|[^']|\\')*)'"`: same as above, for single-quotes - `'\.([^.]+)(?=\.|\s|\Z)'`: separate terms with periods in-between diff --git a/doc/development/fe_guide/accessibility.md b/doc/development/fe_guide/accessibility.md index 67166a93cb4..af45603782f 100644 --- a/doc/development/fe_guide/accessibility.md +++ b/doc/development/fe_guide/accessibility.md @@ -109,15 +109,15 @@ Text input examples: </gl-form-group> ``` -Textarea examples: +`textarea` examples: ```html -<!-- Textarea with label --> +<!-- textarea with label --> <gl-form-group :label="__('Issue description')" label-for="issue-description"> <gl-form-textarea id="issue-description" v-model="description" /> </gl-form-group> -<!-- Textarea with hidden label --> +<!-- textarea with hidden label --> <gl-form-group :label="__('Issue description')" label-for="issue-description" label-sr-only> <gl-form-textarea id="issue-description" v-model="description" /> </gl-form-group> @@ -347,7 +347,7 @@ Keep in mind that: See the [Pajamas Keyboard-only page](https://design.gitlab.com/accessibility-audits/keyboard-only/) for more detail. -## Tabindex +## `tabindex` Prefer **no** `tabindex` to using `tabindex`, since: diff --git a/doc/development/fe_guide/content_editor.md b/doc/development/fe_guide/content_editor.md index 8cc274c732e..982033cf2ad 100644 --- a/doc/development/fe_guide/content_editor.md +++ b/doc/development/fe_guide/content_editor.md @@ -11,7 +11,7 @@ experience for [GitLab Flavored Markdown](../../user/markdown.md) in the GitLab It also serves as the foundation for implementing Markdown-focused editors that target other engines, like static site generators. -We use [tiptap 2.0](https://tiptap.dev/) and [ProseMirror](https://prosemirror.net/) +We use [Tiptap 2.0](https://tiptap.dev/) and [ProseMirror](https://prosemirror.net/) to build the Content Editor. These frameworks provide a level of abstraction on top of the native [`contenteditable`](https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content) web technology. @@ -209,7 +209,7 @@ the following events: - `blur` - `error`. -Learn more about these events in [Tiptap's event guide](https://tiptap.dev/api/events/). +Learn more about these events in [the Tiptap event guide](https://tiptap.dev/api/events/). ```html <script> @@ -255,13 +255,13 @@ provides all the necessary extensions to support #### Implement new extensions Extensions are the building blocks of the Content Editor. You can learn how to implement -new ones by reading [Tiptap's guide](https://tiptap.dev/guide/custom-extensions). +new ones by reading [the Tiptap guide](https://tiptap.dev/guide/custom-extensions). We recommend checking the list of built-in [nodes](https://tiptap.dev/api/nodes) and [marks](https://tiptap.dev/api/marks) before implementing a new extension from scratch. Store the Content Editor extensions in the `~/content_editor/extensions` directory. -When using a Tiptap's built-in extension, wrap it in a ES6 module inside this directory: +When using a Tiptap built-in extension, wrap it in a ES6 module inside this directory: ```javascript export { Bold as default } from '@tiptap/extension-bold'; @@ -326,10 +326,10 @@ sequenceDiagram A->>E: setContent(document) ``` -Deserializers live in the extension modules. Read Tiptap's -[parseHTML](https://tiptap.dev/guide/custom-extensions#parse-html) and -[addAttributes](https://tiptap.dev/guide/custom-extensions#attributes) documentation to -learn how to implement them. Titap's API is a wrapper around ProseMirror's +Deserializers live in the extension modules. Read Tiptap documentation about +[`parseHTML`](https://tiptap.dev/guide/custom-extensions#parse-html) and +[`addAttributes`](https://tiptap.dev/guide/custom-extensions#attributes) to +learn how to implement them. The Tiptap API is a wrapper around ProseMirror's [schema spec API](https://prosemirror.net/docs/ref/#model.SchemaSpec). #### Serialization diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md index fc91ff55b24..232689080ea 100644 --- a/doc/development/fe_guide/development_process.md +++ b/doc/development/fe_guide/development_process.md @@ -45,7 +45,7 @@ Use your best judgment when to use it and contribute new points through merge re - [ ] Check off tasks on your created task list to keep everyone updated on the progress - [ ] [Share your work early with reviewers/maintainers](#share-your-work-early) -- [ ] Share your work with UXer and Product Manager with Screenshots and/or [GIF's](https://about.gitlab.com/handbook/product/making-gifs/). They are easy to create for you and keep them up to date. +- [ ] Share your work with UXer and Product Manager with Screenshots and/or [GIF images](https://about.gitlab.com/handbook/product/making-gifs/). They are easy to create for you and keep them up to date. - [ ] If you are blocked on something let everyone on the issue know through a comment. - [ ] Are you unable to work on this issue for a longer period of time, also let everyone know. - [ ] **Documentation** Update/add docs for the new feature, see `docs/`. Ping one of the documentation experts/reviewers @@ -58,7 +58,7 @@ Use your best judgment when to use it and contribute new points through merge re - [ ] Did you check the mobile view? - [ ] Check the built webpack bundle (For the report run `WEBPACK_REPORT=true gdk start`, then open `webpack-report/index.html`) if we have unnecessary bloat due to wrong references, including libraries multiple times, etc.. If you need help contact the webpack [domain expert](https://about.gitlab.com/handbook/engineering/frontend/#frontend-domain-experts) - [ ] **Tests** Not only greenfield tests - Test also all bad cases that come to your mind. -- [ ] If you have multiple MR's then also smoke test against the final merge. +- [ ] If you have multiple MRs then also smoke test against the final merge. - [ ] Are there any big changes on how and especially how frequently we use the API then let production know about it - [ ] Smoke test of the RC on dev., staging., canary deployments and .com - [ ] Follow up on issues that came out of the review. Create issues for discovered edge cases that should be covered in future iterations. diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md index 4c0259638d0..0fec38b1200 100644 --- a/doc/development/fe_guide/graphql.md +++ b/doc/development/fe_guide/graphql.md @@ -109,7 +109,7 @@ Default client accepts two parameters: `resolvers` and `config`. If you are making multiple queries to the same Apollo client object you might encounter the following error: `Cache data may be lost when replacing the someProperty field of a Query object. To address this problem, either ensure all objects of SomeEntityhave an id or a custom merge function`. We are already checking `ID` presence for every GraphQL type that has an `ID`, so this shouldn't be the case. Most likely, the `SomeEntity` type doesn't have an `ID` property, and to fix this warning we need to define a custom merge function. -We have some client-wide types with `merge: true` defined in the default client as [typePolicies](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/lib/graphql.js) (this means that Apollo will merge existing and incoming responses in the case of subsequent queries). Consider adding `SomeEntity` there or defining a custom merge function for it. +We have some client-wide types with `merge: true` defined in the default client as [`typePolicies`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/lib/graphql.js) (this means that Apollo will merge existing and incoming responses in the case of subsequent queries). Consider adding `SomeEntity` there or defining a custom merge function for it. ## GraphQL Queries diff --git a/doc/development/fe_guide/style/javascript.md b/doc/development/fe_guide/style/javascript.md index 38fb926197b..0536d1c5c77 100644 --- a/doc/development/fe_guide/style/javascript.md +++ b/doc/development/fe_guide/style/javascript.md @@ -7,7 +7,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/development/fe_guide/style_guide_ # JavaScript style guide -We use [Airbnb's JavaScript Style Guide](https://github.com/airbnb/javascript) and its accompanying +We use [the Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) and its accompanying linter to manage most of our JavaScript style guidelines. In addition to the style guidelines set by Airbnb, we also have a few specific rules @@ -16,11 +16,11 @@ listed below. NOTE: You can run ESLint locally by running `yarn run lint:eslint:all` or `yarn run lint:eslint $PATH_TO_FILE`. -## Avoid forEach +## Avoid `forEach` -Avoid forEach when mutating data. Use `map`, `reduce` or `filter` instead of `forEach` +Avoid `forEach` when mutating data. Use `map`, `reduce` or `filter` instead of `forEach` when mutating data. This minimizes mutations in functions, -which aligns with [Airbnb's style guide](https://github.com/airbnb/javascript#testing--for-real). +which aligns with [the Airbnb style guide](https://github.com/airbnb/javascript#testing--for-real). ```javascript // bad diff --git a/doc/development/fe_guide/style/scss.md b/doc/development/fe_guide/style/scss.md index c20ade6bc1d..7a5c955db93 100644 --- a/doc/development/fe_guide/style/scss.md +++ b/doc/development/fe_guide/style/scss.md @@ -43,7 +43,7 @@ result (such as `ml-1` becoming `gl-ml-2`). #### Where should you put new utility classes? -If a class you need has not been added to GitLab UI, you get to add it! Follow the naming patterns documented in the [utility files](https://gitlab.com/gitlab-org/gitlab-ui/-/tree/main/src/scss/utility-mixins) and refer to [GitLab UI's CSS documentation](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/doc/contributing/adding_css.md#adding-utility-mixins) for more details, especially about adding responsive and stateful rules. +If a class you need has not been added to GitLab UI, you get to add it! Follow the naming patterns documented in the [utility files](https://gitlab.com/gitlab-org/gitlab-ui/-/tree/main/src/scss/utility-mixins) and refer to the [GitLab UI CSS documentation](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/doc/contributing/adding_css.md#adding-utility-mixins) for more details, especially about adding responsive and stateful rules. If it is not possible to wait for a GitLab UI update (generally one day), add the class to [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/utilities.scss) following the same naming conventions documented in GitLab UI. A follow-up issue to backport the class to GitLab UI and delete it from GitLab should be opened. diff --git a/doc/development/fe_guide/tooling.md b/doc/development/fe_guide/tooling.md index c9efb8e939d..762ef852d74 100644 --- a/doc/development/fe_guide/tooling.md +++ b/doc/development/fe_guide/tooling.md @@ -212,7 +212,7 @@ yarn run lint:prettier:fix Formats all files in the repository with Prettier. -### VSCode Settings +### VS Code Settings #### Select Prettier as default formatter diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index 19bbfa314ea..362998c16af 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -431,7 +431,7 @@ export default { Refer to [Vuex documentation](https://vuex.vuejs.org/guide/testing.html) regarding testing Actions, Getters and Mutations. -#### Testing components that need a store +#### Testing components that need a store Smaller components might use `store` properties to access the data. To write unit tests for those components, we need to include the store and provide the correct state: diff --git a/doc/development/fe_guide/widgets.md b/doc/development/fe_guide/widgets.md index 3364c778d76..edb8559da48 100644 --- a/doc/development/fe_guide/widgets.md +++ b/doc/development/fe_guide/widgets.md @@ -44,7 +44,7 @@ All editable sidebar widgets should use [`SidebarEditableItem`](https://gitlab.c We aim to make widgets as reusable as possible. That's why we should avoid adding any external state bindings to widgets or to their child components. This includes Vuex mappings and mediator stores. -## Widget's responsibility +## Widget responsibility A widget is responsible for fetching and updating an entity it's designed for (assignees, iterations, and so on). This means a widget should **always** fetch data (if it's not in Apollo cache already). @@ -78,7 +78,7 @@ To handle the same logic for query updates, we **alias** query fields. For examp - `group` or `project` become `workspace` - `issue`, `epic`, or `mergeRequest` become `issuable` -Unfortunately, Apollo assigns aliased fields a typename of `undefined`, so we need to fetch `__typename` explicitly: +Unfortunately, Apollo assigns aliased fields a `typename` of `undefined`, so we need to fetch `__typename` explicitly: ```plaintext query issueConfidential($fullPath: ID!, $iid: String) { diff --git a/doc/development/feature_development.md b/doc/development/feature_development.md index 645505b2da1..b9e093b9479 100644 --- a/doc/development/feature_development.md +++ b/doc/development/feature_development.md @@ -127,7 +127,7 @@ See [database guidelines](database/index.md). - [Security Scanners](integrations/secure.md) - [Secure Partner Integration](integrations/secure_partner_integration.md) - [How to run Jenkins in development environment](integrations/jenkins.md) -- [How to run local `Codesandbox` integration for Web IDE Live Preview](integrations/codesandbox.md) +- [How to run local CodeSandbox integration for Web IDE Live Preview](integrations/codesandbox.md) The following integration guides are internal. Some integrations require access to administrative accounts of third-party services and are available only for GitLab team members to contribute to: diff --git a/doc/development/git_object_deduplication.md b/doc/development/git_object_deduplication.md index dcfcd2e864a..6014ccbfb39 100644 --- a/doc/development/git_object_deduplication.md +++ b/doc/development/git_object_deduplication.md @@ -171,7 +171,7 @@ There are three different things that can go wrong here. #### 1. SQL says repository A belongs to pool P but Gitaly says A has no alternate objects -In this case, we miss out on disk space savings but all RPC's on A +In this case, we miss out on disk space savings but all RPCs on A itself function fine. The next time garbage collection runs on A, the alternates connection gets established in Gitaly. This is done by `Projects::GitDeduplicationService` in GitLab Rails. diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index a570b5dd7eb..a23f1dd2d80 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -56,7 +56,7 @@ they are merged. ### `gitaly-ruby` -It is possible to implement and test RPC's in Gitaly using Ruby code, +It is possible to implement and test RPCs in Gitaly using Ruby code, in [`gitaly-ruby`](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby). This should make it easier to contribute for developers who are less @@ -324,7 +324,7 @@ the integration by using GDK: 1. The state of the flag must be observable. To check it, you must enable it by fetching the Prometheus metrics: - 1. Navigate to GDK's root directory. + 1. Navigate to the GDK root directory. 1. Make sure you have the proper branch checked out for Gitaly. 1. Recompile it with `make gitaly-setup` and restart the service with `gdk restart gitaly`. 1. Make sure your setup is running: `gdk status | grep praefect`. @@ -342,7 +342,7 @@ the integration by using GDK: 1. After you observe the metrics for the new feature flag and it increments, you can enable the new feature: - 1. Navigate to GDK's root directory. + 1. Navigate to the GDK root directory. 1. Start a Rails console: ```shell diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md index edf78d5f83d..17b4a28f57d 100644 --- a/doc/development/github_importer.md +++ b/doc/development/github_importer.md @@ -192,7 +192,7 @@ briefly waits for jobs to complete before deciding what the next action should be. For small projects, this may slow down the import process a bit, but it also reduces pressure on the system as a whole. -## Refreshing import JIDs +## Refreshing import job IDs GitLab includes a worker called `Gitlab::Import::StuckProjectImportJobsWorker` that periodically runs and marks project imports as failed if they have been @@ -203,7 +203,7 @@ often we hit the GitHub rate limit (more on this below), but we don't want To prevent this from happening we periodically refresh the expiration time of the import process. This works by storing the JID of the import job in the -database, then refreshing this JID's TTL at various stages throughout the import +database, then refreshing this JID TTL at various stages throughout the import process. This is done by calling `ProjectImportState#refresh_jid_expiration`. By refreshing this TTL we can ensure our import does not get marked as failed so long we're still performing work. diff --git a/doc/development/gitlab_flavored_markdown/specification_guide/index.md b/doc/development/gitlab_flavored_markdown/specification_guide/index.md index b72f3c14350..85c6653180b 100644 --- a/doc/development/gitlab_flavored_markdown/specification_guide/index.md +++ b/doc/development/gitlab_flavored_markdown/specification_guide/index.md @@ -157,7 +157,7 @@ official specifications, but are part of the GitHub and GitLab internal Markdown implementations. These internal extensions are often dependent upon the GitHub or GitLab implementations or environments, and may depend upon metadata which is only available via interacting with those environments. For example, -[GitHub supports GitHub-specific autolinked references](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls), +[GitHub supports GitHub-specific automatically linked references](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls), and [GitLab also supports GitLab-specific references](../../../user/markdown.md#gitlab-specific-references). These may also be implemented by third-party Markdown rendering engines which integrate with @@ -1149,7 +1149,7 @@ These files are Markdown specification files containing examples generated based similar to the `output_spec/spec.txt` and `output_spec/spec.html`, with the following differences: 1. They contain a superset of _all_ examples from - the Commonmark, GitHub Flavored Markdown, and GitLab Flavored Markdown specifications, whereas + the CommonMark, GitHub Flavored Markdown, and GitLab Flavored Markdown specifications, whereas `spec.*` only contains the GLFM specification. This is to provide a single place to refer to all examples when working with [snapshot testing](#markdown-snapshot-testing). 1. They contain _only_ header sections which contain examples. They do not contain any prose-only diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md index b561ebc4285..e7e628f5293 100644 --- a/doc/development/go_guide/index.md +++ b/doc/development/go_guide/index.md @@ -391,7 +391,7 @@ functionality: This gives us a thin abstraction over underlying implementations that is consistent across Workhorse, Gitaly, and, in future, other Go servers. For example, in the case of `gitlab.com/gitlab-org/labkit/tracing` we can switch -from using `Opentracing` directly to using `Zipkin` or Gokit's own tracing wrapper +from using `Opentracing` directly to using `Zipkin` or the Go kit's own tracing wrapper without changes to the application code, while still keeping the same consistent configuration mechanism (that is, the `GITLAB_TRACING` environment variable). diff --git a/doc/development/image_scaling.md b/doc/development/image_scaling.md index a1a5e9122c6..502a18fecd7 100644 --- a/doc/development/image_scaling.md +++ b/doc/development/image_scaling.md @@ -26,7 +26,7 @@ Whether we allow an image to be rescaled or not is decided by combination of har The hard-coded rules only permit: - [Project, group and user avatars](https://gitlab.com/gitlab-org/gitlab/-/blob/fd08748862a5fe5c25b919079858146ea85843ae/app/controllers/concerns/send_file_upload.rb#L65-67) -- [PNGs or JPEGs](https://gitlab.com/gitlab-org/gitlab/-/blob/5dff8fa3814f2a683d8884f468cba1ec06a60972/lib/gitlab/file_type_detection.rb#L23) +- [PNG or JPEG images](https://gitlab.com/gitlab-org/gitlab/-/blob/5dff8fa3814f2a683d8884f468cba1ec06a60972/lib/gitlab/file_type_detection.rb#L23) - [Specific dimensions](https://gitlab.com/gitlab-org/gitlab/-/blob/5dff8fa3814f2a683d8884f468cba1ec06a60972/app/models/concerns/avatarable.rb#L6) Furthermore, configuration in Workhorse can lead to the image scaler rejecting a request if: diff --git a/doc/development/integrations/codesandbox.md b/doc/development/integrations/codesandbox.md index d7d0ea48db0..b7fe3fbd1c4 100644 --- a/doc/development/integrations/codesandbox.md +++ b/doc/development/integrations/codesandbox.md @@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Set up local CodeSandbox development environment This guide walks through setting up a local [CodeSandbox repository](https://github.com/codesandbox/codesandbox-client) and integrating it with a local GitLab instance. CodeSandbox -is used to power the Web IDE's [Live Preview feature](../../user/project/web_ide/index.md#live-preview). Having a local CodeSandbox setup is useful for debugging upstream issues or +is used to power the Web IDE [Live Preview feature](../../user/project/web_ide/index.md#live-preview). Having a local CodeSandbox setup is useful for debugging upstream issues or creating upstream contributions like [this one](https://github.com/codesandbox/codesandbox-client/pull/5137). ## Initial setup @@ -43,7 +43,7 @@ Before using CodeSandbox with your local GitLab instance, you must: GitLab integrates with two parts of CodeSandbox: - An npm package called `smooshpack` (called `sandpack` in the `codesandbox-client` project). - This exposes an entrypoint for us to kick off Codesandbox's bundler. + This exposes an entrypoint for us to kick off CodeSandbox's bundler. - A server that houses CodeSandbox assets for bundling and previewing. This is hosted on a separate server for security. diff --git a/doc/development/integrations/index.md b/doc/development/integrations/index.md index 2639da818c6..8c715a0459a 100644 --- a/doc/development/integrations/index.md +++ b/doc/development/integrations/index.md @@ -58,7 +58,7 @@ end `Integration.prop_accessor` installs accessor methods on the class. Here we would have `#url`, `#url=` and `#url_changed?`, to manage the `url` field. Fields stored in `Integration#properties` should be accessed by these accessors directly on the model, just like other ActiveRecord attributes. -You should always access the properties through their getters, and not interact with the `properties` hash directly. +You should always access the properties through their `getters`, and not interact with the `properties` hash directly. You **must not** write to the `properties` hash, you **must** use the generated setter method instead. Direct writes to this hash are not persisted. diff --git a/doc/development/integrations/jira_connect.md b/doc/development/integrations/jira_connect.md index d4215662db4..a03667be7cc 100644 --- a/doc/development/integrations/jira_connect.md +++ b/doc/development/integrations/jira_connect.md @@ -68,7 +68,7 @@ If the app install failed, you might need to delete `jira_connect_installations` #### Not authorized to access the file -If you use Gitpod and you get an error about Jira not being able to access the descriptor file, you might need to make the GDK's port public by following these steps: +If you use Gitpod and you get an error about Jira not being able to access the descriptor file, you might need to make the GDK port public by following these steps: 1. Open your GitLab workspace in Gitpod. 1. When the GDK is running, select **Ports** in the bottom-right corner. diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md index 6e505fa0d19..a482b16e9cb 100644 --- a/doc/development/migration_style_guide.md +++ b/doc/development/migration_style_guide.md @@ -338,7 +338,7 @@ is concurrently accessed and modified by other processes, acquiring the lock may a while. The lock request is waiting in a queue and it may also block other queries on the `users` table once it has been enqueued. -More information about PostgresSQL locks: [Explicit Locking](https://www.postgresql.org/docs/current/explicit-locking.html) +More information about PostgreSQL locks: [Explicit Locking](https://www.postgresql.org/docs/current/explicit-locking.html) For stability reasons, GitLab.com has a specific [`statement_timeout`](../user/gitlab_com/index.md#postgresql) set. When the migration is invoked, any database query has @@ -813,7 +813,7 @@ in the `namespaces` table. Only when creating a new column with a default, all t NOTE: A faster [ALTER TABLE ADD COLUMN with a non-null default](https://www.depesz.com/2018/04/04/waiting-for-postgresql-11-fast-alter-table-add-column-with-a-non-null-default/) -was introduced on PostgresSQL 11.0, removing the need of rewriting the table when a new column with a default value is added. +was introduced on PostgreSQL 11.0, removing the need of rewriting the table when a new column with a default value is added. For the reasons mentioned above, it's safe to use `change_column_default` in a single-transaction migration without requiring `disable_ddl_transaction!`. diff --git a/doc/development/packages/dependency_proxy.md b/doc/development/packages/dependency_proxy.md index d5cc219cba0..1386889a43f 100644 --- a/doc/development/packages/dependency_proxy.md +++ b/doc/development/packages/dependency_proxy.md @@ -143,7 +143,7 @@ Management of file uploads and caching happens in [Workhorse](../workhorse/index [`POST` routes](https://gitlab.com/gitlab-org/gitlab/-/blob/3f76455ac9cf90a927767e55c837d6b07af818df/config/routes/group.rb#L170-173) that we have for the Dependency Proxy. -The [send_dependency](https://gitlab.com/gitlab-org/gitlab/-/blob/7359d23f4e078479969c872924150219c6f1665f/app/helpers/workhorse_helper.rb#L46-53) +The [`send_dependency`](https://gitlab.com/gitlab-org/gitlab/-/blob/7359d23f4e078479969c872924150219c6f1665f/app/helpers/workhorse_helper.rb#L46-53) method makes a request to Workhorse including the previously fetched JWT from the external registry. Workhorse then can use that token to request the manifest or blob the user originally requested. The Workhorse code lives in [`workhorse/internal/dependencyproxy/dependencyproxy.go`](https://gitlab.com/gitlab-org/gitlab/-/blob/b8f44a8f3c26efe9932c2ada2df75ef7acb8417b/workhorse/internal/dependencyproxy/dependencyproxy.go#L4). diff --git a/doc/development/pages/index.md b/doc/development/pages/index.md index 6ee8a9ac433..5e56264330a 100644 --- a/doc/development/pages/index.md +++ b/doc/development/pages/index.md @@ -178,7 +178,7 @@ The `redirect-uri` must not contain any GitLab Pages site domain. auth-redirect-uri=http://pages.gdk.test:3010/auth # the authentication callback url for GitLab Pages ``` -1. If running Pages inside the GDK, you can use GDK's `protected_config_files` section under `gdk` in +1. If running Pages inside the GDK, you can use GDK `protected_config_files` section under `gdk` in your `gdk.yml` to avoid getting `gitlab-pages.conf` configuration rewritten: ```yaml diff --git a/doc/development/product_qualified_lead_guide/index.md b/doc/development/product_qualified_lead_guide/index.md index 89a05d59fc9..f8cd7fd48b9 100644 --- a/doc/development/product_qualified_lead_guide/index.md +++ b/doc/development/product_qualified_lead_guide/index.md @@ -17,7 +17,7 @@ A hand-raise PQL is a user who requests to speak to sales from within the produc 1. Set up CustomersDot using the [normal install instructions](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/setup/installation_steps.md). 1. Set the `CUSTOMER_PORTAL_URL` environment variable to your local (or ngrok) URL of your CustomersDot instance. -1. Place `export CUSTOMER_PORTAL_URL='https://XXX.ngrok.io/'` in your shell rc script (`~/.zshrc` or `~/.bash_profile` or `~/.bashrc`) and restart GDK. +1. Place `export CUSTOMER_PORTAL_URL='https://XXX.ngrok.io/'` in your shell `rc` script (`~/.zshrc` or `~/.bash_profile` or `~/.bashrc`) and restart GDK. 1. Enter the credentials on CustomersDot development to Platypus in your `/config/secrets.yml` and restart. Credentials for the Platypus Staging are in the 1Password Growth vault. The URL for staging is `https://staging.ci.nexus.gitlabenvironment.cloud`. ```yaml @@ -144,7 +144,7 @@ sequenceDiagram ``` -#### Trial lead flow on CustomersDot (sync_to_gl) +#### Trial lead flow on CustomersDot (`sync_to_gl`) ```mermaid sequenceDiagram diff --git a/doc/development/projections.md b/doc/development/projections.md index 49480981d8d..7c727fc0901 100644 --- a/doc/development/projections.md +++ b/doc/development/projections.md @@ -24,7 +24,7 @@ You can find a basic list of projection options in - vim - [vim-projectionist](https://github.com/tpope/vim-projectionist) -- VSCode +- VS Code - [Alternate File](https://marketplace.visualstudio.com/items?itemName=will-wow.vscode-alternate-file) - [projectionist](https://github.com/jarsen/projectionist) - [`jumpto`](https://github.com/gmdayley/jumpto) diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md index 3239748193f..9e3b1f58abe 100644 --- a/doc/development/reactive_caching.md +++ b/doc/development/reactive_caching.md @@ -208,7 +208,7 @@ There are some `class_attribute` options which can be tweaked. self.reactive_cache_key = ->(integration) { [integration.class.model_name.singular, integration.project_id] } ``` - If your reactive_cache_key is exactly like the above, you can use the existing + If your `reactive_cache_key` is exactly like the above, you can use the existing `Integrations::ReactivelyCached` concern instead. #### `self.reactive_cache_lease_timeout` diff --git a/doc/development/sec/index.md b/doc/development/sec/index.md index fc13c960451..3f52020701f 100644 --- a/doc/development/sec/index.md +++ b/doc/development/sec/index.md @@ -102,15 +102,15 @@ After being [merged](../integrations/secure.md#tracking-and-merging-vulnerabilit ### Analyzer vulnerability translation -In the case of SAST's semgrep analyzer, there is a secondary identifier of particular importance: the identifier linking the report’s vulnerability -to the legacy analyzer (that is, bandit or eslint). +In the case of the SAST Semgrep analyzer, there is a secondary identifier of particular importance: the identifier linking the report’s vulnerability +to the legacy analyzer (that is, bandit or ESLint). To [enable vulnerability translation](../../user/application_security/sast/analyzers.md#vulnerability-translation) -the semgrep analyzer relies on a secondary identifier exactly matching the primary identifier of the legacy analyzer. +the Semgrep analyzer relies on a secondary identifier exactly matching the primary identifier of the legacy analyzer. For example, when [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) was previously used to generate vulnerability records, the [`semgrep`](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) analyzer must produce an identifier collection containing the -original eslint primary identifier. +original ESLint primary identifier. Given the original `eslint` report: @@ -131,7 +131,7 @@ Given the original `eslint` report: } ``` -The corresponding semgrep report must contain the `eslint_rule_id`: +The corresponding Semgrep report must contain the `eslint_rule_id`: ```json { diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md index 471c93c3baa..bccdda9ca04 100644 --- a/doc/development/secure_coding_guidelines.md +++ b/doc/development/secure_coding_guidelines.md @@ -1209,7 +1209,7 @@ These types of bugs are often seen in environments which allow multi-threading a ### Examples -**Example 1:** you have a model which accepts a URL as input. When the model is created you verify that the URL's host resolves to a public IP address, to prevent attackers making internal network calls. But DNS records can change ([DNS rebinding](#server-side-request-forgery-ssrf)]). An attacker updates the DNS record to `127.0.0.1`, and when your code resolves those URL's host it results in sending a potentially malicious request to a server on the internal network. The property was valid at the "time of check", but invalid and malicious at "time of use". +**Example 1:** you have a model which accepts a URL as input. When the model is created you verify that the URL host resolves to a public IP address, to prevent attackers making internal network calls. But DNS records can change ([DNS rebinding](#server-side-request-forgery-ssrf)]). An attacker updates the DNS record to `127.0.0.1`, and when your code resolves those URL host it results in sending a potentially malicious request to a server on the internal network. The property was valid at the "time of check", but invalid and malicious at "time of use". GitLab-specific example can be found in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214401) where, although `Gitlab::UrlBlocker.validate!` was called, the returned value was not used. This made it vulnerable to TOCTOU bug and SSRF protection bypass through [DNS rebinding](#server-side-request-forgery-ssrf). The fix was to [use the validated IP address](https://gitlab.com/gitlab-org/gitlab/-/commit/7af8abd4df9a98f7a1ae7c4ec9840d0a7a8c684d). diff --git a/doc/development/service_ping/metrics_dictionary.md b/doc/development/service_ping/metrics_dictionary.md index f7abf7b99fa..25895d732e4 100644 --- a/doc/development/service_ping/metrics_dictionary.md +++ b/doc/development/service_ping/metrics_dictionary.md @@ -55,7 +55,7 @@ Each metric is defined in a separate YAML file consisting of a number of fields: | `options` | no | `object`: options information needed to calculate the metric value. | | `skip_validation` | no | This should **not** be set. [Used for imported metrics until we review, update and make them valid](https://gitlab.com/groups/gitlab-org/-/epics/5425). | -### Metric key_path +### Metric `key_path` The `key_path` of the metric is the location in the JSON Service Ping payload. @@ -108,7 +108,7 @@ Metric definitions can have one of the following statuses: - `broken`: Metric reports broken data (for example, -1 fallback), or does not report data at all. A metric marked as `broken` must also have the `repair_issue_url` attribute. - `removed`: Metric was removed, but it may appear in Service Ping payloads sent from instances running on older versions of GitLab. -### Metric value_type +### Metric `value_type` Metric definitions can have one of the following values for `value_type`: @@ -120,7 +120,7 @@ In general, we avoid complex objects and prefer one of the `boolean`, `number`, An example of a metric that uses `value_type: object` is `topology` (`/config/metrics/settings/20210323120839_topology.yml`), which has a related schema in `/config/metrics/objects_schemas/topology_schema.json`. -### Metric time_frame +### Metric `time_frame` - `7d`: The metric data applies to the most recent 7-day interval. For example, the following metric counts the number of users that create epics over a 7-day interval: `ee/config/metrics/counts_7d/20210305145820_g_product_planning_epic_created_weekly.yml`. - `28d`: The metric data applies to the most recent 28-day interval. For example, the following metric counts the number of unique users that create issues over a 28-day interval: `config/metrics/counts_28d/20210216181139_issues.yml`. diff --git a/doc/development/sidekiq/idempotent_jobs.md b/doc/development/sidekiq/idempotent_jobs.md index 80c6c403549..1487677ed75 100644 --- a/doc/development/sidekiq/idempotent_jobs.md +++ b/doc/development/sidekiq/idempotent_jobs.md @@ -189,7 +189,7 @@ that can tolerate some duplication. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69372) in GitLab 14.3. > - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/338350) in GitLab 14.4. > - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/338350) in GitLab 14.6. -> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/346598) in GitLab 14.9. [Feature flag preserve_latest_wal_locations_for_idempotent_jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/346598) removed. +> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/346598) in GitLab 14.9. [Feature flag `preserve_latest_wal_locations_for_idempotent_jobs`](https://gitlab.com/gitlab-org/gitlab/-/issues/346598) removed. The deduplication always take into account the latest binary replication pointer, not the first one. This happens because we drop the same job scheduled for the second time and the Write-Ahead Log (WAL) is lost. diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md index 979432a2e5b..c9d783377bd 100644 --- a/doc/development/sidekiq/index.md +++ b/doc/development/sidekiq/index.md @@ -14,7 +14,7 @@ information on administering GitLab, see [configuring Sidekiq](../../administrat There are pages with additional detail on the following topics: 1. [Compatibility across updates](compatibility_across_updates.md) -1. [Job idempotency and job deduplication](idempotent_jobs.md) +1. [Job idempotence and job deduplication](idempotent_jobs.md) 1. [Limited capacity worker: continuously performing work with a specified concurrency](limited_capacity_worker.md) 1. [Logging](logging.md) 1. [Worker attributes](worker_attributes.md) diff --git a/doc/development/snowplow/index.md b/doc/development/snowplow/index.md index 8d05e05e592..32628744a23 100644 --- a/doc/development/snowplow/index.md +++ b/doc/development/snowplow/index.md @@ -17,7 +17,7 @@ Snowplow is an enterprise-grade marketing and Product Intelligence platform that - **Data modeling** joins event-level data with other data sets, aggregates them into smaller data sets, and applies business logic. This produces a clean set of tables for data analysis. We use data models for Redshift and Looker. - **Analytics** are performed on Snowplow events or on aggregate tables. - + ## Enable Snowplow tracking diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md index b9a36bfb60c..e473b158087 100644 --- a/doc/development/testing_guide/end_to_end/feature_flags.md +++ b/doc/development/testing_guide/end_to_end/feature_flags.md @@ -30,7 +30,7 @@ feature flag is under test. - Format: `feature_flag: { name: 'feature_flag_name', scope: :project }` - When `scope` is set to `:global`, the test will be **skipped on all live .com environments**. This is to avoid issues with feature flag changes affecting other tests or users on that environment. -- When `scope` is set to any other value (such as `:project`, `:group` or `:user`), or if no `scope` is specified, the test will only be **skipped on canary, production, and preprod**. +- When `scope` is set to any other value (such as `:project`, `:group` or `:user`), or if no `scope` is specified, the test will only be **skipped on canary, production, and pre-production**. This is due to the fact that administrator access is not available there. **WARNING:** You are strongly advised to first try and [enable feature flags only for a group, project, user](../../feature_flags/index.md#feature-actors), diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md index 5fbf2ffbcde..6a599ce9a50 100644 --- a/doc/development/testing_guide/end_to_end/page_objects.md +++ b/doc/development/testing_guide/end_to_end/page_objects.md @@ -155,7 +155,7 @@ In our case, `data-qa-selector="login_field"`, `data-qa-selector="password_field Things to note: -- The name of the element and the `qa_selector` must match and be snake_cased +- The name of the element and the `qa_selector` must match and be snake cased - If the element appears on the page unconditionally, add `required: true` to the element. See [Dynamic element validation](dynamic_element_validation.md) - You may see `.qa-selector` classes in existing Page Objects. We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector) diff --git a/doc/development/testing_guide/end_to_end/troubleshooting.md b/doc/development/testing_guide/end_to_end/troubleshooting.md index e0925cb71f4..b4c47b90f0b 100644 --- a/doc/development/testing_guide/end_to_end/troubleshooting.md +++ b/doc/development/testing_guide/end_to_end/troubleshooting.md @@ -59,7 +59,7 @@ Net::ReadTimeout: Net::ReadTimeout with #<TCPSocket:(closed)> ``` This error can happen if GitLab runs on an address that does not resolve from -`localhost`. For example, if you set GDK's `hostname` +`localhost`. For example, if you set the GDK `hostname` [to a specific local IP address](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/run_qa_against_gdk.md#run-qa-tests-against-your-gdk-setup), you must use that IP address instead of `localhost` in the command. For example, if your IP is `192.168.0.12`: diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md index 647fb94c4f6..d925e04266c 100644 --- a/doc/development/testing_guide/frontend_testing.md +++ b/doc/development/testing_guide/frontend_testing.md @@ -1165,7 +1165,7 @@ By now you've probably heard of [Jest snapshot tests](https://jestjs.io/docs/sna To use them within GitLab, there are a few guidelines that should be highlighted: - Treat snapshots as code -- Don't think of a snapshot file as a Blackbox +- Don't think of a snapshot file as a black box - Care for the output of the snapshot, otherwise, it's not providing any real value. This will usually involve reading the generated snapshot file as you would read any other piece of code Think of a snapshot test as a simple way to store a raw `String` representation of what you've put into the item being tested. This can be used to evaluate changes in a component, a store, a complex piece of generated output, etc. You can see more in the list below for some recommended `Do's and Don'ts`. @@ -1175,7 +1175,7 @@ Jest provides a great set of docs on [best practices](https://jestjs.io/docs/sna ### How does a snapshot work? -A snapshot is purely a stringified version of what you ask to be tested on the lefthand side of the function call. This means any kind of changes you make to the formatting of the string has an impact on the outcome. This process is done by leveraging serializers for an automatic transform step. For Vue this is already taken care of by leveraging the `vue-jest` package, which offers the proper serializer. +A snapshot is purely a stringified version of what you ask to be tested on the left-hand side of the function call. This means any kind of changes you make to the formatting of the string has an impact on the outcome. This process is done by leveraging serializers for an automatic transform step. For Vue this is already taken care of by leveraging the `vue-jest` package, which offers the proper serializer. Should the outcome of your spec be different from what is in the generated snapshot file, you'll be notified about it by a failing test in your test suite. diff --git a/doc/development/uploads/working_with_uploads.md b/doc/development/uploads/working_with_uploads.md index 92d0f45bd4b..a3951fb4c7e 100644 --- a/doc/development/uploads/working_with_uploads.md +++ b/doc/development/uploads/working_with_uploads.md @@ -26,7 +26,7 @@ stored. When you create a new Uploader class you are deciding where to store the feature. First of all, ask yourself if you need a new Uploader class. It is OK -to use the same Uploader class for different mountpoints or different +to use the same Uploader class for different mount points or different models. If you do want or need your own Uploader class then you should make it @@ -160,8 +160,8 @@ we modified it. The central concept of CarrierWave is the **Uploader** class. The Uploader defines where files get stored, and optionally contains validation and processing logic. To use an Uploader you must associate -it with a text column on an ActiveRecord model. This called "mounting" -and the column is called the "mountpoint". For example: +it with a text column on an ActiveRecord model. This is called "mounting" +and the column is called `mountpoint`. For example: ```ruby class Project < ApplicationRecord @@ -179,12 +179,12 @@ The directory `/var/opt/gitlab/gitlab-rails/uploads/-/system/project/avatar/123/` was chosen by the Uploader using among others configuration (`/var/opt/gitlab/gitlab-rails/uploads`), the model name (`project`), -the model ID (`123`) and the mountpoint (`avatar`). +the model ID (`123`) and the mount point (`avatar`). > The Uploader determines the individual storage directory of your -> upload. The mountpoint column in your model contains the filename. +> upload. The `mountpoint` column in your model contains the filename. -You never access the mountpoint column directly because CarrierWave +You never access the `mountpoint` column directly because CarrierWave defines a getter and setter on your model that operates on file handle objects. @@ -213,7 +213,7 @@ CarrierWave has 2 storage engines: |CarrierWave class|GitLab name|Description| |---|---|---| -|`CarrierWave::Storage::File`|`ObjectStorage::Store::LOCAL` |Local files, accessed through the Ruby stdlib| +|`CarrierWave::Storage::File`|`ObjectStorage::Store::LOCAL` |Local files, accessed through the Ruby `stdlib` | | `CarrierWave::Storage::Fog`|`ObjectStorage::Store::REMOTE`|Cloud files, accessed through the [Fog gem](https://github.com/fog/fog)| GitLab uses both of these engines, depending on configuration. @@ -227,8 +227,8 @@ storage engine file by file. An Uploader is associated with two storage areas: regular storage and cache storage. Each has its own storage engine. If you assign a file -to a mountpoint setter (`project.avatar = -File.open('/tmp/tanuki.png')`) you will copy/move the file to cache +to a mount point setter (`project.avatar = File.open('/tmp/tanuki.png')`) +you will copy/move the file to cache storage as a side effect via the `cache!` method. To persist the file you must somehow call the `store!` method. This either happens via [ActiveRecord callbacks](https://github.com/carrierwaveuploader/carrierwave/blob/v1.3.2/lib/carrierwave/orm/activerecord.rb#L55) diff --git a/doc/development/value_stream_analytics.md b/doc/development/value_stream_analytics.md index ace921b3978..2d5f33b5dae 100644 --- a/doc/development/value_stream_analytics.md +++ b/doc/development/value_stream_analytics.md @@ -71,7 +71,7 @@ which are always available to the end-users regardless of the subscription. ### Value streams Value streams are container objects for the stages. There can be multiple value streams per group -focusing on different aspects of the Dev Ops lifecycle. +focusing on different aspects of the DevOps lifecycle. ### Events diff --git a/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md b/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md index c477b3d9015..5bcadc6f39b 100644 --- a/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md +++ b/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md @@ -54,7 +54,7 @@ database with a minimal development effort. ### Example configuration - + In this example, two independent value streams are set up for two teams that are using different development workflows within the `Test Group` (top-level namespace). diff --git a/doc/development/work_items.md b/doc/development/work_items.md index a417e1d1349..90e454bec85 100644 --- a/doc/development/work_items.md +++ b/doc/development/work_items.md @@ -54,7 +54,7 @@ To avoid confusion and ensure communication is efficient, we will use the follow | work item view | The new frontend view that renders work items of any type | | | | legacy issue view | The existing view used to render issues and incidents | | | | issue | The existing issue model | | | -| issuable | Any model currently using the issueable module (issues, epics and MRs) | _Incidents are an **issuable**_ | _Incidents are a **work item type**_ | +| issuable | Any model currently using the issuable module (issues, epics and MRs) | _Incidents are an **issuable**_ | _Incidents are a **work item type**_ | | widget | A UI element to present or allow interaction with specific work item data | | | Some terms have been used in the past but have since become confusing and are now discouraged. @@ -92,7 +92,7 @@ NOTE: At first, defining a WIT will only be possible at the root-level group, which would then be inherited by subgroups. We will investigate the possibility of defining new WITs at subgroup levels at a later iteration. -### Introducing work_item_types table +### Introducing `work_item_types` table For example, suppose there are three root-level groups with IDs: `11`, `12`, and `13`. Also, assume the following base types: `issue: 0`, `incident: 1`, `test_case: 2`. @@ -228,7 +228,7 @@ So, migrating epics to a work item type requires providing feature parity betwee The main missing features are: -- Get WIs to the group level. This is dependent on [Consolidate Groups and Projects](https://gitlab.com/gitlab-org/architecture/tasks/-/issues/7) +- Get work items to the group level. This is dependent on [Consolidate Groups and Projects](https://gitlab.com/gitlab-org/architecture/tasks/-/issues/7) initiative. - A hierarchy widget: the ability to structure work items into hierarchies. - Inherited date widget. diff --git a/doc/development/work_items_widgets.md b/doc/development/work_items_widgets.md index 89602d969e6..ba15a3f0163 100644 --- a/doc/development/work_items_widgets.md +++ b/doc/development/work_items_widgets.md @@ -80,7 +80,7 @@ mutation { ``` -### Widget's responsibility and structure +### Widget responsibility and structure A widget is responsible for displaying and updating a single attribute, such as title, description, or labels. Widgets must support any type of work item. diff --git a/doc/development/workhorse/configuration.md b/doc/development/workhorse/configuration.md index 82e44a6f995..9fc106b8f04 100644 --- a/doc/development/workhorse/configuration.md +++ b/doc/development/workhorse/configuration.md @@ -162,7 +162,7 @@ addr = "localhost:9229" max_version = "tls1.3" ``` -## Interaction of authBackend and authSocket +## Interaction of `authBackend` and `authSocket` The interaction between `authBackend` and `authSocket` can be confusing. If `authSocket` is set, it overrides the host portion of `authBackend`, but not @@ -170,7 +170,7 @@ the relative path. In table form: -| authBackend | authSocket | Workhorse connects to | Rails relative URL | +| `authBackend` | `authSocket` | Workhorse connects to | Rails relative URL | |--------------------------------|-------------------|-----------------------|--------------------| | unset | unset | `localhost:8080` | `/` | | `http://localhost:3000` | unset | `localhost:3000` | `/` | diff --git a/doc/install/aws/gitlab_hybrid_on_aws.md b/doc/install/aws/gitlab_hybrid_on_aws.md index 1a7e02edb5d..ef7d4ac0f69 100644 --- a/doc/install/aws/gitlab_hybrid_on_aws.md +++ b/doc/install/aws/gitlab_hybrid_on_aws.md @@ -14,8 +14,8 @@ Amazon provides a managed Kubernetes service offering known as [Amazon Elastic K ## Tested AWS Bill of Materials by reference architecture size -| GitLab Cloud Native Hybrid Ref Arch | GitLab Baseline Perf Test Results Omnibus on Instances | AWS Bill of Materials (BOM) for CNH | AWS Build Performance Testing Results for [CNH](https://gitlab.com/guided-explorations/aws/implementation-patterns/gitlab-cloud-native-hybrid-on-eks/-/blob/master/gitlab-alliances-testing/5K/5k-QuickStart-ARM-RDS-Redis_v13-12-3-ee_2021-07-23_140128/5k-QuickStart-ARM-RDS-Redis_v13-12-3-ee_2021-07-23_140128_results.txt) | CNH Cost Estimate 3 AZs* | -| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| GitLab Cloud Native Hybrid Ref Arch | GitLab Baseline Performance Test Results Omnibus on Instances | AWS Bill of Materials (BOM) for CNH | AWS Build Performance Testing Results for [CNH](https://gitlab.com/guided-explorations/aws/implementation-patterns/gitlab-cloud-native-hybrid-on-eks/-/blob/master/gitlab-alliances-testing/5K/5k-QuickStart-ARM-RDS-Redis_v13-12-3-ee_2021-07-23_140128/5k-QuickStart-ARM-RDS-Redis_v13-12-3-ee_2021-07-23_140128_results.txt) | CNH Cost Estimate 3 AZs* | +| ------------------------------------------------------------ | ------------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | | [2K Omnibus](../../administration/reference_architectures/2k_users.md) | [2K Baseline](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/2k) | [2K Cloud Native Hybrid on EKS](#2k-cloud-native-hybrid-on-eks) | GPT Test Results | [1 YR Ec2 Compute Savings + 1 YR RDS & ElastiCache RIs](https://calculator.aws/#/estimate?id=544bcf1162beae6b8130ad257d081cdf9d4504e3)<br />(2 AZ Cost Estimate is in BOM Below) | | [3K](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) | [3k Baseline](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/3k) | [3K Cloud Native Hybrid on EKS](#3k-cloud-native-hybrid-on-eks) | [3K Full Fixed Scale GPT Test Results](https://gitlab.com/guided-explorations/aws/implementation-patterns/gitlab-cloud-native-hybrid-on-eks/-/blob/master/gitlab-alliances-testing/3K/3k-QuickStart-ARM-RDS-Cache_v13-12-3-ee_2021-07-23_124216/3k-QuickStart-ARM-RDS-Cache_v13-12-3-ee_2021-07-23_124216_results.txt)<br /><br />[3K Elastic Auto Scale GPT Test Results](https://gitlab.com/guided-explorations/aws/implementation-patterns/gitlab-cloud-native-hybrid-on-eks/-/blob/master/gitlab-alliances-testing/3K/3k-QuickStart-AutoScale-ARM-RDS-Cache_v13-12-3-ee_2021-07-23_194200/3k-QuickStart-AutoScale-ARM-RDS-Cache_v13-12-3-ee_2021-07-23_194200_results.txt) | [1 YR Ec2 Compute Savings + 1 YR RDS & ElastiCache RIs](https://calculator.aws/#/estimate?id=f1294fec554e21be999711cddcdab9c5e7f83f14)<br />(2 AZ Cost Estimate is in BOM Below) | | [5K](../../administration/reference_architectures/5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) | [5k Baseline](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/5k) | [5K Cloud Native Hybrid on EKS](#5k-cloud-native-hybrid-on-eks) | [5K Full Fixed Scale GPT Test Results](https://gitlab.com/guided-explorations/aws/implementation-patterns/gitlab-cloud-native-hybrid-on-eks/-/blob/master/gitlab-alliances-testing/5K/5k-QuickStart-ARM-RDS-Redis_v13-12-3-ee_2021-07-23_140128/5k-QuickStart-ARM-RDS-Redis_v13-12-3-ee_2021-07-23_140128_results.txt)<br /><br />[5K AutoScale from 25% GPT Test Results](https://gitlab.com/guided-explorations/aws/implementation-patterns/gitlab-cloud-native-hybrid-on-eks/-/blob/master/gitlab-alliances-testing/5K/5k-QuickStart-AutoScale-From-25Percent-ARM-RDS-Redis_v13-12-3-ee_2021-07-24_102717/5k-QuickStart-AutoScale-From-25Percent-ARM-RDS-Redis_v13-12-3-ee_2021-07-24_102717_results.txt) | [1 YR Ec2 Compute Savings + 1 YR RDS & ElastiCache RIs](https://calculator.aws/#/estimate?id=330ee43c5b14662db5df6e52b34898d181a09e16) | @@ -166,12 +166,12 @@ If EKS node autoscaling is employed, it is likely that your average loading will | Non-Kubernetes Compute | Ref Arch Raw Total | AWS BOM<br />(Directly Usable in AWS Quick Start) | Example Cost<br />US East, 3 AZ | Example Cost<br />US East, 2 AZ | | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------- | ------------------------------- | ------------------------------- | -| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for perf. testing | | | +| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for performance testing | | | | **PostgreSQL**<br />AWS Amazon RDS PostgreSQL Nodes Configuration (GPT tested) | 2vCPU, 7.5 GB<br />Tested with Graviton ARM | **db.r6g.large** x 3 nodes <br />(6vCPU, 48 GB) | 3 nodes x $0.26 = $0.78/hr | 3 nodes x $0.26 = $0.78/hr | | **Redis** | 1vCPU, 3.75GB<br />(across 12 nodes for Redis Cache, Redis Queues/Shared State, Sentinel Cache, Sentinel Queues/Shared State) | **cache.m6g.large** x 3 nodes<br />(6vCPU, 19GB) | 3 nodes x $0.15 = $0.45/hr | 2 nodes x $0.15 = $0.30/hr | | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | | | | | Gitaly Instances (in ASG) | 12 vCPU, 45GB<br />(across 3 nodes) | **m5.xlarge** x 3 nodes<br />(48 vCPU, 180 GB) | $0.192 x 3 = $0.58/hr | $0.192 x 3 = $0.58/hr | -| | The GitLab Reference architecture for 2K is not Highly Available and therefore has a single Gitaly no Praefect. AWS Quick Starts MUST be HA, so it implements Prafect from the 3K Ref Architecture to meet that requirement | | | | +| | The GitLab Reference architecture for 2K is not Highly Available and therefore has a single Gitaly no Praefect. AWS Quick Starts MUST be HA, so it implements Praefect from the 3K Ref Architecture to meet that requirement | | | | | Praefect (Instances in ASG with load balancer) | 6 vCPU, 10 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB) | $0.09 x 3 = $0.21/hr | $0.09 x 3 = $0.21/hr | | Praefect PostgreSQL(1) (AWS RDS) | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | Not applicable; reuses GitLab PostgreSQL | $0 | $0 | | Internal Load Balancing Node | 2 vCPU, 1.8 GB | AWS ELB | $0.10/hr | $0.10/hr | @@ -221,7 +221,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will | Non-Kubernetes Compute | Ref Arch Raw Total | AWS BOM<br />(Directly Usable in AWS Quick Start) | Example Cost<br />US East, 3 AZ | Example Cost<br />US East, 2 AZ | | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------- | ------------------------------- | ------------------------------------------------------------ | -| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for perf. testing | | | +| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for performance testing | | | | **PostgreSQL**<br />Amazon RDS PostgreSQL Nodes Configuration (GPT tested) | 18vCPU, 36 GB <br />(across 9 nodes for PostgreSQL, PgBouncer, Consul)<br />Tested with Graviton ARM | **db.r6g.xlarge** x 3 nodes <br />(12vCPU, 96 GB) | 3 nodes x $0.52 = $1.56/hr | 3 nodes x $0.52 = $1.56/hr | | **Redis** | 6vCPU, 18GB<br />(across 6 nodes for Redis Cache, Sentinel) | **cache.m6g.large** x 3 nodes<br />(6vCPU, 19GB) | 3 nodes x $0.15 = $0.45/hr | 2 nodes x $0.15 = $0.30/hr | | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) | | | | | @@ -275,7 +275,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will | Non-Kubernetes Compute | Ref Arch Raw Total | AWS BOM<br />(Directly Usable in AWS Quick Start) | Example Cost<br />US East, 3 AZ | Example Cost<br />US East, 2 AZ | | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------- | ------------------------------- | ------------------------------------------------------------ | -| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for perf. testing | | | +| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for performance testing | | | | **PostgreSQL**<br />Amazon RDS PostgreSQL Nodes Configuration (GPT tested) | 21vCPU, 51 GB <br />(across 9 nodes for PostgreSQL, PgBouncer, Consul)<br />Tested with Graviton ARM | **db.r6g.2xlarge** x 3 nodes <br />(24vCPU, 192 GB) | 3 nodes x $1.04 = $3.12/hr | 3 nodes x $1.04 = $3.12/hr | | **Redis** | 9vCPU, 27GB<br />(across 6 nodes for Redis, Sentinel) | **cache.m6g.xlarge** x 3 nodes<br />(12vCPU, 39GB) | 3 nodes x $0.30 = $0.90/hr | 2 nodes x $0.30 = $0.60/hr | | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) | | | | | @@ -328,7 +328,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will | Non-Kubernetes Compute | Ref Arch Raw Total | AWS BOM | Example Cost<br />US East, 3 AZ | Example Cost<br />US East, 2 AZ | | ------------------------------------------------------------ | ------------------------------ | ------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for perf. testing | | | +| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for performance testing | | | | **PostgreSQL**<br />Amazon RDS PostgreSQL Nodes Configuration (GPT tested) | 36vCPU, 102 GB <br />(across 9 nodes for PostgreSQL, PgBouncer, Consul) | **db.r6g.2xlarge** x 3 nodes <br />(24vCPU, 192 GB) | 3 nodes x $1.04 = $3.12/hr | 3 nodes x $1.04 = $3.12/hr | | **Redis** | 30vCPU, 114GB<br />(across 12 nodes for Redis Cache, Redis Queues/Shared State, Sentinel Cache, Sentinel Queues/Shared State) | **cache.m5.2xlarge** x 3 nodes<br />(24vCPU, 78GB) | 3 nodes x $0.62 = $1.86/hr | 2 nodes x $0.62 = $1.24/hr | | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) | | | | | @@ -381,7 +381,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will | Non-Kubernetes Compute | Ref Arch Raw Total | AWS BOM | Example Cost<br />US East, 3 AZ | Example Cost<br />US East, 2 AZ | | ------------------------------------------------------------ | ------------------------------------------------------------ | --------------------------------------------------------- | ------------------------------- | ------------------------------------------------------------ | -| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for perf. testing | | | +| **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for performance testing | | | | **PostgreSQL**<br />Amazon RDS PostgreSQL Nodes Configuration (GPT tested) | 96vCPU, 360 GB <br />(across 3 nodes) | **db.r6g.8xlarge** x 3 nodes <br />(96vCPU, 768 GB total) | 3 nodes x $4.15 = $12.45/hr | 3 nodes x $4.15 = $12.45/hr | | **Redis** | 30vCPU, 114GB<br />(across 12 nodes for Redis Cache, Redis Queues/Shared State, Sentinel Cache, Sentinel Queues/Shared State) | **cache.m6g.2xlarge** x 3 nodes<br />(24vCPU, 78GB total) | 3 nodes x $0.60 = $1.80/hr | 2 nodes x $0.60 = $1.20/hr | | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) | | | | | diff --git a/doc/install/aws/gitlab_sre_for_aws.md b/doc/install/aws/gitlab_sre_for_aws.md index c55ce993cfc..e68aea00b36 100644 --- a/doc/install/aws/gitlab_sre_for_aws.md +++ b/doc/install/aws/gitlab_sre_for_aws.md @@ -56,7 +56,7 @@ All recommendations are for production configurations, including performance tes - Use only SSD storage and the [class of Elastic Block Store (EBS) storage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) that suites your durability and speed requirements. - When not using provisioned EBS IO, EBS volume size determines the I/O level, so provisioning volumes that are much larger than needed can be the least expensive way to improve EBS IO. -- If Gitaly performance monitoring shows signs of disk stress then one of the provisioned IOPs levels can be chosen. EBS IOPs levels also have enhanced durability which may be appealing for some implementations aside from performance considerations. +- If Gitaly performance monitoring shows signs of disk stress then one of the provisioned IOPS levels can be chosen. EBS IOPS levels also have enhanced durability which may be appealing for some implementations aside from performance considerations. **To accommodate:** diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md index 93a966b69fb..05db439ffcd 100644 --- a/doc/install/aws/index.md +++ b/doc/install/aws/index.md @@ -70,7 +70,7 @@ Because any given GitLab upgrade might involve data disk updates or database sch - [GitLab Enterprise Edition](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;ownerAlias=782774275127;search=GitLab%20EE;sort=desc:name): If you want to unlock the enterprise features, a license is needed. - [GitLab Community Edition](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;ownerAlias=782774275127;search=GitLab%20CE;sort=desc:name): The open source version of GitLab. - - [GitLab Premium or Ultimate Marketplace (Prelicensed)](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;source=Marketplace;search=GitLab%20EE;sort=desc:name): 5 user license built into per-minute billing. + - [GitLab Premium or Ultimate Marketplace (pre-licensed)](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;source=Marketplace;search=GitLab%20EE;sort=desc:name): 5 user license built into per-minute billing. 1. AMI IDs are unique per region, so after you've loaded one of the above, select the desired target region in the upper right of the console to see the appropriate AMIs. 1. After the console is loaded, you can add additional search criteria to narrow further. For instance, type `13.` to find only 13.x versions. @@ -104,7 +104,7 @@ Implementation patterns enable platform-specific terminology, best practice arch ### Platform as a Service (PaaS) specification and usage -Platform as a Service options are a huge portion of the value provided by Cloud Platforms as they simplify operational complexity and reduce the SRE and security skilling required to operate advanced, highly available technology services. Implementation patterns can be prequalified against the partner PaaS options. +Platform as a Service options are a huge portion of the value provided by Cloud Platforms as they simplify operational complexity and reduce the SRE and security skilling required to operate advanced, highly available technology services. Implementation patterns can be pre-qualified against the partner PaaS options. - Implementation patterns help implementers understand what PaaS options are known to work and how to choose between PaaS solutions when a single platform has more than one PaaS option for the same GitLab role. - For instance, where reference architectures do not have a specific recommendation on what technology is leveraged for GitLab outbound email services or what the sizing should be - a Reference Implementation may advise using a cloud providers Email as a Service (PaaS) and possibly even with specific settings. diff --git a/doc/integration/arkose.md b/doc/integration/arkose.md index aa27e3ba4a4..09a7defcff8 100644 --- a/doc/integration/arkose.md +++ b/doc/integration/arkose.md @@ -35,8 +35,8 @@ improve their risk prediction model. NOTE: Enabling the `arkose_labs_prevent_login` feature flag results in sessions with a `High` risk -score being denied access. So far, we have kept this feature flag disabled to evaluate Arkose -Protect's predictions and to make sure we are not preventing legitimate users from signing in. +score being denied access. So far, we have kept this feature flag disabled to evaluate Arkose Protect +predictions and to make sure we are not preventing legitimate users from signing in. That said, we have seen that interactive challenges are effective in preventing some malicious sign-in attempts as not completing them prevents attackers from moving on to the next sign-in step. diff --git a/doc/integration/datadog.md b/doc/integration/datadog.md index 31e254658c1..1f20bccf083 100644 --- a/doc/integration/datadog.md +++ b/doc/integration/datadog.md @@ -38,9 +38,11 @@ project, group, or instance level: Used only in advanced scenarios. 1. Optional. If you use more than one GitLab instance, provide a unique **Service** name to differentiate between your GitLab instances. +<!-- vale gitlab.Spelling = NO --> 1. Optional. If you use groups of GitLab instances (such as staging and production environments), provide an **Env** name. This value is attached to each span the integration generates. +<!-- vale gitlab.Spelling = YES --> 1. Optional. To define any custom tags for all spans at which the integration is being configured, enter one tag per line in **Tags**. Each line must be in the format `key:value`. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79665) in GitLab 14.8.) 1. Optional. Select **Test settings** to test your integration. @@ -51,4 +53,4 @@ section of your Datadog account. ## Related topics -- [Datadog's CI Visibility](https://docs.datadoghq.com/continuous_integration/) documentation. +- [Datadog CI Visibility](https://docs.datadoghq.com/continuous_integration/) documentation. diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md index 8a438dde52e..53a2fb8bbdd 100644 --- a/doc/integration/jenkins.md +++ b/doc/integration/jenkins.md @@ -179,7 +179,7 @@ If you get this error message while configuring GitLab, the following are possib - The Jenkins instance is at a local address and is not included in the [GitLab installation's allowlist](../security/webhooks.md#create-an-allowlist-for-local-requests). - The credentials for the Jenkins instance do not have sufficient access or are invalid. -- The **Enable authentication for `/project` end-point** checkbox is not selected in your [Jenkin's plugin configuration](#configure-the-jenkins-server). +- The **Enable authentication for `/project` end-point** checkbox is not selected in your [Jenkins plugin configuration](#configure-the-jenkins-server). ### Error in merge requests - "Could not connect to the CI server" diff --git a/doc/integration/saml.md b/doc/integration/saml.md index 0106f04d204..bba872a9ae9 100644 --- a/doc/integration/saml.md +++ b/doc/integration/saml.md @@ -522,10 +522,10 @@ NOTE: This setting should be used only to map attributes that are part of the OmniAuth `info` hash schema. -`attribute_statements` is used to map Attribute Names in a SAMLResponse to entries +`attribute_statements` is used to map Attribute Names in a `SAMLResponse` to entries in the OmniAuth [`info` hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later). -For example, if your SAMLResponse contains an Attribute called `EmailAddress`, +For example, if your `SAMLResponse` contains an Attribute called `EmailAddress`, specify `{ email: ['EmailAddress'] }` to map the Attribute to the corresponding key in the `info` hash. URI-named Attributes are also supported, for example, `{ email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }`. diff --git a/doc/operations/metrics/dashboards/panel_types.md b/doc/operations/metrics/dashboards/panel_types.md index 95e8bd82475..71a7dff3b46 100644 --- a/doc/operations/metrics/dashboards/panel_types.md +++ b/doc/operations/metrics/dashboards/panel_types.md @@ -40,8 +40,8 @@ Note the following properties: | Property | Type | Required | Description | | ------ | ------ | ------ | ------ | -| type | string | no | Type of panel to be rendered. Optional for area panel types | -| query_range | string | required | For area panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) | +| `type` | string | no | Type of panel to be rendered. Optional for area panel types | +| `query_range` | string | required | For area panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) |  @@ -82,8 +82,8 @@ Note the following properties: | Property | Type | Required | Description | | ------ | ------ | ------ | ------ | -| type | string | required | Must be `anomaly-chart` for anomaly panel types | -| query_range | yes | required | For anomaly panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) in every metric. | +| `type` | string | required | Must be `anomaly-chart` for anomaly panel types | +| `query_range` | yes | required | For anomaly panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) in every metric. |  @@ -138,8 +138,8 @@ Note the following properties: | Property | Type | Required | Description | | ------ | ------ | ------ | ------ | -| type | string | yes | Type of panel to be rendered. For column panel types, set to `column` | -| query_range | yes | yes | For column panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) | +| `type` | string | yes | Type of panel to be rendered. For column panel types, set to `column` | +| `query_range` | yes | yes | For column panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) |  @@ -306,8 +306,8 @@ Note the following properties: | Property | Type | Required | Description | | ------ | ------ | ------ | ------ | -| type | string | yes | Type of panel to be rendered. For heatmap panel types, set to `heatmap` | -| query_range | yes | yes | For area panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) | +| `type` | string | yes | Type of panel to be rendered. For heatmap panel types, set to `heatmap` | +| `query_range` | yes | yes | For area panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) |  diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md index 463ccb7b629..e5d8d858df2 100644 --- a/doc/security/crime_vulnerability.md +++ b/doc/security/crime_vulnerability.md @@ -53,7 +53,7 @@ SPDY support earlier than version 4 is advertised. From the report above it is important to note that Nessus is only checking if TLS advertises the SPDY protocol earlier than version 4. It does not perform an attack nor does it check if compression is enabled. The Nessus scanner alone -cannot tell that SPDY's compression is disabled and not subject to the CRIME +cannot tell that SPDY compression is disabled and not subject to the CRIME vulnerability. ## References diff --git a/doc/security/password_storage.md b/doc/security/password_storage.md index bd514de6e2c..67ef161e634 100644 --- a/doc/security/password_storage.md +++ b/doc/security/password_storage.md @@ -21,7 +21,7 @@ GitLab uses the [Devise](https://github.com/heartcombo/devise) authentication library to hash user passwords. Created password hashes have these attributes: - **Hashing**: - - **BCrypt**: By default, the [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing + - **bcrypt**: By default, the [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing function is used to generate the hash of the provided password. This cryptographic hashing function is strong and industry-standard. - **PBKDF2+SHA512**: PBKDF2+SHA512 is supported: @@ -29,7 +29,7 @@ library to hash user passwords. Created password hashes have these attributes: - In GitLab 15.6 and later when [FIPS mode](../development/fips_compliance.md) is enabled (feature flags are not required). - **Stretching**: Password hashes are [stretched](https://en.wikipedia.org/wiki/Key_stretching) to harden against brute-force attacks. By default, GitLab uses a stretching - factor of 10 for BCrypt and 20,000 for PBKDF2 + SHA512. + factor of 10 for bcrypt and 20,000 for PBKDF2 + SHA512. - **Salting**: A [cryptographic salt](https://en.wikipedia.org/wiki/Salt_(cryptography)) is added to each password to harden against pre-computed hash and dictionary attacks. To increase security, each salt is randomly generated for each diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index 264ac790453..4dd17badedc 100644 --- a/doc/topics/autodevops/customize.md +++ b/doc/topics/autodevops/customize.md @@ -314,7 +314,7 @@ the database are preconfigured, but can be customized by setting the associated postgres://user:password@postgres-host:postgres-port/postgres-database ``` -### Upgrading PostgresSQL +### Upgrading PostgreSQL WARNING: The CI/CD variable `AUTO_DEVOPS_POSTGRES_CHANNEL` that controls default provisioned diff --git a/doc/topics/plan_and_track.md b/doc/topics/plan_and_track.md index cf5dfe488db..862c41aa4d9 100644 --- a/doc/topics/plan_and_track.md +++ b/doc/topics/plan_and_track.md @@ -11,12 +11,16 @@ with milestones and track your team's time. Learn how to save time with quick actions, see how GitLab renders Markdown text, and learn how to use Git to interact with GitLab. +<!-- vale gitlab.Spelling = NO --> + <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For a thorough demo of Plan features, see [Multi-team planning with GitLab Ultimate](https://www.youtube.com/watch?v=KmASFwSap7c). In this video, Gabe describes a use case of a multi-team organization that uses GitLab with [Scaled Agile Framework (SAFe)](https://about.gitlab.com/solutions/agile-delivery/scaled-agile/). +<!-- vale gitlab.Spelling = YES --> + ## Basic workflow features Planning features everyone needs to use day-to-day. diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md index 6d878bcb01c..f9422a91357 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/doc/user/admin_area/settings/visibility_and_access_controls.md @@ -219,7 +219,7 @@ If only one protocol is enabled: - The project page shows only the allowed protocol's URL, with no option to change it. -- GitLab shows a tooltip when you hover over the URL's protocol, if user action +- GitLab shows a tooltip when you hover over the protocol for the URL, if user action (such as adding a SSH key or setting a password) is required:  diff --git a/doc/user/application_security/api_fuzzing/create_har_files.md b/doc/user/application_security/api_fuzzing/create_har_files.md index e7eaf47121b..5e033a75902 100644 --- a/doc/user/application_security/api_fuzzing/create_har_files.md +++ b/doc/user/application_security/api_fuzzing/create_har_files.md @@ -109,7 +109,7 @@ responses in HAR format. have an account, first create an account. 1. Browse pages that call an API. Fiddler automatically captures the requests. 1. Select one or more requests, then from the context menu, select **Export > Selected Sessions**. -1. In the **Choose Format** dropdown list select **HTTPArchive v1.2**. +1. In the **Choose Format** dropdown list select **HTTP Archive v1.2**. 1. Enter a filename and select **Save**. Fiddler shows a popup message confirming the export has succeeded. diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md index b14a42a7fb0..c03201232ad 100644 --- a/doc/user/application_security/api_fuzzing/index.md +++ b/doc/user/application_security/api_fuzzing/index.md @@ -1589,7 +1589,7 @@ variables: While testing an API you may might want to exclude a parameter (query string, header, or body element) from testing. This may be needed because a parameter always causes a failure, slows down testing, or for other reasons. To exclude parameters you can use one of the following variables: `FUZZAPI_EXCLUDE_PARAMETER_ENV` or `FUZZAPI_EXCLUDE_PARAMETER_FILE`. -The `FUZZAPI_EXCLUDE_PARAMETER_ENV` allows providing a JSON string containing excluded parameters. This is a good option if the JSON is short and will not often change. Another option is the variable `FUZZAPI_EXCLUDE_PARAMETER_FILE`. This variable is set to a file path that can be checked into the repository, created by another job as an artifact, or generated at runtime from a pre script using `FUZZAPI_PRE_SCRIPT`. +The `FUZZAPI_EXCLUDE_PARAMETER_ENV` allows providing a JSON string containing excluded parameters. This is a good option if the JSON is short and will not often change. Another option is the variable `FUZZAPI_EXCLUDE_PARAMETER_FILE`. This variable is set to a file path that can be checked into the repository, created by another job as an artifact, or generated at runtime from a pre-script using `FUZZAPI_PRE_SCRIPT`. #### Exclude parameters using a JSON document diff --git a/doc/user/application_security/dast/checks/16.2.md b/doc/user/application_security/dast/checks/16.2.md index a317b9418a1..2051b118009 100644 --- a/doc/user/application_security/dast/checks/16.2.md +++ b/doc/user/application_security/dast/checks/16.2.md @@ -40,5 +40,5 @@ the `Server` header. - [CWE](https://cwe.mitre.org/data/definitions/16.html) - [Apache ServerTokens](https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/) -- [NGINX server_tokens](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens) +- [NGINX `server_tokens`](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens) - [IIS 10 Remove Server Header](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/#attributes) diff --git a/doc/user/application_security/dast/checks/548.1.md b/doc/user/application_security/dast/checks/548.1.md index b6907db5928..6cef8ccdb63 100644 --- a/doc/user/application_security/dast/checks/548.1.md +++ b/doc/user/application_security/dast/checks/548.1.md @@ -41,5 +41,5 @@ indexing. - [CWE](https://cwe.mitre.org/data/definitions/548.html) - [Apache Options](https://httpd.apache.org/docs/2.4/mod/core.html#options) -- [NGINX autoindex](https://nginx.org/en/docs/http/ngx_http_autoindex_module.html) -- [IIS directoryBrowse element](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/directorybrowse) +- [NGINX `autoindex`](https://nginx.org/en/docs/http/ngx_http_autoindex_module.html) +- [IIS `directoryBrowse` element](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/directorybrowse) diff --git a/doc/user/application_security/dast/checks/798.33.md b/doc/user/application_security/dast/checks/798.33.md index 536faefdb51..4761ac9d157 100644 --- a/doc/user/application_security/dast/checks/798.33.md +++ b/doc/user/application_security/dast/checks/798.33.md @@ -4,11 +4,11 @@ group: Dynamic Analysis 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 --- -# Exposure of confidential secret or token Droneci Access Token +# Exposure of confidential secret or token Drone CI Access Token ## Description -The response body contains content that matches the pattern of a Droneci Access Token. +The response body contains content that matches the pattern of a Drone CI Access Token. Exposing this value could allow attackers to gain access to all resources granted by this token. ## Remediation diff --git a/doc/user/application_security/dast/checks/798.49.md b/doc/user/application_security/dast/checks/798.49.md index 7ea3a65fbfa..41a3e8ace3d 100644 --- a/doc/user/application_security/dast/checks/798.49.md +++ b/doc/user/application_security/dast/checks/798.49.md @@ -4,11 +4,11 @@ group: Dynamic Analysis 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 --- -# Exposure of confidential secret or token Freshbooks Access Token +# Exposure of confidential secret or token FreshBooks Access Token ## Description -The response body contains content that matches the pattern of a Freshbooks Access Token. +The response body contains content that matches the pattern of a FreshBooks Access Token. Exposing this value could allow attackers to gain access to all resources granted by this token. ## Remediation diff --git a/doc/user/application_security/dast/checks/798.65.md b/doc/user/application_security/dast/checks/798.65.md index f2ebfb988b2..083bfec3350 100644 --- a/doc/user/application_security/dast/checks/798.65.md +++ b/doc/user/application_security/dast/checks/798.65.md @@ -4,11 +4,11 @@ group: Dynamic Analysis 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 --- -# Exposure of confidential secret or token Launchdarkly Access Token +# Exposure of confidential secret or token LaunchDarkly Access Token ## Description -The response body contains content that matches the pattern of a Launchdarkly Access Token. +The response body contains content that matches the pattern of a LaunchDarkly Access Token. Exposing this value could allow attackers to gain access to all resources granted by this token. ## Remediation diff --git a/doc/user/application_security/dast/checks/798.97.md b/doc/user/application_security/dast/checks/798.97.md index d3035b05bbb..711288eba9c 100644 --- a/doc/user/application_security/dast/checks/798.97.md +++ b/doc/user/application_security/dast/checks/798.97.md @@ -4,11 +4,11 @@ group: Dynamic Analysis 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 --- -# Exposure of confidential secret or token Rubygem API token +# Exposure of confidential secret or token RubyGems API token ## Description -The response body contains content that matches the pattern of a Rubygem API token. +The response body contains content that matches the pattern of a RubyGems API token. Exposing this value could allow attackers to gain access to all resources granted by this token. ## Remediation diff --git a/doc/user/application_security/dast/checks/829.1.md b/doc/user/application_security/dast/checks/829.1.md index f18634b72d9..7df250c2047 100644 --- a/doc/user/application_security/dast/checks/829.1.md +++ b/doc/user/application_security/dast/checks/829.1.md @@ -20,7 +20,7 @@ applications users would be protected from the malicious alterations. All identified resources should be sourced from the same domain as the target application. If this is not possible, it is strongly recommended that all `script` tags that implement `src` values, or `link` tags that implement the `href` values include Sub-Resource Integrity. To generate SRI integrity values the -[srihash](https://www.srihash.org/) tool can be used, or by running one of the following commands: +[SRI hash](https://www.srihash.org/) tool can be used, or by running one of the following commands: - `cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A` - `shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64` diff --git a/doc/user/application_security/dast/checks/829.2.md b/doc/user/application_security/dast/checks/829.2.md index 19490afe676..d9d3e5a6341 100644 --- a/doc/user/application_security/dast/checks/829.2.md +++ b/doc/user/application_security/dast/checks/829.2.md @@ -19,7 +19,7 @@ them with known good versions. All identified resources should be sourced from the same domain as the target application. If this is not possible, it is strongly recommended that all `script` tags that implement `src` values, or `link` tags that implement the `href` values include Sub-Resource Integrity. To generate SRI integrity values the -[srihash](https://www.srihash.org/) tool can be used, or by running one of the following commands: +[SRI hash](https://www.srihash.org/) tool can be used, or by running one of the following commands: - `cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A` - `shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64` diff --git a/doc/user/application_security/dast/checks/index.md b/doc/user/application_security/dast/checks/index.md index 9466734f9cf..56406b24586 100644 --- a/doc/user/application_security/dast/checks/index.md +++ b/doc/user/application_security/dast/checks/index.md @@ -69,7 +69,7 @@ The [DAST browser-based crawler](../browser_based.md) provides a number of vulne | [798.30](798.30.md) | Exposure of confidential secret or token Dropbox API secret | High | Passive | | [798.31](798.31.md) | Exposure of confidential secret or token Dropbox long lived API token | High | Passive | | [798.32](798.32.md) | Exposure of confidential secret or token Dropbox short lived API token | High | Passive | -| [798.33](798.33.md) | Exposure of confidential secret or token Droneci Access Token | High | Passive | +| [798.33](798.33.md) | Exposure of confidential secret or token Drone CI Access Token | High | Passive | | [798.34](798.34.md) | Exposure of confidential secret or token Duffel API token | High | Passive | | [798.35](798.35.md) | Exposure of confidential secret or token Dynatrace API token | High | Passive | | [798.36](798.36.md) | Exposure of confidential secret or token EasyPost API token | High | Passive | @@ -84,7 +84,7 @@ The [DAST browser-based crawler](../browser_based.md) provides a number of vulne | [798.46](798.46.md) | Exposure of confidential secret or token Flutterwave Secret Key | High | Passive | | [798.47](798.47.md) | Exposure of confidential secret or token Flutterwave Encryption Key | High | Passive | | [798.48](798.48.md) | Exposure of confidential secret or token Frame.io API token | High | Passive | -| [798.49](798.49.md) | Exposure of confidential secret or token Freshbooks Access Token | High | Passive | +| [798.49](798.49.md) | Exposure of confidential secret or token FreshBooks Access Token | High | Passive | | [798.50](798.50.md) | Exposure of confidential secret or token GoCardless API token | High | Passive | | [798.52](798.52.md) | Exposure of confidential secret or token GitHub Personal Access Token | High | Passive | | [798.53](798.53.md) | Exposure of confidential secret or token GitHub OAuth Access Token | High | Passive | @@ -99,7 +99,7 @@ The [DAST browser-based crawler](../browser_based.md) provides a number of vulne | [798.62](798.62.md) | Exposure of confidential secret or token Kraken Access Token | High | Passive | | [798.63](798.63.md) | Exposure of confidential secret or token Kucoin Access Token | High | Passive | | [798.64](798.64.md) | Exposure of confidential secret or token Kucoin Secret Key | High | Passive | -| [798.65](798.65.md) | Exposure of confidential secret or token Launchdarkly Access Token | High | Passive | +| [798.65](798.65.md) | Exposure of confidential secret or token LaunchDarkly Access Token | High | Passive | | [798.66](798.66.md) | Exposure of confidential secret or token Linear API Token | High | Passive | | [798.67](798.67.md) | Exposure of confidential secret or token Linear Client Secret | High | Passive | | [798.68](798.68.md) | Exposure of confidential secret or token LinkedIn Client ID | High | Passive | @@ -126,7 +126,7 @@ The [DAST browser-based crawler](../browser_based.md) provides a number of vulne | [798.94](798.94.md) | Exposure of confidential secret or token Private Key | High | Passive | | [798.95](798.95.md) | Exposure of confidential secret or token Pulumi API token | High | Passive | | [798.96](798.96.md) | Exposure of confidential secret or token PyPI upload token | High | Passive | -| [798.97](798.97.md) | Exposure of confidential secret or token Rubygem API token | High | Passive | +| [798.97](798.97.md) | Exposure of confidential secret or token RubyGem API token | High | Passive | | [798.98](798.98.md) | Exposure of confidential secret or token RapidAPI Access Token | High | Passive | | [798.99](798.99.md) | Exposure of confidential secret or token Sendbird Access ID | High | Passive | | [798.100](798.100.md) | Exposure of confidential secret or token Sendbird Access Token | High | Passive | diff --git a/doc/user/application_security/dast_api/index.md b/doc/user/application_security/dast_api/index.md index 9e0d174e8ee..5c9144056bc 100644 --- a/doc/user/application_security/dast_api/index.md +++ b/doc/user/application_security/dast_api/index.md @@ -1605,7 +1605,7 @@ variables: While testing an API you may might want to exclude a parameter (query string, header, or body element) from testing. This may be needed because a parameter always causes a failure, slows down testing, or for other reasons. To exclude parameters, you can set one of the following variables: `DAST_API_EXCLUDE_PARAMETER_ENV` or `DAST_API_EXCLUDE_PARAMETER_FILE`. -The `DAST_API_EXCLUDE_PARAMETER_ENV` allows providing a JSON string containing excluded parameters. This is a good option if the JSON is short and will not often change. Another option is the variable `DAST_API_EXCLUDE_PARAMETER_FILE`. This variable is set to a file path that can be checked into the repository, created by another job as an artifact, or generated at runtime with a pre script using `DAST_API_PRE_SCRIPT`. +The `DAST_API_EXCLUDE_PARAMETER_ENV` allows providing a JSON string containing excluded parameters. This is a good option if the JSON is short and will not often change. Another option is the variable `DAST_API_EXCLUDE_PARAMETER_FILE`. This variable is set to a file path that can be checked into the repository, created by another job as an artifact, or generated at runtime with a pre-script using `DAST_API_PRE_SCRIPT`. #### Exclude parameters using a JSON document diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md index 64f5c7d02bd..621b4847c60 100644 --- a/doc/user/application_security/dependency_scanning/index.md +++ b/doc/user/application_security/dependency_scanning/index.md @@ -437,7 +437,7 @@ To support the following package managers, the GitLab analyzers proceed in two s <li> <a id="exported-dependency-information-notes-4"></a> <p> - Because of the implementation of <code>go build</code>, the Go build process requires network access, a pre-loaded modcache via <code>go mod download</code>, or vendored dependencies. For more information, + Because of the implementation of <code>go build</code>, the Go build process requires network access, a pre-loaded mod cache via <code>go mod download</code>, or vendored dependencies. For more information, refer to the Go documentation on <a href="https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependencies">compiling packages and dependencies</a>. </p> </li> diff --git a/doc/user/application_security/terminology/index.md b/doc/user/application_security/terminology/index.md index f156d60be8f..27e12bc0516 100644 --- a/doc/user/application_security/terminology/index.md +++ b/doc/user/application_security/terminology/index.md @@ -164,15 +164,15 @@ table.package-managers-and-types ul { <tbody> <tr> <td>gem</td> - <td><a href="https://bundler.io/">bundler</a></td> + <td><a href="https://bundler.io/">Bundler</a></td> </tr> <tr> - <td>packagist</td> - <td><a href="https://getcomposer.org/">composer</a></td> + <td>Packagist</td> + <td><a href="https://getcomposer.org/">Composer</a></td> </tr> <tr> - <td>conan</td> - <td><a href="https://conan.io/">conan</a></td> + <td>Conan</td> + <td><a href="https://conan.io/">Conan</a></td> </tr> <tr> <td>go</td> @@ -180,10 +180,10 @@ table.package-managers-and-types ul { </tr> <tr> <td rowspan="3">maven</td> - <td><a href="https://gradle.org/">gradle</a></td> + <td><a href="https://gradle.org/">Gradle</a></td> </tr> <tr> - <td><a href="https://maven.apache.org/">maven</a></td> + <td><a href="https://maven.apache.org/">Maven</a></td> </tr> <tr> <td><a href="https://www.scala-sbt.org">sbt</a></td> @@ -196,12 +196,12 @@ table.package-managers-and-types ul { <td><a href="https://classic.yarnpkg.com/en">yarn</a></td> </tr> <tr> - <td>nuget</td> - <td><a href="https://www.nuget.org/">nuget</a></td> + <td>NuGet</td> + <td><a href="https://www.nuget.org/">NuGet</a></td> </tr> <tr> - <td rowspan="4">pypi</td> - <td><a href="https://setuptools.pypa.io/en/latest/">setuptools</a></td> + <td rowspan="4">PyPI</td> + <td><a href="https://setuptools.pypa.io/en/latest/">Setuptools</a></td> </tr> <tr> <td><a href="https://pip.pypa.io/en/stable">pip</a></td> diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 0adda54bf06..c420d04d15c 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -314,7 +314,7 @@ The list of GitLab.com specific settings (and their defaults) is as follows: | `max_wal_senders` | 32 | 0 | | `max_wal_size` | 5GB | 1GB | | `shared_buffers` | 112896MB | Based on how much memory is available | -| `shared_preload_libraries` | pg_stat_statements | empty | +| `shared_preload_libraries` | `pg_stat_statements` | empty | | `shmall` | 30146560 | Based on the server's capabilities | | `shmmax` | 123480309760 | Based on the server's capabilities | | `wal_buffers` | 16MB | -1 | diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md index 67263f15f06..a81b61c50ce 100644 --- a/doc/user/group/devops_adoption/index.md +++ b/doc/user/group/devops_adoption/index.md @@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1. > - Fuzz Testing metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/330398) in GitLab 14.2. > - Dependency Scanning metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328034) in GitLab 14.2. -> - Multiselect [added](https://gitlab.com/gitlab-org/gitlab/-/issues/333586) in GitLab 14.2. +> - Multi-select [added](https://gitlab.com/gitlab-org/gitlab/-/issues/333586) in GitLab 14.2. > - Overview table [added](https://gitlab.com/gitlab-org/gitlab/-/issues/335638) in GitLab 14.3. > - Adoption over time chart [added](https://gitlab.com/gitlab-org/gitlab/-/issues/337561) in GitLab 14.4. diff --git a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md index 6b8e2003b8d..7e6a0495d90 100644 --- a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md +++ b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md @@ -94,7 +94,7 @@ Use CI/CD environment variables to configure your project. 1. On the left sidebar, select **Settings > CI/CD**. 1. Expand **Variables**. 1. Set the variable `BASE64_GOOGLE_CREDENTIALS` to the `base64` encoded JSON file you just created. -1. Set the variable `TF_VAR_gcp_project` to your GCP's `project` name. +1. Set the variable `TF_VAR_gcp_project` to your GCP `project` name. 1. Set the variable `TF_VAR_agent_token` to the agent token displayed in the previous task. 1. Set the variable `TF_VAR_kas_address` to the agent server address displayed in the previous task. diff --git a/doc/user/profile/preferences.md b/doc/user/profile/preferences.md index 9838cd1daae..7b79ffad630 100644 --- a/doc/user/profile/preferences.md +++ b/doc/user/profile/preferences.md @@ -96,7 +96,7 @@ A diff compares the old/removed content with the new/added content (for example, [Markdown inline diff](../markdown.md#inline-diff)). Typically, the colors red and green are used for removed and added lines in diffs. The exact colors depend on the selected [syntax highlighting theme](#syntax-highlighting-theme). -The colors may lead to difficulties in case of red–green color blindness. +The colors may lead to difficulties in case of red-green color blindness. For this reason, you can customize the following colors: @@ -205,12 +205,12 @@ Open an issue if you notice that using absolute times breaks a layout. ## Web IDE -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/370139) in GitLab 15.7 [with a flag](../../administration/feature_flags.md) named 'vscode_web_ide'. Disabled by default. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/370139) in GitLab 15.7 [with a flag](../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default. FLAG: On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is not available. The feature is not ready for production use. -The [VS Code-based Web IDE](../project/web_ide/index.md#vscode-reimplementation) is +The [VS Code-based Web IDE](../project/web_ide/index.md#vs-code-reimplementation) is the default editing environment when the `vscode_web_ide` feature flag is enabled. diff --git a/doc/user/project/clusters/cluster_access.md b/doc/user/project/clusters/cluster_access.md index c9b3596d92f..529e7a6da12 100644 --- a/doc/user/project/clusters/cluster_access.md +++ b/doc/user/project/clusters/cluster_access.md @@ -49,16 +49,16 @@ GitLab creates the following resources for RBAC clusters. | Name | Type | Details | Created when | |:----------------------|:---------------------|:-----------------------------------------------------------------------------------------------------------|:-----------------------| | `gitlab` | `ServiceAccount` | `default` namespace | Creating a new cluster | -| `gitlab-admin` | `ClusterRoleBinding` | [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) roleRef | Creating a new cluster | +| `gitlab-admin` | `ClusterRoleBinding` | [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) role | Creating a new cluster | | `gitlab-token` | `Secret` | Token for `gitlab` ServiceAccount | Creating a new cluster | | Environment namespace | `Namespace` | Contains all environment-specific resources | Deploying to a cluster | | Environment namespace | `ServiceAccount` | Uses namespace of environment | Deploying to a cluster | | Environment namespace | `Secret` | Token for environment ServiceAccount | Deploying to a cluster | -| Environment namespace | `RoleBinding` | [`admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) roleRef | Deploying to a cluster | +| Environment namespace | `RoleBinding` | [`admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) role | Deploying to a cluster | The environment namespace `RoleBinding` was [updated](https://gitlab.com/gitlab-org/gitlab/-/issues/31113) in GitLab 13.6 -to `admin` roleRef. Previously, the `edit` roleRef was used. +to `admin` role. Previously, the `edit` role was used. ## ABAC cluster resources diff --git a/doc/user/project/integrations/mlflow_client.md b/doc/user/project/integrations/mlflow_client.md index 111037a63d7..e32e91c54ac 100644 --- a/doc/user/project/integrations/mlflow_client.md +++ b/doc/user/project/integrations/mlflow_client.md @@ -19,9 +19,9 @@ Setting up your integrations requires minimal changes to existing code. GitLab plays the role of proxy server, both for artifact storage and tracking data. It reflects the MLFlow [Scenario 5](https://www.mlflow.org/docs/latest/tracking.html#scenario-5-mlflow-tracking-server-enabled-with-proxied-artifact-storage-access). -## Enable MFlow Client Integration +## Enable MLFlow Client Integration -Complete this task to enable MFlow Client Integration. +Complete this task to enable MLFlow Client Integration. Prerequisites: diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md index 4d4d3c8804d..3d45e947c4c 100644 --- a/doc/user/project/integrations/webhooks.md +++ b/doc/user/project/integrations/webhooks.md @@ -52,7 +52,7 @@ specific to a group, including: ## Configure a webhook in GitLab -You can configure a webhook for a group or a project. +To configure a webhook for a project or group: 1. In your project or group, on the left sidebar, select **Settings > Webhooks**. 1. In **URL**, enter the URL of the webhook endpoint. @@ -219,10 +219,10 @@ You can filter push events by branch. Use one of the following options to filter - **All branches**: push events from all branches. - **Wildcard pattern**: push events from a branch that matches a wildcard pattern (for example, `*-stable` or `production/*`). -- **Regular expression**: push events from a branch that matches a regular expression (for example, `(feature|hotfix)/*`). +- **Regular expression**: push events from a branch that matches a regular expression (for example, `^(feature|hotfix)/`). -You can configure branch filtering -in the [webhook settings](#configure-a-webhook-in-gitlab) in your project. +To configure branch filtering for a project or group, see +[Configure a webhook in GitLab](#configure-a-webhook-in-gitlab). ## How image URLs are displayed in the webhook body diff --git a/doc/user/project/issues/managing_issues.md b/doc/user/project/issues/managing_issues.md index 0e12b2f2424..b0581e0a3e4 100644 --- a/doc/user/project/issues/managing_issues.md +++ b/doc/user/project/issues/managing_issues.md @@ -632,7 +632,7 @@ When this feature is enabled, you can use the OR operator (**is one of: `||`**) when you [filter the list of issues](#filter-the-list-of-issues). `is one of` represents an inclusive OR. For example, if you filter by `Assignee is one of Sidney Jones` and -`Assignee is one of Zhang Wei`, GitLab shows issues where either Sidney, Zhang, or both of them are assignees. +`Assignee is one of Zhang Wei`, GitLab shows issues where either `Sidney`, `Zhang`, or both of them are assignees. ### Filter issues by ID diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md index e8ec954df8f..a7627f12657 100644 --- a/doc/user/project/members/index.md +++ b/doc/user/project/members/index.md @@ -61,7 +61,7 @@ To add a user to a project: 1. Select **Invite members**. 1. Enter an email address and select a [role](../../permissions.md). 1. Optional. Select an **Access expiration date**. - From that date onwards, the user can no longer access the project. + From that date onward, the user can no longer access the project. 1. Select **Invite**. If the user has a GitLab account, they are added to the members list. @@ -110,7 +110,7 @@ To add a group to a project: 1. Select a group. 1. Select the highest [role](../../permissions.md) for users in the group. 1. Optional. Select an **Access expiration date**. - From that date onwards, the group can no longer access the project. + From that date onward, the group can no longer access the project. 1. Select **Invite**. The members of the group are not displayed on the **Members** tab. diff --git a/doc/user/project/merge_requests/reviews/data_usage.md b/doc/user/project/merge_requests/reviews/data_usage.md index 3a3af7a24bc..a73780004d2 100644 --- a/doc/user/project/merge_requests/reviews/data_usage.md +++ b/doc/user/project/merge_requests/reviews/data_usage.md @@ -39,6 +39,6 @@ Suggested Reviewers is off by default and requires a Project Owner or Admin to e Suggested Reviewers operates completely within the GitLab.com infrastructure providing the same level of [privacy](https://about.gitlab.com/privacy/) and [security](https://about.gitlab.com/security/) of any other feature of GitLab.com. -No new additional data is collected to enable this feature. GitLab is inferencing your merge request against a trained machine learning model. The content of your source code is not used as training data. Your data also never leaves GitLab.com, all training and inference is done within GitLab.com infrastructure. +No new additional data is collected to enable this feature. GitLab infers your merge request against a trained machine learning model. The content of your source code is not used as training data. Your data also never leaves GitLab.com, all training and inference is done within GitLab.com infrastructure. [Read more about the security of GitLab.com](https://about.gitlab.com/security/faq/) diff --git a/doc/user/project/pages/getting_started/pages_forked_sample_project.md b/doc/user/project/pages/getting_started/pages_forked_sample_project.md index 2f8b9478834..9841e52a089 100644 --- a/doc/user/project/pages/getting_started/pages_forked_sample_project.md +++ b/doc/user/project/pages/getting_started/pages_forked_sample_project.md @@ -57,7 +57,7 @@ you can rename it to `<namespace>.gitlab.io`, where `<namespace>` is your GitLab  -1. Open your SSG's configuration file and change the [base URL](../getting_started_part_one.md#urls-and-base-urls) +1. Open your SSG configuration file and change the [base URL](../getting_started_part_one.md#urls-and-base-urls) from `"project-name"` to `""`. The project name setting varies by SSG and may not be in the configuration file. ## Related topics diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md index 588d94729e2..a0c8073d6eb 100644 --- a/doc/user/project/pages/getting_started_part_one.md +++ b/doc/user/project/pages/getting_started_part_one.md @@ -87,7 +87,7 @@ Every Static Site Generator (SSG) default configuration expects to find your website under a (sub)domain (`example.com`), not in a subdirectory of that domain (`example.com/subdir`). Therefore, whenever you publish a project website (`namespace.gitlab.io/project-name`), -you must look for this configuration (base URL) on your SSG's +you must look for this configuration (base URL) on your static site generator's documentation and set it up to reflect this pattern. For example, for a Jekyll site, the `baseurl` is defined in the Jekyll diff --git a/doc/user/project/repository/web_editor.md b/doc/user/project/repository/web_editor.md index 773662edb17..cc89ca0fb1a 100644 --- a/doc/user/project/repository/web_editor.md +++ b/doc/user/project/repository/web_editor.md @@ -73,7 +73,7 @@ To close the preview panel, do one of the following: > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56159) in GitLab 13.11 for self-managed instances. Web Editor enables you to highlight a single line by adding specially formatted -hash information to the URL's file path segment. For example, the file path segment +hash information to the file path segment of the URL. For example, the file path segment `MY_FILE.js#L3` instructs the Web Editor to highlight line 3. The Web Editor also enables you to highlight multiple lines using a similar pattern. In diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md index 0200e9c4e7d..ee6af3b0aa6 100644 --- a/doc/user/project/web_ide/index.md +++ b/doc/user/project/web_ide/index.md @@ -80,7 +80,7 @@ If you are missing Syntax Highlighting support for any language, we prepared a s > - Full Solarized Dark Theme [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/219228) in GitLab 13.1. > - Full [Solarized Light](https://gitlab.com/gitlab-org/gitlab/-/issues/221035) and [Monokai](https://gitlab.com/gitlab-org/gitlab/-/issues/221034) Themes introduced in GitLab 13.6. -All the themes GitLab supports for syntax highlighting are applied to the Web IDE's entire screen. +All the themes GitLab supports for syntax highlighting are applied to the entire Web IDE screen. You can pick a theme from your [profile preferences](../../profile/preferences.md). | Solarized Dark Theme | Dark Theme | @@ -460,11 +460,11 @@ The Web IDE has a few limitations: connect to the runner. Try to stop and restart the terminal. If the problem persists, double check your runner configuration. -## VSCode Reimplementation +## VS Code Reimplementation > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95169) in GitLab 15.4 [with a flag](../../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default. As announced in [this blog post](https://about.gitlab.com/blog/2022/05/23/the-future-of-the-gitlab-web-ide/), -the current implementation of the Web IDE will be replaced with a [VSCode inspired implementation](https://gitlab.com/groups/gitlab-org/-/epics/7683). +the current implementation of the Web IDE will be replaced with a [VS Code inspired implementation](https://gitlab.com/groups/gitlab-org/-/epics/7683). This effort is currently under development. Follow [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7683) for updates and more information. diff --git a/lib/security/weak_passwords.rb b/lib/security/weak_passwords.rb index cfdb6ae8ffa..0772ef42fea 100644 --- a/lib/security/weak_passwords.rb +++ b/lib/security/weak_passwords.rb @@ -8,8 +8,13 @@ module Security # Substrings shorter than this may appear legitimately in a truly # random password. MINIMUM_SUBSTRING_SIZE = 4 - # Passwords of this length or more are more likely to randomly - # include a forbidden substring. + + # Passwords of 64+ characters are more likely to randomly include a + # forbidden substring. + # + # This length was chosen somewhat arbitrarily, balancing security, + # usability, and skipping checks on `::User.random_password` which + # is 128 chars. See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105755 PASSWORD_SUBSTRING_CHECK_MAX_LENGTH = 64 class << self diff --git a/qa/qa/page/merge_request/show.rb b/qa/qa/page/merge_request/show.rb index 21ad80b9ace..fba9dad2be9 100644 --- a/qa/qa/page/merge_request/show.rb +++ b/qa/qa/page/merge_request/show.rb @@ -434,7 +434,11 @@ module QA end def revert_change! - click_element(:revert_button, Page::Component::CommitModal) + # retry when the modal doesn't appear for large MRs as the onClick listener is initialized after the click + # https://gitlab.com/gitlab-org/gitlab/-/issues/366336 + retry_on_exception do + click_element(:revert_button, Page::Component::CommitModal) + end click_element(:submit_commit_button) end |