Commit 99c6ace2 authored by GitLab Bot's avatar GitLab Bot
Browse files

Add latest changes from gitlab-org/gitlab@master

parent c94ea6cfefc1
......@@ -58,6 +58,9 @@ export default {
hasDiff() {
return hasDiff(this.file);
},
isActive() {
return this.currentDiffFileId === this.file.file_hash;
},
isFileTooLarge() {
return this.file.viewer.error === diffViewerErrors.too_large;
},
......@@ -143,7 +146,7 @@ export default {
<div
:id="file.file_hash"
:class="{
'is-active': currentDiffFileId === file.file_hash,
'is-active': isActive,
}"
class="diff-file file-holder"
>
......@@ -153,6 +156,7 @@ export default {
:collapsible="true"
:expanded="!isCollapsed"
:add-merge-request-buttons="true"
:is-active="isActive"
class="js-file-title file-title"
@toggleFile="handleToggle"
@showForkMessage="showForkMessage"
......
......@@ -55,6 +55,11 @@ export default {
type: Boolean,
required: true,
},
isActive: {
type: Boolean,
required: false,
default: false,
},
},
computed: {
...mapGetters('diffs', ['diffHasExpandedDiscussions', 'diffHasDiscussions']),
......@@ -158,6 +163,9 @@ export default {
<div
ref="header"
class="js-file-title file-title file-title-flex-parent"
:class="{
'is-active': isActive,
}"
@click.self="handleToggleFile"
>
<div class="file-header-content">
......
......@@ -26,7 +26,7 @@ export default {
};
},
computed: {
...mapState('diffs', ['tree', 'renderTreeList']),
...mapState('diffs', ['tree', 'renderTreeList', 'currentDiffFileId', 'viewedDiffFileIds']),
...mapGetters('diffs', ['allBlobs']),
filteredTreeList() {
const search = this.search.toLowerCase().trim();
......@@ -96,6 +96,8 @@ export default {
:level="0"
:hide-file-stats="hideFileStats"
:file-row-component="$options.DiffFileRow"
:active-file="currentDiffFileId"
:viewed-files="viewedDiffFileIds"
@toggleTreeOpen="toggleTreeOpen"
@clickFile="scrollToFile"
/>
......
......@@ -26,6 +26,7 @@ export default () => ({
showTreeList: true,
currentDiffFileId: '',
projectPath: '',
viewedDiffFileIds: [],
commentForms: [],
highlightedRow: null,
renderTreeList: true,
......
......@@ -284,6 +284,9 @@ export default {
},
[types.UPDATE_CURRENT_DIFF_FILE_ID](state, fileId) {
state.currentDiffFileId = fileId;
if (!state.viewedDiffFileIds.includes(fileId)) {
state.viewedDiffFileIds = [fileId, ...state.viewedDiffFileIds];
}
},
[types.OPEN_DIFF_FILE_COMMENT_FORM](state, formData) {
state.commentForms.push({
......
......@@ -18,6 +18,16 @@ export default {
type: Number,
required: true,
},
activeFile: {
type: String,
required: false,
default: '',
},
viewedFiles: {
type: Array,
required: false,
default: () => [],
},
},
computed: {
isTree() {
......@@ -34,8 +44,8 @@ export default {
fileClass() {
return {
'file-open': this.isBlob && this.file.opened,
'is-active': this.isBlob && this.file.active,
folder: this.isTree,
'is-active': this.isBlob && (this.file.active || this.activeFile === this.file.fileHash),
'is-viewed': this.isBlob && this.viewedFiles.includes(this.file.fileHash),
'is-open': this.file.opened,
};
},
......@@ -107,15 +117,23 @@ export default {
v-else
:class="fileClass"
:title="file.name"
class="file-row"
class="file-row text-left px-1 py-2 ml-n2 d-flex align-items-center"
role="button"
@click="clickFile"
@mouseleave="$emit('mouseleave', $event)"
>
<div class="file-row-name-container">
<span ref="textOutput" :style="levelIndentation" class="file-row-name str-truncated">
<div class="file-row-name-container w-100 d-flex align-items-center">
<span
ref="textOutput"
:style="levelIndentation"
class="file-row-name str-truncated d-inline-block"
:class="[
{ 'folder font-weight-normal': isTree },
fileClass['is-viewed'] ? 'font-weight-normal' : 'font-weight-bold',
]"
>
<file-icon
class="file-row-icon"
class="file-row-icon align-middle mr-1"
:class="{ 'text-secondary': file.type === 'tree' }"
:file-name="file.name"
:loading="file.loading"
......@@ -132,14 +150,8 @@ export default {
<style>
.file-row {
display: flex;
align-items: center;
height: 32px;
padding: 4px 8px;
margin-left: -8px;
margin-right: -8px;
border-radius: 3px;
text-align: left;
cursor: pointer;
}
......@@ -157,24 +169,15 @@ export default {
}
.file-row-name-container {
display: flex;
width: 100%;
align-items: center;
overflow: visible;
}
.file-row-name {
display: inline-block;
flex: 1;
max-width: inherit;
height: 19px;
height: 20px;
line-height: 16px;
text-overflow: ellipsis;
white-space: nowrap;
}
.file-row-name .file-row-icon {
margin-right: 2px;
vertical-align: middle;
}
</style>
......@@ -69,6 +69,11 @@
}
}
.file-title.is-active,
.file-title-flex-parent.is-active {
background-color: $gray-200;
}
@media (min-width: map-get($grid-breakpoints, md)) {
&.conflict .file-title,
&.conflict .file-title-flex-parent {
......
......@@ -86,7 +86,11 @@ def commit_status(sha, ref)
def calculate_reactive_cache(sha, ref)
response = get_path("httpAuth/app/rest/builds/branch:unspecified:any,revision:#{sha}")
{ build_page: read_build_page(response), commit_status: read_commit_status(response) }
if response
{ build_page: read_build_page(response), commit_status: read_commit_status(response) }
else
{ build_page: teamcity_url, commit_status: :error }
end
end
def execute(data)
......@@ -149,7 +153,7 @@ def build_url(path)
end
def get_path(path)
Gitlab::HTTP.get(build_url(path), verify: false, basic_auth: basic_auth)
Gitlab::HTTP.try_get(build_url(path), verify: false, basic_auth: basic_auth, extra_log_info: { project_id: project_id })
end
def post_to_build_queue(data, branch)
......
......@@ -4,14 +4,12 @@
module Projects
module LfsPointers
class LfsListService < BaseService
REV = 'HEAD'
# Retrieve all lfs blob pointers and returns a hash
# with the structure { lfs_file_oid => lfs_file_size }
def execute
return {} unless project&.lfs_enabled?
Gitlab::Git::LfsChanges.new(project.repository, REV)
Gitlab::Git::LfsChanges.new(project.repository)
.all_pointers
.map! { |blob| [blob.lfs_oid, blob.lfs_size] }
.to_h
......
......@@ -3,7 +3,7 @@
class AuthorizedKeysWorker
include ApplicationWorker
PERMITTED_ACTIONS = [:add_key, :remove_key].freeze
PERMITTED_ACTIONS = %w[add_key remove_key].freeze
feature_category :source_code_management
urgency :high
......@@ -13,11 +13,13 @@ class AuthorizedKeysWorker
def perform(action, *args)
return unless Gitlab::CurrentSettings.authorized_keys_enabled?
case action
when :add_key
case action.to_s
when 'add_key'
authorized_keys.add_key(*args)
when :remove_key
when 'remove_key'
authorized_keys.remove_key(*args)
else
raise "Unknown action: #{action.inspect}"
end
end
......
......@@ -13,7 +13,7 @@ def perform(action, *arg)
# enqueued in the previous release, so handle them here.
#
# See https://gitlab.com/gitlab-org/gitlab/-/issues/25095 for more details
if AuthorizedKeysWorker::PERMITTED_ACTIONS.include?(action)
if AuthorizedKeysWorker::PERMITTED_ACTIONS.include?(action.to_s)
AuthorizedKeysWorker.new.perform(action, *arg)
return
......
---
title: Optimize template_repositories query by using batch counting
merge_request: 27352
author:
type: performance
---
title: Fix updating the authorized_keys file
merge_request: 27798
author:
type: fixed
---
title: Highlight currently focused/viewed file in file tree
merge_request: 27703
author:
type: changed
---
title: Set commit status to failed if the TeamCity connection is refused
merge_request: 27395
author:
type: fixed
# frozen_string_literal: true
class AddIndexOnNamespaceIdAndIdToProjects < ActiveRecord::Migration[6.0]
include Gitlab::Database::MigrationHelpers
DOWNTIME = false
disable_ddl_transaction!
def up
add_concurrent_index :projects, [:namespace_id, :id]
remove_concurrent_index :projects, :namespace_id
end
def down
add_concurrent_index :projects, :namespace_id
remove_concurrent_index :projects, [:namespace_id, :id]
end
end
# frozen_string_literal: true
class AddMaxPersonalAccessTokenLifetimeToNamespaces < ActiveRecord::Migration[6.0]
include Gitlab::Database::MigrationHelpers
DOWNTIME = false
def up
with_lock_retries do
add_column :namespaces, :max_personal_access_token_lifetime, :integer
end
end
def down
with_lock_retries do
remove_column :namespaces, :max_personal_access_token_lifetime
end
end
end
......@@ -3944,7 +3944,8 @@ CREATE TABLE public.namespaces (
max_artifacts_size integer,
mentions_disabled boolean,
default_branch_protection smallint,
unlock_membership_to_ldap boolean
unlock_membership_to_ldap boolean,
max_personal_access_token_lifetime integer
);
CREATE SEQUENCE public.namespaces_id_seq
......@@ -9656,7 +9657,7 @@ CREATE INDEX index_projects_on_name_and_id ON public.projects USING btree (name,
CREATE INDEX index_projects_on_name_trigram ON public.projects USING gin (name public.gin_trgm_ops);
CREATE INDEX index_projects_on_namespace_id ON public.projects USING btree (namespace_id);
CREATE INDEX index_projects_on_namespace_id_and_id ON public.projects USING btree (namespace_id, id);
CREATE INDEX index_projects_on_path_and_id ON public.projects USING btree (path, id);
......@@ -12701,6 +12702,7 @@ INSERT INTO "schema_migrations" (version) VALUES
('20200313101649'),
('20200313123934'),
('20200316111759'),
('20200316162648'),
('20200316173312'),
('20200317142110'),
('20200318152134'),
......@@ -12708,5 +12710,6 @@ INSERT INTO "schema_migrations" (version) VALUES
('20200318163148'),
('20200318164448'),
('20200318165448'),
('20200319203901');
('20200319203901'),
('20200323075043');
......@@ -73,6 +73,9 @@ from teams other than your own.
**approved by a [UX lead](https://about.gitlab.com/company/team/)**.
1. If your merge request includes a new dependency or a filesystem change, it must be
**approved by a [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/distribution/#how-to-work-with-distribution) for more details.
1. If your merge request includes documentation changes, it must be **approved
by a [Technical writer](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers)**, based on
the appropriate [product category](https://about.gitlab.com/handbook/product/categories/).
#### Security requirements
......@@ -84,12 +87,17 @@ The responsibility to find the best solution and implement it lies with the
merge request author.
Before assigning a merge request to a maintainer for approval and merge, they
should be confident that it actually solves the problem it was meant to solve,
that it does so in the most appropriate way, that it satisfies all requirements,
and that there are no remaining bugs, logical problems, uncovered edge cases,
or known vulnerabilities. The best way to do this, and to avoid unnecessary
back-and-forth with reviewers, is to perform a self-review of your own merge
request, following the [Code Review](#reviewing-a-merge-request) guidelines.
should be confident that:
- It actually solves the problem it was meant to solve.
- It does so in the most appropriate way.
- It satisfies all requirements.
- There are no remaining bugs, logical problems, uncovered edge cases,
or known vulnerabilities.
The best way to do this, and to avoid unnecessary back-and-forth with reviewers,
is to perform a self-review of your own merge request, following the
[Code Review](#reviewing-a-merge-request) guidelines.
To reach the required level of confidence in their solution, an author is expected
to involve other people in the investigation and implementation processes as
......@@ -110,11 +118,11 @@ request diff alerting the reviewer to anything important as well as for anything
that demands further explanation or attention. Examples of content that may
warrant a comment could be:
- The addition of a linting rule (Rubocop, JS etc)
- The addition of a library (Ruby gem, JS lib etc)
- Where not obvious, a link to the parent class or method
- Any benchmarking performed to complement the change
- Potentially insecure code
- The addition of a linting rule (Rubocop, JS etc).
- The addition of a library (Ruby gem, JS lib etc).
- Where not obvious, a link to the parent class or method.
- Any benchmarking performed to complement the change.
- Potentially insecure code.
Avoid:
......@@ -233,6 +241,11 @@ first time.
addressed. If there's an open reply, an open thread, a suggestion,
a question, or anything else, the thread should be left to be resolved
by the reviewer.
- It should not be assumed that all feedback requires their recommended changes
to be incorporated into the MR before it is merged. It is a judgment call by
the MR author and the reviewer as to if this is required, or if a follow-up
issue should be created to address the feedback in the future after the MR in
question is merged.
- Push commits based on earlier rounds of feedback as isolated commits to the
branch. Do not squash until the branch is ready to merge. Reviewers should be
able to read individual updates based on their earlier feedback.
......
......@@ -48,13 +48,8 @@ request is as follows:
but do not change the commit history if you're working on shared branches though.
1. Push the commit(s) to your working branch in your fork.
1. Submit a merge request (MR) to the `master` branch in the main GitLab project.
1. Your merge request needs at least 1 approval, but feel free to require more.
For instance if you're touching both backend and frontend code, it's a good idea
to require 2 approvals: 1 from a backend maintainer and 1 from a frontend
maintainer.
1. If you're submitting changes to documentation, you'll need approval from a technical
writer, based on the appropriate [product category](https://about.gitlab.com/handbook/product/categories/).
Only assign the MR to them when it's ready for docs review.
1. Your merge request needs at least 1 approval, but depending on your changes
you might need additional approvals. Refer to the [Approval guidelines](../code_review.md#approval-guidelines).
1. You don't have to select any specific approvers, but you can if you really want
specific people to approve your merge request.
1. The MR title should describe the change you want to make.
......@@ -66,18 +61,12 @@ request is as follows:
1. Mention the issue(s) your merge request solves, using the `Solves #XXX` or
`Closes #XXX` syntax to [auto-close](../../user/project/issues/managing_issues.md#closing-issues-automatically)
the issue(s) once the merge request is merged.
1. If you're allowed to (Core team members, for example), set a relevant milestone
and [labels](issue_workflow.md).
1. If the MR changes the UI, you'll need approval from a Product Designer (UX), based on the appropriate [product category](https://about.gitlab.com/handbook/product/categories/). UI changes should use available components from the GitLab Design System, [Pajamas](https://design.gitlab.com/). The MR must include *Before* and *After* screenshots.
1. If you're allowed to, set a relevant milestone and [labels](issue_workflow.md).
1. UI changes should use available components from the GitLab Design System,
[Pajamas](https://design.gitlab.com/). The MR must include *Before* and
*After* screenshots.
1. If the MR changes CSS classes, please include the list of affected pages, which
can be found by running `grep css-class ./app -R`.
1. Be prepared to answer questions and incorporate feedback into your MR with new
commits. Once you have fully addressed a suggestion from a reviewer, click the
"Resolve thread" button beneath it to mark it resolved.
1. The merge request author resolves only the threads they have fully addressed.
If there's an open reply or thread, a suggestion, a question, or anything else,
the thread should be left to be resolved by the reviewer.
1. It should not be assumed that all feedback requires their recommended changes to be incorporated into the MR before it is merged. It is a judgment call by the MR author and the reviewer as to if this is required, or if a follow-up issue should be created to address the feedback in the future after the MR in question is merged.
1. If your MR touches code that executes shell commands, reads or opens files, or
handles paths to files on disk, make sure it adheres to the
[shell command guidelines](../shell_commands.md)
......@@ -98,6 +87,10 @@ request is as follows:
`doc/update/upgrading_from_source.md` in the same merge request. If these
instructions are specific to a version, add them to the "Version specific
upgrading instructions" section.
1. Read and adhere to
[The responsibility of the merge request author](../code_review.md#the-responsibility-of-the-merge-request-author).
1. Read and follow
[Having your merge request reviewed](../code_review.md#having-your-merge-request-reviewed).
If you would like quick feedback on your merge request feel free to mention someone
from the [core team](https://about.gitlab.com/community/core-team/) or one of the
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment