Commit c4db541c authored by 🤖 GitLab Bot 🤖's avatar 🤖 GitLab Bot 🤖

Add latest changes from gitlab-org/[email protected]

parent 603c7d4c
Pipeline #129374726 passed with stages
in 71 minutes and 31 seconds
......@@ -58,9 +58,6 @@ export default {
hasDiff() {
return hasDiff(this.file);
isActive() {
return this.currentDiffFileId === this.file.file_hash;
isFileTooLarge() {
return this.file.viewer.error === diffViewerErrors.too_large;
......@@ -146,7 +143,7 @@ export default {
'is-active': isActive,
'is-active': currentDiffFileId === file.file_hash,
class="diff-file file-holder"
......@@ -156,7 +153,6 @@ export default {
class="js-file-title file-title"
......@@ -55,11 +55,6 @@ export default {
type: Boolean,
required: true,
isActive: {
type: Boolean,
required: false,
default: false,
computed: {
...mapGetters('diffs', ['diffHasExpandedDiscussions', 'diffHasDiscussions']),
......@@ -163,9 +158,6 @@ export default {
class="js-file-title file-title file-title-flex-parent"
'is-active': isActive,
<div class="file-header-content">
......@@ -26,7 +26,7 @@ export default {
computed: {
...mapState('diffs', ['tree', 'renderTreeList', 'currentDiffFileId', 'viewedDiffFileIds']),
...mapState('diffs', ['tree', 'renderTreeList']),
...mapGetters('diffs', ['allBlobs']),
filteredTreeList() {
const search =;
......@@ -96,8 +96,6 @@ export default {
......@@ -26,7 +26,6 @@ export default () => ({
showTreeList: true,
currentDiffFileId: '',
projectPath: '',
viewedDiffFileIds: [],
commentForms: [],
highlightedRow: null,
renderTreeList: true,
......@@ -284,9 +284,6 @@ 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) {
import Vue from 'vue';
import ReleaseEditApp from './components/app_edit.vue';
import createStore from './stores';
import detailModule from './stores/modules/detail';
import createDetailModule from './stores/modules/detail';
export default () => {
const el = document.getElementById('js-edit-release-page');
const store = createStore({
modules: {
detail: detailModule,
detail: createDetailModule(el.dataset),
featureFlags: {
releaseShowPage: Boolean(gon.features?.releaseShowPage),
store.dispatch('detail/setInitialState', el.dataset);
return new Vue({
import Vue from 'vue';
import ReleaseShowApp from './components/app_show.vue';
import createStore from './stores';
import detailModule from './stores/modules/detail';
import createDetailModule from './stores/modules/detail';
export default () => {
const el = document.getElementById('js-show-release-page');
const store = createStore({
modules: {
detail: detailModule,
detail: createDetailModule(el.dataset),
store.dispatch('detail/setInitialState', el.dataset);
return new Vue({
......@@ -5,9 +5,6 @@ import { s__ } from '~/locale';
import { redirectTo } from '~/lib/utils/url_utility';
import { convertObjectPropsToCamelCase } from '~/lib/utils/common_utils';
export const setInitialState = ({ commit }, initialState) =>
commit(types.SET_INITIAL_STATE, initialState);
export const requestRelease = ({ commit }) => commit(types.REQUEST_RELEASE);
export const receiveReleaseSuccess = ({ commit }, data) =>
commit(types.RECEIVE_RELEASE_SUCCESS, data);
import * as actions from './actions';
import mutations from './mutations';
import state from './state';
import createState from './state';
export default {
export default initialState => ({
namespaced: true,
state: createState(initialState),
import * as types from './mutation_types';
export default {
[types.SET_INITIAL_STATE](state, initialState) {
Object.keys(state).forEach(key => {
state[key] = initialState[key];
[types.REQUEST_RELEASE](state) {
state.isFetchingRelease = true;
export default () => ({
projectId: null,
tagName: null,
releasesPagePath: null,
markdownDocsPath: null,
markdownPreviewPath: null,
updateReleaseApiDocsPath: null,
export default ({
}) => ({
release: null,
......@@ -18,16 +18,6 @@ export default {
type: Number,
required: true,
activeFile: {
type: String,
required: false,
default: '',
viewedFiles: {
type: Array,
required: false,
default: () => [],
computed: {
isTree() {
......@@ -44,8 +34,8 @@ export default {
fileClass() {
return {
'file-open': this.isBlob && this.file.opened,
'is-active': this.isBlob && ( || this.activeFile === this.file.fileHash),
'is-viewed': this.isBlob && this.viewedFiles.includes(this.file.fileHash),
'is-active': this.isBlob &&,
folder: this.isTree,
'is-open': this.file.opened,
......@@ -117,23 +107,15 @@ export default {
class="file-row text-left px-1 py-2 ml-n2 d-flex align-items-center"
@mouseleave="$emit('mouseleave', $event)"
<div class="file-row-name-container w-100 d-flex align-items-center">
class="file-row-name str-truncated d-inline-block"
{ 'folder font-weight-normal': isTree },
fileClass['is-viewed'] ? 'font-weight-normal' : 'font-weight-bold',
<div class="file-row-name-container">
<span ref="textOutput" :style="levelIndentation" class="file-row-name str-truncated">
class="file-row-icon align-middle mr-1"
:class="{ 'text-secondary': file.type === 'tree' }"
......@@ -150,8 +132,14 @@ export default {
.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;
......@@ -169,15 +157,24 @@ 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: 20px;
height: 19px;
line-height: 16px;
text-overflow: ellipsis;
white-space: nowrap;
.file-row-name .file-row-icon {
margin-right: 2px;
vertical-align: middle;
......@@ -69,11 +69,6 @@
}, {
background-color: $gray-200;
@media (min-width: map-get($grid-breakpoints, md)) {
&.conflict .file-title,
&.conflict .file-title-flex-parent {
......@@ -7,7 +7,7 @@ class X509Issuer < ApplicationRecord
validates :subject_key_identifier, presence: true, format: { with: /\A(\h{2}:){19}\h{2}\z/ }
# rfc 5280 - Issuer
validates :subject, presence: true
# rfc 5280 - CRL Distribution Points
# rfc 5280 - CRL Distribution Points
# cRLDistributionPoints extension using URI:http
validates :crl_url, presence: true, public_url: true
title: Highlight currently focused/viewed file in file tree
merge_request: 27703
type: changed
title: Update ApplicationLimits to prefer defaults
merge_request: 27574
type: changed
title: Extract X509::Signature from X509::Commit
merge_request: 27327
author: Roger Meier
type: changed
# frozen_string_literal: true
class UpdatePlanLimitsDefaults < ActiveRecord::Migration[6.0]
DOWNTIME = false
def up
change_column_default :plan_limits, :project_hooks, 100
change_column_default :plan_limits, :group_hooks, 50
change_column_default :plan_limits, :ci_project_subscriptions, 2
change_column_default :plan_limits, :ci_pipeline_schedules, 10
def down
change_column_default :plan_limits, :project_hooks, 0
change_column_default :plan_limits, :group_hooks, 0
change_column_default :plan_limits, :ci_project_subscriptions, 0
change_column_default :plan_limits, :ci_pipeline_schedules, 0
......@@ -4508,10 +4508,10 @@ CREATE TABLE public.plan_limits (
ci_active_pipelines integer DEFAULT 0 NOT NULL,
ci_pipeline_size integer DEFAULT 0 NOT NULL,
ci_active_jobs integer DEFAULT 0 NOT NULL,
project_hooks integer DEFAULT 0 NOT NULL,
group_hooks integer DEFAULT 0 NOT NULL,
ci_project_subscriptions integer DEFAULT 0 NOT NULL,
ci_pipeline_schedules integer DEFAULT 0 NOT NULL
project_hooks integer DEFAULT 100 NOT NULL,
group_hooks integer DEFAULT 50 NOT NULL,
ci_project_subscriptions integer DEFAULT 2 NOT NULL,
ci_pipeline_schedules integer DEFAULT 10 NOT NULL
CREATE SEQUENCE public.plan_limits_id_seq
......@@ -12747,6 +12747,7 @@ INSERT INTO "schema_migrations" (version) VALUES
......@@ -405,198 +405,4 @@ network and LDAP server response time will affect these metrics.
## Troubleshooting
### Referral error
If you see `LDAP search error: Referral` in the logs, or when troubleshooting
LDAP Group Sync, this error may indicate a configuration problem. The LDAP
configuration `/etc/gitlab/gitlab.rb` (Omnibus) or `config/gitlab.yml` (source)
is in YAML format and is sensitive to indentation. Check that `group_base` and
`admin_group` configuration keys are indented 2 spaces past the server
identifier. The default identifier is `main` and an example snippet looks like
the following:
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: ''
group_base: 'cn=my_group,ou=groups,dc=example,dc=com'
admin_group: 'my_admin_group'
[reconfigure]: ../
[restart]: ../
[^1]: In Active Directory, a user is marked as disabled/blocked if the user
account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
has bit 2 set. See <>
for more information.
### User DN has changed
When an LDAP user is created in GitLab, their LDAP DN is stored for later reference.
If GitLab cannot find a user by their DN, it will attempt to fallback
to finding the user by their email. If the lookup is successful, GitLab will
update the stored DN to the new value.
### User is not being added to a group
Sometimes you may think a particular user should be added to a GitLab group via
LDAP group sync, but for some reason it's not happening. There are several
things to check to debug the situation.
- Ensure LDAP configuration has a `group_base` specified. This configuration is
required for group sync to work properly.
- Ensure the correct LDAP group link is added to the GitLab group. Check group
links by visiting the GitLab group, then **Settings dropdown > LDAP groups**.
- Check that the user has an LDAP identity:
1. Sign in to GitLab as an administrator user.
1. Navigate to **Admin Area > Users**.
1. Search for the user
1. Open the user, by clicking on their name. Do not click 'Edit'.
1. Navigate to the **Identities** tab. There should be an LDAP identity with
an LDAP DN as the 'Identifier'.
If all of the above looks good, jump in to a little more advanced debugging.
Often, the best way to learn more about why group sync is behaving a certain
way is to enable debug logging. There is verbose output that details every
step of the sync.
1. Start a Rails console:
# For Omnibus installations
sudo gitlab-rails console
# For installations from source
sudo -u git -H bundle exec rails console -e production
1. Set the log level to debug (only for this session):
Rails.logger.level = Logger::DEBUG
1. Choose a GitLab group to test with. This group should have an LDAP group link
already configured. If the output is `nil`, the group could not be found.
If a bunch of group attributes are output, your group was found successfully.
group = Group.find_by(name: 'my_group')
# Output
=> #<Group:0x007fe825196558 id: 1234, name: "my_group"...>
1. Run a group sync for this particular group.
1. Look through the output of the sync. See [example log output](#example-log-output)
below for more information about the output.
1. If you still aren't able to see why the user isn't being added, query the
LDAP group directly to see what members are listed. Still in the Rails console,
run the following query:
adapter ='ldapmain') # If `main` is the LDAP provider
ldap_group = EE::Gitlab::Auth::Ldap::Group.find_by_cn('group_cn_here', adapter)
# Output
=> #<EE::Gitlab::Auth::Ldap::Group:0x007fcbdd0bb6d8
1. Query the LDAP group's member DNs and see if the user's DN is in the list.
One of the DNs here should match the 'Identifier' from the LDAP identity
checked earlier. If it doesn't, the user does not appear to be in the LDAP
# Output
=> ["uid=john,ou=people,dc=example,dc=com", "uid=mary,ou=people,dc=example,dc=com"]
1. Some LDAP servers don't store members by DN. Rather, they use UIDs instead.
If you didn't see results from the last query, try querying by UIDs instead.
# Output
=> ['john','mary']
#### Example log output
The output of the last command will be very verbose, but contains lots of
helpful information. For the most part you can ignore log entries that are SQL
Indicates the point where syncing actually begins:
Started syncing all providers for 'my_group' group
The follow entry shows an array of all user DNs GitLab sees in the LDAP server.
Note that these are the users for a single LDAP group, not a GitLab group. If
you have multiple LDAP groups linked to this GitLab group, you will see multiple
log entries like this - one for each LDAP group. If you don't see an LDAP user
DN in this log entry, LDAP is not returning the user when we do the lookup.
Verify the user is actually in the LDAP group.
Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com",
"uid=mary0,ou=people,dc=example,dc=com", "uid=john1,ou=people,dc=example,dc=com",
"uid=mary1,ou=people,dc=example,dc=com", "uid=john2,ou=people,dc=example,dc=com",
"uid=mary2,ou=people,dc=example,dc=com", "uid=john3,ou=people,dc=example,dc=com",
"uid=mary3,ou=people,dc=example,dc=com", "uid=john4,ou=people,dc=example,dc=com",
Shortly after each of the above entries, you will see a hash of resolved member
access levels. This hash represents all user DNs GitLab thinks should have
access to this group, and at which access level (role). This hash is additive,
and more DNs may be added, or existing entries modified, based on additional
LDAP group lookups. The very last occurrence of this entry should indicate
exactly which users GitLab believes should be added to the group.
NOTE: **Note:**
10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
and 50 is 'Owner'.
Resolved 'my_group' group member access: {"uid=john0,ou=people,dc=example,dc=com"=>30,
"uid=mary0,ou=people,dc=example,dc=com"=>30, "uid=john1,ou=people,dc=example,dc=com"=>30,
"uid=mary1,ou=people,dc=example,dc=com"=>30, "uid=john2,ou=people,dc=example,dc=com"=>30,
"uid=mary2,ou=people,dc=example,dc=com"=>30, "uid=john3,ou=people,dc=example,dc=com"=>30,
"uid=mary3,ou=people,dc=example,dc=com"=>30, "uid=john4,ou=people,dc=example,dc=com"=>30,
It's not uncommon to see warnings like the following. These indicate that GitLab
would have added the user to a group, but the user could not be found in GitLab.
Usually this is not a cause for concern.
If you think a particular user should already exist in GitLab, but you're seeing
this entry, it could be due to a mismatched DN stored in GitLab. See
[User DN has changed](#User-DN-has-changed) to update the user's LDAP identity.
User with DN `uid=john0,ou=people,dc=example,dc=com` should have access
to 'my_group' group but there is no user in GitLab with that
identity. Membership will be updated once the user signs in for
the first time.
Finally, the following entry says syncing has finished for this group:
Finished syncing all providers for 'my_group' group
Please see our [administrator guide to troubleshooting LDAP](
This diff is collapsed.
......@@ -552,74 +552,4 @@ be mandatory and clients cannot be authenticated with the TLS protocol.
## Troubleshooting
If a user account is blocked or unblocked due to the LDAP configuration, a
message will be logged to `application.log`.
If there is an unexpected error during an LDAP lookup (configuration error,
timeout), the login is rejected and a message will be logged to
### Debug LDAP user filter with ldapsearch
This example uses `ldapsearch` and assumes you are using ActiveDirectory. The
following query returns the login names of the users that will be allowed to
log in to GitLab if you configure your own user_filter.
ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$base" "$user_filter" sAMAccountName
- Variables beginning with a `$` refer to a variable from the LDAP section of
your configuration file.
- Replace `ldaps://` with `ldap://` if you are using the plain authentication method.
Port `389` is the default `ldap://` port and `636` is the default `ldaps://`
- We are assuming the password for the bind_dn user is in bind_dn_password.txt.
### Invalid credentials when logging in
- Make sure the user you are binding with has enough permissions to read the user's
tree and traverse it.
- Check that the `user_filter` is not blocking otherwise valid users.
- Run the following check command to make sure that the LDAP settings are
correct and GitLab can see your users:
# For Omnibus installations
sudo gitlab-rake gitlab:ldap:check
# For installations from source
sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
### Connection refused
If you are getting 'Connection Refused' errors when trying to connect to the
LDAP server please double-check the LDAP `port` and `encryption` settings used by
GitLab. Common combinations are `encryption: 'plain'` and `port: 389`, OR
`encryption: 'simple_tls'` and `port: 636`.
### Connection times out
If GitLab cannot reach your LDAP endpoint, you will see a message like this:
Could not authenticate you from Ldapmain because "Connection timed out - user specified timeout".
If your configured LDAP provider and/or endpoint is offline or otherwise unreachable by GitLab, no LDAP user will be able to authenticate and log in. GitLab does not cache or store credentials for LDAP users to provide authentication during an LDAP outage.
Contact your LDAP provider or administrator if you are seeing this error.
### No file specified as Settingslogic source
If `sudo gitlab-ctl reconfigure` fails with the following error, or you are seeing it in
the logs, you may have malformed YAML in `/etc/gitlab/gitlab.rb`:
Errno::ENOENT: No such file or directory - No file specified as Settingslogic source
This issue is frequently due to the spacing in your YAML file. To fix the problem,
verify the syntax with **spacing** against the
[documentation for the configuration of LDAP](#configuration).
Please see our [administrator guide to troubleshooting LDAP](
......@@ -28,7 +28,7 @@ rake gitlab:ldap:check[50]
## Run a Group Sync
> [Introduced]( in [GitLab Starter]( 12.3.
> [Introduced]( in [GitLab Starter]( 12.2.
The following task will run a [group sync](../auth/ immediately. This is valuable
when you'd like to update all configured group memberships against LDAP without
......@@ -536,98 +536,6 @@ group = Group.find_by_path_or_name('group-name')
### LDAP commands in the rails console
TIP: **TIP:**
Use the rails runner to avoid entering the rails console in the first place.
This is great when only a single command (such as a UserSync or GroupSync)
is needed.
# Get debug output
Rails.logger.level = Logger::DEBUG
# Run a UserSync (normally performed once a day)
# Run a GroupSync for all groups (9.3-)
# Run a GroupSync for all groups (9.3+)