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.