diff --git a/app/assets/javascripts/releases/components/asset_links_form.vue b/app/assets/javascripts/releases/components/asset_links_form.vue
index bbfc3cc6aeb690157cd1fe31b452f6d9cb2a8c8b..d0d1485d8e77672b30bde7180076820b0822dd55 100644
--- a/app/assets/javascripts/releases/components/asset_links_form.vue
+++ b/app/assets/javascripts/releases/components/asset_links_form.vue
@@ -124,10 +124,10 @@ export default {
@@ -164,7 +164,7 @@ export default {
@@ -186,7 +186,7 @@ export default {
@@ -200,7 +200,7 @@ export default {
/>
-
+
s labels.
MSG
+EE_CHANGE_WITH_FOSS_SPEC_CHANGE_MESSAGE = <<~MSG
+You've made some EE-specific changes, but only made changes to FOSS tests.
+This could be a sign that you're testing an EE-specific behavior in a FOSS test.
-has_app_changes = !helper.all_changed_files.grep(%r{\A(ee/)?(app|lib|db/(geo/)?(post_)?migrate)/}).empty?
-has_spec_changes = !helper.all_changed_files.grep(%r{\A(ee/)?spec/}).empty?
+Please make sure the spec files pass in AS-IF-FOSS mode either:
+
+1. Locally with `FOSS_ONLY=1 bin/rspec -- %s`.
+1. In the MR pipeline by verifying that the `rspec foss-impact` job has passed.
+1. In the MR pipelines by including `RUN AS-IF-FOSS` in the MR title (you can do it with the ``/title %s [RUN AS-IF-FOSS]`` quick action) and start a new MR pipeline.
+
+MSG
+
+has_app_changes = helper.all_changed_files.grep(%r{\A(app|lib|db/(geo/)?(post_)?migrate)/}).any?
+has_ee_app_changes = helper.all_changed_files.grep(%r{\Aee/(app|lib|db/(geo/)?(post_)?migrate)/}).any?
+spec_changes = helper.all_changed_files.grep(%r{\Aspec/})
+has_spec_changes = spec_changes.any?
+has_ee_spec_changes = helper.all_changed_files.grep(%r{\Aee/spec/}).any?
new_specs_needed = (gitlab.mr_labels & NO_SPECS_LABELS).empty?
-if has_app_changes && !has_spec_changes && new_specs_needed
+if (has_app_changes || has_ee_app_changes) && !(has_spec_changes || has_ee_spec_changes) && new_specs_needed
warn format(NO_NEW_SPEC_MESSAGE, labels: helper.labels_list(NO_SPECS_LABELS)), sticky: false
end
+
+# The only changes outside `ee/` are in `spec/`
+if has_ee_app_changes && has_spec_changes && !(has_app_changes || has_ee_spec_changes)
+ warn format(EE_CHANGE_WITH_FOSS_SPEC_CHANGE_MESSAGE, spec_files: spec_changes.join(" "), mr_title: gitlab.mr_json['title']), sticky: false
+end
diff --git a/db/migrate/20200603073101_change_constraint_name_on_resource_state_events.rb b/db/migrate/20200603073101_change_constraint_name_on_resource_state_events.rb
new file mode 100644
index 0000000000000000000000000000000000000000..ae95bc6d3c55325e8af39de59d5f11961b128738
--- /dev/null
+++ b/db/migrate/20200603073101_change_constraint_name_on_resource_state_events.rb
@@ -0,0 +1,16 @@
+# frozen_string_literal: true
+
+class ChangeConstraintNameOnResourceStateEvents < ActiveRecord::Migration[6.0]
+ DOWNTIME = false
+
+ NEW_CONSTRAINT_NAME = 'state_events_must_belong_to_issue_or_merge_request_or_epic'
+ OLD_CONSTRAINT_NAME = 'resource_state_events_must_belong_to_issue_or_merge_request_or_epic'
+
+ def up
+ execute "ALTER TABLE resource_state_events RENAME CONSTRAINT #{OLD_CONSTRAINT_NAME} TO #{NEW_CONSTRAINT_NAME};"
+ end
+
+ def down
+ execute "ALTER TABLE resource_state_events RENAME CONSTRAINT #{NEW_CONSTRAINT_NAME} TO #{OLD_CONSTRAINT_NAME};"
+ end
+end
diff --git a/db/structure.sql b/db/structure.sql
index 133d34b28cda7391489613535f46b5a519141c5d..fb8368538cee72cf7227222bc72c2cb92ca0b11d 100644
--- a/db/structure.sql
+++ b/db/structure.sql
@@ -5895,7 +5895,7 @@ CREATE TABLE public.resource_state_events (
created_at timestamp with time zone NOT NULL,
state smallint NOT NULL,
epic_id integer,
- CONSTRAINT resource_state_events_must_belong_to_issue_or_merge_request_or_ CHECK ((((issue_id <> NULL::bigint) AND (merge_request_id IS NULL) AND (epic_id IS NULL)) OR ((issue_id IS NULL) AND (merge_request_id <> NULL::bigint) AND (epic_id IS NULL)) OR ((issue_id IS NULL) AND (merge_request_id IS NULL) AND (epic_id <> NULL::integer))))
+ CONSTRAINT state_events_must_belong_to_issue_or_merge_request_or_epic CHECK ((((issue_id <> NULL::bigint) AND (merge_request_id IS NULL) AND (epic_id IS NULL)) OR ((issue_id IS NULL) AND (merge_request_id <> NULL::bigint) AND (epic_id IS NULL)) OR ((issue_id IS NULL) AND (merge_request_id IS NULL) AND (epic_id <> NULL::integer))))
);
CREATE SEQUENCE public.resource_state_events_id_seq
@@ -13776,5 +13776,6 @@ COPY "schema_migrations" (version) FROM STDIN;
20200527152116
20200527152657
20200528123703
+20200603073101
\.
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index a8a092f3f36620f71b171504887dc9ab861a98c7..2b737d76302f9f1c7881c9c8eed8380d08cec082 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -1,19 +1,25 @@
+---
+stage: Create
+group: Gitaly
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+type: reference
+---
+
# Gitaly
-[Gitaly](https://gitlab.com/gitlab-org/gitaly) is the service that
-provides high-level RPC access to Git repositories. Without it, no other
-components can read or write Git data. GitLab components that access Git
-repositories (GitLab Rails, GitLab Shell, GitLab Workhorse, etc.) act as clients
-to Gitaly. End users do not have direct access to Gitaly.
+[Gitaly](https://gitlab.com/gitlab-org/gitaly) is the service that provides high-level RPC access to
+Git repositories. Without it, no GitLab components can read or write Git data.
-On this page:
+In the Gitaly documentation:
- **Gitaly server** refers to any node that runs Gitaly itself.
- **Gitaly client** refers to any node that runs a process that makes requests of the
Gitaly server. Processes include, but are not limited to:
- - GitLab Rails application.
- - GitLab Shell.
- - GitLab Workhorse.
+ - [GitLab Rails application](https://gitlab.com/gitlab-org/gitlab).
+ - [GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell).
+ - [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse).
+
+GitLab end users do not have direct access to Gitaly.
CAUTION: **Caution:**
From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
@@ -22,7 +28,7 @@ support for NFS for Git repositories is scheduled to be removed. Upgrade to
## Architecture
-Here's a high-level architecture overview of how Gitaly is used.
+The following is a high-level architecture overview of how Gitaly is used.
![Gitaly architecture diagram](img/architecture_v12_4.png)
@@ -30,7 +36,7 @@ Here's a high-level architecture overview of how Gitaly is used.
The Gitaly service itself is configured via a [TOML configuration file](reference.md).
-If you want to change any of its settings:
+To change Gitaly settings:
**For Omnibus GitLab**
@@ -44,12 +50,20 @@ If you want to change any of its settings:
## Running Gitaly on its own server
-This is an optional way to deploy Gitaly which can benefit GitLab
-installations that are larger than a single machine. Most
-installations will be better served with the default configuration
-used by Omnibus and the GitLab source installation guide.
-Following transition to Gitaly on its own server,
-[Gitaly servers will need to be upgraded before Gitaly clients in your cluster](https://docs.gitlab.com/omnibus/update/#upgrading-gitaly-servers).
+By default, Gitaly is run on the same server as Gitaly clients and is
+[configured as above](#configuring-gitaly). Single-server installations are best served by
+this default configuration used by:
+
+- [Omnibus GitLab](https://docs.gitlab.com/omnibus/).
+- The GitLab [source installation guide](../../install/installation.md).
+
+However, Gitaly can be deployed to its own server, which can benefit GitLab installations that span
+multiple machines.
+
+NOTE: **Note:**
+When configured to run on their own servers, Gitaly servers
+[must be upgraded](https://docs.gitlab.com/omnibus/update/#upgrading-gitaly-servers) before Gitaly
+clients in your cluster.
Starting with GitLab 11.4, Gitaly is able to serve all Git requests without
requiring a shared NFS mount for Git repository data.
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 3dbb56bde328ad8347c1dee1d38810043518b877..3b98ac7316ddf0a8be63d9b38a0a25413693d0e9 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -1,4 +1,7 @@
---
+stage: Create
+group: Gitaly
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
type: reference
---
diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md
index 55366f20f1106c2808e70640bb638bd908c579c7..73aac6527c8c8d2139127839f0dd783c6a79a58c 100644
--- a/doc/administration/gitaly/reference.md
+++ b/doc/administration/gitaly/reference.md
@@ -1,4 +1,7 @@
---
+stage: Create
+group: Gitaly
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
type: reference
---
diff --git a/doc/administration/high_availability/gitaly.md b/doc/administration/high_availability/gitaly.md
index b1d6f771e0d2ca20d3c2a0713b9a78c78515993e..fd7d5365a2a82700861c3774623e7b120bbcbd01 100644
--- a/doc/administration/high_availability/gitaly.md
+++ b/doc/administration/high_availability/gitaly.md
@@ -1,4 +1,7 @@
---
+stage: Create
+group: Gitaly
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
type: reference
---
diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md
index effd7e37c49171a5efe4b796563c337d0f788462..43e4de224096efa89237322e27d76e61be1d1a72 100644
--- a/doc/policy/maintenance.md
+++ b/doc/policy/maintenance.md
@@ -144,6 +144,10 @@ It's also important to ensure that any background migrations have been fully com
before upgrading to a new major version. To see the current size of the `background_migration` queue,
[Check for background migrations before upgrading](../update/README.md#checking-for-background-migrations-before-upgrading).
+If your GitLab instance has any GitLab Runners associated with it, it is very
+important to upgrade the GitLab Runners to match the GitLab minor version that was
+upgraded to. This is to ensure [compatibility with GitLab versions](https://docs.gitlab.com/runner/#compatibility-with-gitlab-versions).
+
### Version 12 onwards: Extra step for major upgrades
From version 12 onwards, an additional step is required. More significant migrations
diff --git a/doc/user/markdown.md b/doc/user/markdown.md
index d9a2bab549f9871e814bee0614bfeb3bbbd5d4b7..f2e9bc4954a777baf2e77ac0c65052509d8a1a79 100644
--- a/doc/user/markdown.md
+++ b/doc/user/markdown.md
@@ -1017,7 +1017,7 @@ You can also use raw HTML in your Markdown, and it will usually work pretty well
See the documentation for HTML::Pipeline's [SanitizationFilter](https://github.com/jch/html-pipeline/blob/v2.12.3/lib/html/pipeline/sanitization_filter.rb#L42)
class for the list of allowed HTML tags and attributes. In addition to the default
-`SanitizationFilter` whitelist, GitLab allows `span`, `abbr`, `details` and `summary` elements.
+`SanitizationFilter` allowlist, GitLab allows `span`, `abbr`, `details` and `summary` elements.
```html
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index 3610a2122b25554a37ecd3d4cab8c81df38e71f0..61d0a8e460ad94a355f797bcd1cb8a0f10f3f1e1 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -250,7 +250,27 @@ When the `_gitlab_session` expires or isn't available, GitLab uses the `remember
to get you a new `_gitlab_session` and keep you signed in through browser restarts.
After your `remember_user_token` expires and your `_gitlab_session` is cleared/expired,
-you will be asked to sign in again to verify your identity (which is for security reasons).
+you will be asked to sign in again to verify your identity for security reasons.
+
+### Increased sign-in time
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20340) in GitLab 13.1.
+
+The `remember_user_token` lifetime of a cookie can now extend beyond the deadline set by `config.remember_for`, as the `config.extend_remember_period` flag is now set to true.
+
+GitLab uses both session and persistent cookies:
+
+- Session cookie: Session cookies are normally removed at the end of the browser session when the browser is closed. The `_gitlab_session` cookie has no expiration date.
+- Persistent cookie: The `remember_me_token` is a cookie with an expiration date of two weeks. GitLab activates this cookie if you click Remember Me when you sign in.
+
+By default, the server sets a time-to-live (TTL) of 1-week on any session that is used.
+
+When you close a browser, the session cookie may still remain. For example, Chrome has the "Continue where you left off" option that restores session cookies.
+In other words, as long as you access GitLab at least once every 2 weeks, you could remain signed in with GitLab, as long as your browser tab is open.
+The server continues to reset the TTL for that session, independent of whether 2FA is installed,
+If you close your browser and open it up again, the `remember_user_token` cookie allows your user to reauthenticate itself.
+
+Without the `config.extend_remember_period` flag, you would be forced to sign in again after two weeks.