From 3dcdea950204629bfcdcc9c0db250adab3b5c1ff Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Wed, 3 Jun 2020 15:08:05 +0000 Subject: [PATCH] Add latest changes from gitlab-org/gitlab@master --- .../releases/components/asset_links_form.vue | 10 ++-- app/models/clusters/applications/runner.rb | 2 +- app/services/issues/import_csv_service.rb | 2 +- .../process_alert_worker.rb | 3 +- ...ld-to-asset-links-on-edit-release-page.yml | 5 ++ ...issues-created-when-importing-from-csv.yml | 5 ++ ...management-fix-multiple-issue-creation.yml | 5 ++ ...ate-gitlab-runner-helm-chart-to-0-17-1.yml | 5 ++ danger/specs/Dangerfile | 27 +++++++++-- ...onstraint_name_on_resource_state_events.rb | 16 +++++++ db/structure.sql | 3 +- doc/administration/gitaly/index.md | 48 ++++++++++++------- doc/administration/gitaly/praefect.md | 3 ++ doc/administration/gitaly/reference.md | 3 ++ .../high_availability/gitaly.md | 3 ++ doc/policy/maintenance.md | 4 ++ doc/user/markdown.md | 2 +- doc/user/profile/index.md | 22 ++++++++- doc/user/project/import/index.md | 4 ++ .../reducing_the_repo_size_using_git.md | 3 ++ locale/gitlab.pot | 3 ++ package.json | 2 +- .../ide/components/repo_editor_spec.js | 13 ++++- .../issues/import_csv_service_spec.rb | 20 ++------ .../process_alert_worker_spec.rb | 35 +++++++------- yarn.lock | 8 ++-- 26 files changed, 186 insertions(+), 70 deletions(-) create mode 100644 changelogs/unreleased/219391-follow-up-from-add-type-field-to-asset-links-on-edit-release-page.yml create mode 100644 changelogs/unreleased/220051-duplicate-issues-created-when-importing-from-csv.yml create mode 100644 changelogs/unreleased/pl-alert-management-fix-multiple-issue-creation.yml create mode 100644 changelogs/unreleased/update-gitlab-runner-helm-chart-to-0-17-1.yml create mode 100644 db/migrate/20200603073101_change_constraint_name_on_resource_state_events.rb diff --git a/app/assets/javascripts/releases/components/asset_links_form.vue b/app/assets/javascripts/releases/components/asset_links_form.vue index bbfc3cc6aeb..d0d1485d8e7 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 00000000000..ae95bc6d3c5 --- /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 133d34b28cd..fb8368538ce 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 a8a092f3f36..2b737d76302 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 3dbb56bde32..3b98ac7316d 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 55366f20f11..73aac6527c8 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 b1d6f771e0d..fd7d5365a2a 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 effd7e37c49..43e4de22409 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 d9a2bab549f..f2e9bc4954a 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 3610a2122b2..61d0a8e460a 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.