Commit 33aa02e7 authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 1219a9dc
import { shallowMount } from '@vue/test-utils';
import Popover from '~/blob/suggest_gitlab_ci_yml/components/popover.vue';
import { mockTracking, unmockTracking, triggerEvent } from 'helpers/tracking_helper';
import * as utils from '~/lib/utils/common_utils';
import { GlButton } from '@gitlab/ui';
jest.mock('~/lib/utils/common_utils', () => ({
...jest.requireActual('~/lib/utils/common_utils'),
scrollToElement: jest.fn(),
}));
const target = 'gitlab-ci-yml-selector';
const dismissKey = '99';
const defaultTrackLabel = 'suggest_gitlab_ci_yml';
const commitTrackLabel = 'suggest_commit_first_project_gitlab_ci_yml';
const dismissCookie = 'suggest_gitlab_ci_yml_99';
const humanAccess = 'owner';
describe('Suggest gitlab-ci.yml Popover', () => {
let wrapper;
function createWrapper(trackLabel) {
wrapper = shallowMount(Popover, {
propsData: {
target,
trackLabel,
dismissKey,
humanAccess,
},
stubs: {
GlButton,
GlIcon
}
slots: {
title: '<gl-button><gl-icon /> </gl-button>',
}
});
}
afterEach(() => {
wrapper.destroy();
wrapper = null;
});
describe('when no dismiss cookie is set', () => {
beforeEach(() => {
createWrapper(defaultTrackLabel);
});
it('sets popoverDismissed to false', () => {
expect(wrapper.vm.popoverDismissed).toEqual(false);
});
});
describe('when the dismiss cookie is set', () => {
beforeEach(() => {
utils.setCookie(dismissCookie, true);
createWrapper(defaultTrackLabel);
});
it('sets popoverDismissed to true', () => {
expect(wrapper.vm.popoverDismissed).toEqual(true);
});
afterEach(() => {
utils.removeCookie(dismissCookie);
});
});
describe('tracking', () => {
let trackingSpy;
beforeEach(() => {
createWrapper(commitTrackLabel);
trackingSpy = mockTracking('_category_', wrapper.element, jest.spyOn);
});
afterEach(() => {
unmockTracking();
});
it('sends a tracking event with the expected properties for the popover being viewed', () => {
const expectedCategory = undefined;
const expectedAction = undefined;
const expectedLabel = 'suggest_commit_first_project_gitlab_ci_yml';
const expectedProperty = 'owner';
document.body.dataset.page = 'projects:blob:new';
wrapper.vm.trackOnShow();
expect(trackingSpy).toHaveBeenCalledWith(expectedCategory, expectedAction, {
label: expectedLabel,
property: expectedProperty,
});
});
it('sends a tracking event when the popover is dismissed', () => {
const expectedLabel = commitTrackLabel;
const expectedProperty = 'owner';
const expectedValue = '10';
const dismissButton = wrapper.find(GlButton);
console.log(wrapper.html());
triggerEvent(dismissButton.element);
expect(trackingSpy).toHaveBeenCalledWith('_category_', 'click_button', {
label: expectedLabel,
property: expectedProperty,
value: expectedValue,
});
});
});
describe('when the popover is mounted with the trackLabel of the Confirm button popover at the bottom of the page', () => {
it('calls scrollToElement so that the Confirm button and popover will be in sight', () => {
const scrollToElementSpy = jest.spyOn(utils, 'scrollToElement');
createWrapper(commitTrackLabel);
expect(scrollToElementSpy).toHaveBeenCalled();
});
});
});
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-9.6-graphicsmagick-1.3.34"
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.26-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-9.6-graphicsmagick-1.3.34"
stages:
- sync
......
......@@ -15,7 +15,7 @@
- .default-retry
- .default-before_script
- .assets-compile-cache
image: registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-graphicsmagick-1.3.34-docker-19.03.1
image: registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-git-2.26-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-graphicsmagick-1.3.34-docker-19.03.1
stage: prepare
services:
- docker:19.03.0-dind
......
......@@ -38,7 +38,7 @@
POSTGRES_HOST_AUTH_METHOD: trust
.use-pg10:
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-10-graphicsmagick-1.3.34"
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.26-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-10-graphicsmagick-1.3.34"
services:
- name: postgres:10.12
command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
......@@ -47,7 +47,7 @@
POSTGRES_HOST_AUTH_METHOD: trust
.use-pg11:
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-11-graphicsmagick-1.3.34"
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.26-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-11-graphicsmagick-1.3.34"
services:
- name: postgres:11.6
command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
......@@ -65,7 +65,7 @@
POSTGRES_HOST_AUTH_METHOD: trust
.use-pg10-ee:
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-10-graphicsmagick-1.3.34"
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.26-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-10-graphicsmagick-1.3.34"
services:
- name: postgres:10.12
command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
......@@ -75,7 +75,7 @@
POSTGRES_HOST_AUTH_METHOD: trust
.use-pg11-ee:
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-11-graphicsmagick-1.3.34"
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.26-lfs-2.9-chrome-73.0-node-12.x-yarn-1.21-postgresql-11-graphicsmagick-1.3.34"
services:
- name: postgres:11.6
command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
......
......@@ -420,4 +420,3 @@ RSpec/RepeatedExample:
- 'ee/spec/models/group_spec.rb'
- 'ee/spec/services/boards/lists/update_service_spec.rb'
- 'ee/spec/services/geo/repository_verification_primary_service_spec.rb'
- 'ee/spec/workers/geo/file_download_dispatch_worker_spec.rb'
......@@ -6,6 +6,7 @@ import EditBlob from './edit_blob';
import BlobFileDropzone from '../blob/blob_file_dropzone';
import initPopover from '~/blob/suggest_gitlab_ci_yml';
import { setCookie } from '~/lib/utils/common_utils';
import Tracking from '~/tracking';
export default () => {
const editBlobForm = $('.js-edit-blob-form');
......@@ -66,10 +67,19 @@ export default () => {
initPopover(suggestEl);
if (commitButton) {
const commitCookieName = `suggest_gitlab_ci_yml_commit_${suggestEl.dataset.dismissKey}`;
const { dismissKey, humanAccess } = suggestEl.dataset;
const commitCookieName = `suggest_gitlab_ci_yml_commit_${dismissKey}`;
const commitTrackLabel = 'suggest_gitlab_ci_yml_commit_changes';
const commitTrackValue = '20';
commitButton.addEventListener('click', () => {
setCookie(commitCookieName, true);
Tracking.event(undefined, 'click_button', {
label: commitTrackLabel,
property: humanAccess,
value: commitTrackValue,
});
});
}
}
......
<script>
import { GlSingleStat } from '@gitlab/ui/dist/charts';
import { roundOffFloat } from '~/lib/utils/common_utils';
import { SUPPORTED_FORMATS, getFormatter } from '~/lib/utils/unit_format';
import { graphDataValidatorForValues } from '../../utils';
const defaultPrecision = 2;
export default {
components: {
GlSingleStat,
......@@ -25,15 +27,19 @@ export default {
/**
* This method formats the query result from a promQL expression
* allowing a user to format the data in percentile values
* by using the `max_value` inner property from the graphData prop
* by using the `maxValue` inner property from the graphData prop
* @returns {(String)}
*/
statValue() {
const chartValue = this.graphData?.max_value
? (this.queryResult / Number(this.graphData.max_value)) * 100
: this.queryResult;
let formatter;
if (this.graphData?.maxValue) {
formatter = getFormatter(SUPPORTED_FORMATS.percent);
return formatter(this.queryResult / Number(this.graphData.maxValue), defaultPrecision);
}
return `${roundOffFloat(chartValue, 1)}${this.queryInfo.unit}`;
formatter = getFormatter(SUPPORTED_FORMATS.number);
return `${formatter(this.queryResult, defaultPrecision)}${this.queryInfo.unit}`;
},
graphTitle() {
return this.queryInfo.label;
......
......@@ -13,7 +13,6 @@ import {
lineWidths,
symbolSizes,
dateFormats,
chartColorValues,
} from '../../constants';
import { getYAxisOptions, getChartGrid, getTooltipFormatter } from './options';
import { makeDataSeries } from '~/helpers/monitor_helper';
......@@ -124,7 +123,7 @@ export default {
// Transforms & supplements query data to render appropriate labels & styles
// Input: [{ queryAttributes1 }, { queryAttributes2 }]
// Output: [{ seriesAttributes1 }, { seriesAttributes2 }]
return this.graphData.metrics.reduce((acc, query, i) => {
return this.graphData.metrics.reduce((acc, query) => {
const { appearance } = query;
const lineType =
appearance && appearance.line && appearance.line.type
......@@ -145,7 +144,6 @@ export default {
lineStyle: {
type: lineType,
width: lineWidth,
color: chartColorValues[i % chartColorValues.length],
},
showSymbol: false,
areaStyle: this.graphData.type === 'area-chart' ? areaStyle : undefined,
......
......@@ -67,13 +67,6 @@ export const colorValues = {
anomalyAreaColor: '#1f78d1',
};
export const chartColorValues = [
'#1f78d1', // $blue-500 (see variables.scss)
'#1aaa55', // $green-500
'#fc9403', // $orange-500
'#6d49cb', // $purple
];
export const lineTypes = {
default: 'solid',
};
......
......@@ -109,6 +109,7 @@ const mapPanelToViewModel = ({
y_label,
y_axis = {},
metrics = [],
max_value,
}) => {
// Both `x_axis.name` and `x_label` are supported for now
// https://gitlab.com/gitlab-org/gitlab/issues/210521
......@@ -125,6 +126,7 @@ const mapPanelToViewModel = ({
y_label: yAxis.name, // Changing y_label to yLabel is pending https://gitlab.com/gitlab-org/gitlab/issues/207198
yAxis,
xAxis,
maxValue: max_value,
metrics: mapToMetricsViewModel(metrics, yAxis.name),
};
};
......
......@@ -602,9 +602,9 @@ module ProjectsHelper
registryAvailable: Gitlab.config.registry.enabled,
registryHelpPath: help_page_path('user/packages/container_registry/index'),
lfsAvailable: Gitlab.config.lfs.enabled,
lfsHelpPath: help_page_path('workflow/lfs/manage_large_binaries_with_git_lfs'),
lfsHelpPath: help_page_path('topics/git/lfs/index'),
lfsObjectsExist: project.lfs_objects.exists?,
lfsObjectsRemovalHelpPath: help_page_path('administration/lfs/manage_large_binaries_with_git_lfs', anchor: 'removing-objects-from-lfs'),
lfsObjectsRemovalHelpPath: help_page_path('topics/git/lfs/index', anchor: 'removing-objects-from-lfs'),
pagesAvailable: Gitlab.config.pages.enabled,
pagesAccessControlEnabled: Gitlab.config.pages.access_control,
pagesAccessControlForced: ::Gitlab::Pages.access_control_is_forced?,
......
......@@ -55,7 +55,7 @@
%span.light= _('Group Git LFS status:')
%strong
= group_lfs_status(@group)
= link_to icon('question-circle'), help_page_path('workflow/lfs/manage_large_binaries_with_git_lfs')
= link_to icon('question-circle'), help_page_path('topics/git/lfs/index')
= render_if_exists 'namespaces/shared_runner_status', namespace: @group
......
......@@ -89,7 +89,7 @@
%span.light Git LFS status:
%strong
= project_lfs_status(@project)
= link_to icon('question-circle'), help_page_path('workflow/lfs/manage_large_binaries_with_git_lfs')
= link_to icon('question-circle'), help_page_path('topics/git/lfs/index')
- else
%li
%span.light repository:
......
......@@ -7,7 +7,7 @@
= f.label :lfs_enabled, class: 'form-check-label' do
%strong
Allow projects within this group to use Git LFS
= link_to icon('question-circle'), help_page_path('workflow/lfs/manage_large_binaries_with_git_lfs')
= link_to icon('question-circle'), help_page_path('topics/git/lfs/index')
%br/
%span This setting can be overridden in each project.
.form-group.row
......
- docs_link_url = help_page_path('workflow/lfs/manage_large_binaries_with_git_lfs')
- docs_link_url = help_page_path('topics/git/lfs/index')
- docs_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: docs_link_url }
%h5= _('Large File Storage')
......
---
title: Fix wrong colors displayed in charts
merge_request: 28095
author:
type: fixed
---
title: Fix single stat panel percentile format support
merge_request: 28365
author:
type: fixed
......@@ -43,7 +43,13 @@ The process will execute the following access checks:
- Ensure the user is still present in LDAP.
- If the LDAP server is Active Directory, ensure the user is active (not
blocked/disabled state). This will only be checked if
`active_directory: true` is set in the LDAP configuration. [^1]
`active_directory: true` is set in the LDAP configuration.
NOTE: **Note:**
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 <https://ctogonewild.com/2009/09/03/bitmask-searches-in-ldap/>
for more information.
The user will be set to `ldap_blocked` state in GitLab if the above conditions
fail. This means the user will not be able to login or push/pull code.
......@@ -93,7 +99,7 @@ following.
EOS
```
1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
1. [Apply your changes to GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
**Source configuration**
......@@ -108,7 +114,7 @@ following.
group_base: ou=groups,dc=example,dc=com
```
1. [Restart GitLab][restart] for the changes to take effect.
1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
To take advantage of group sync, group owners or maintainers will need to [create one
or more LDAP group links](#adding-group-links).
......@@ -183,7 +189,7 @@ group, as opposed to the full DN.
EOS
```
1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
1. [Apply your changes to GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
**Source configuration**
......@@ -199,7 +205,7 @@ group, as opposed to the full DN.
admin_group: my_admin_group
```
1. [Restart GitLab][restart] for the changes to take effect.
1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
## Global group memberships lock
......@@ -318,7 +324,7 @@ task.
EOS
```
1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
1. [Apply your changes to GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
**Source configuration**
......@@ -333,7 +339,7 @@ task.
external_groups: ['interns', 'contractors']
```
1. [Restart GitLab][restart] for the changes to take effect.
1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
## Group sync technical details
......
......@@ -84,7 +84,7 @@ following is most likely true:
- The `bind_dn` user doesn't have enough permissions to traverse the user tree.
- The user(s) don't fall under the [configured `base`](ldap.md#configuration).
- The [configured `user_filter`][user-filter] blocks access to the user(s).
- The [configured `user_filter`](ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server) blocks access to the user(s).
In this case, you con confirm which of the above is true using
[ldapsearch](#ldapsearch) with the existing LDAP configuration in your
......@@ -97,7 +97,7 @@ here are some questions to ask yourself:
- Does the user fall under the [configured `base`](ldap.md#configuration) in
LDAP? The user must fall under this `base` to login.
- Does the user pass through the [configured `user_filter`][user-filter]?
- Does the user pass through the [configured `user_filter`](ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server)?
If one is not configured, this question can be ignored. If it is, then the
user must also pass through this filter to be allowed to login.
- Refer to our docs on [debugging the `user_filter`](#debug-ldap-user-filter).
......@@ -132,7 +132,7 @@ are true for the user in question:
#### Email has already been taken
A user tries to login with the correct LDAP credentials, is denied access,
and the [production.log][production-log] shows an error that looks like this:
and the [production.log](../logs.md#productionlog) shows an error that looks like this:
```plaintext
(LDAP) Error saving user <USER DN> (email@example.com): ["Email has already been taken"]
......@@ -168,7 +168,7 @@ profile](../../user/profile/index.md#user-profile) or an admin can do it.
#### Debug LDAP user filter
[`ldapsearch`](#ldapsearch) allows you to test your configured
[user filter][user-filter]
[user filter](ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server)
to confirm that it returns the users you expect it to return.
```shell
......@@ -184,7 +184,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$ba
#### Sync all users **(STARTER ONLY)**
The output from a manual [user sync][user-sync] can show you what happens when
The output from a manual [user sync](ldap-ee.md#user-sync) can show you what happens when
GitLab tries to sync its users against LDAP. Enter the [rails console](#rails-console)
and then run:
......@@ -297,9 +297,9 @@ 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][group-sync] is required for group sync to work properly.
[This configuration](ldap-ee.md#group-sync) is required for group sync to work properly.
- Ensure the correct [LDAP group link is added to the GitLab
group][group-links].
group](ldap-ee.md#adding-group-links).
- Check that the user has an LDAP identity:
1. Sign in to GitLab as an administrator user.
1. Navigate to **Admin area -> Users**.
......@@ -312,7 +312,7 @@ things to check to debug the situation.
interval](ldap-ee.md#adjusting-ldap-group-sync-schedule) for the group to
sync. To speed up the process, either go to the GitLab group **Settings ->
Members** and press **Sync now** (sync one group) or [run the group sync Rake
task][group-sync-rake] (sync all groups).
task](../raketasks/ldap.md#run-a-group-sync) (sync all groups).
If all of the above looks good, jump in to a little more advanced debugging in
the rails console.
......@@ -352,9 +352,9 @@ GitLab syncs the `admin_group`.
NOTE: **NOTE:**
To sync all groups manually when debugging is unnecessary, [use the Rake
task][group-sync-rake] instead.
task](../raketasks/ldap.md#run-a-group-sync) instead.
The output from a manual [group sync][group-sync] can show you what happens
The output from a manual [group sync](ldap-ee.md#group-sync) can show you what happens
when GitLab syncs its LDAP group memberships against LDAP.
```ruby
......@@ -449,7 +449,7 @@ this line will indicate the sync is finished:
Finished syncing admin users for 'ldapmain' provider
```
If [admin sync][admin-sync] is not configured, you'll see a message
If [admin sync](ldap-ee.md#administrator-sync) is not configured, you'll see a message
stating as such:
```shell
......@@ -541,7 +541,7 @@ for each of these users.
### LDAP check
The [Rake task to check LDAP][ldap-check] is a valuable tool
The [Rake task to check LDAP](../raketasks/ldap.md#check) is a valuable tool
to help determine whether GitLab can successfully establish a connection to
LDAP and can get so far as to even read users.
......@@ -561,11 +561,11 @@ users, [see what to do when no users are found](#no-users-are-found).
### GitLab logs
If a user account is blocked or unblocked due to the LDAP configuration, a
message will be [logged to `application.log`][application-log].
message will be [logged to `application.log`](../logs.md#applicationlog).
If there is an unexpected error during an LDAP lookup (configuration error,
timeout), the login is rejected and a message will be [logged to
`production.log`][production-log].
`production.log`](../logs.md#productionlog).
### ldapsearch
......@@ -649,24 +649,3 @@ console](#rails-console) and run:
```ruby
Rails.logger.level = Logger::DEBUG
```
<!-- LINK REFERENCES -->
[tail-logs]: https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server
[production-log]: ../logs.md#productionlog
[application-log]: ../logs.md#applicationlog
[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
[restart]: ../restart_gitlab.md#installations-from-source
[ldap-check]: ../raketasks/ldap.md#check
[group-sync-rake]: ../raketasks/ldap.md#run-a-group-sync
[user-filter]: ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server
[user-sync]: ldap-ee.md#user-sync
[group-sync]: ldap-ee.md#group-sync
[admin-sync]: ldap-ee.md#administrator-sync
[config]: ldap.md#configuration
[group-links]: ldap-ee.md#adding-group-links
[^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 <https://ctogonewild.com/2009/09/03/bitmask-searches-in-ldap/>
for more information.
......@@ -236,7 +236,7 @@ push origin
[deprecate-annex-issue]: https://gitlab.com/gitlab-org/gitlab/issues/1648
[git-annex]: https://git-annex.branchable.com/ "git-annex website"
[gitlab shell]: https://gitlab.com/gitlab-org/gitlab-shell "GitLab Shell repository"
[guide]: lfs/migrate_from_git_annex_to_git_lfs.html
[guide]: ../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md
[issue]: https://git-annex.branchable.com/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/ "git-annex issue"
[reconfigure GitLab]: restart_gitlab.md#omnibus-gitlab-reconfigure
[restart GitLab]: restart_gitlab.md#installations-from-source
......@@ -19,6 +19,18 @@ will fail.
- **Max limit:** 5.000 comments
## Size of comments and descriptions of issues, merge requests, and epics
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/61974) in GitLab 12.2.
There is a limit to the size of comments and descriptions of issues, merge requests, and epics.
Attempting to add a body of text larger than the limit will result in an error, and the
item will not be created.
It's possible that this limit will be changed to a lower number in the future.
- **Max size:** ~1 million characters / ~1 MB
## Number of pipelines per Git push
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/51401) in GitLab 11.10.
......
......@@ -198,6 +198,85 @@ JUnit test report artifact (`junit.xml.gz`) migration
[is not supported](https://gitlab.com/gitlab-org/gitlab/issues/27698)
by the `gitlab:artifacts:migrate` script.
### OpenStack compatible connection settings
The connection settings match those provided by [Fog](https://github.com/fog), and are as follows:
| Setting | Description | Default |
|---------|-------------|---------|
| `provider` | Always `OpenStack` for compatible hosts | OpenStack |
| `openstack_username` | OpenStack username | |
| `openstack_api_key` | OpenStack API key | |
| `openstack_temp_url_key` | OpenStack key for generating temporary urls | |
| `openstack_auth_url` | OpenStack authentication endpont | |
| `openstack_region` | OpenStack region | |
| `openstack_tenant_id` | OpenStack tenant ID |
**In Omnibus installations:**
_The uploads are stored by default in
`/var/opt/gitlab/gitlab-rails/shared/artifacts`._
1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with
the values you want:
```ruby
gitlab_rails['artifacts_enabled'] = true
gitlab_rails['artifacts_object_store_enabled'] = true
gitlab_rails['artifacts_object_store_remote_directory'] = "artifacts"
gitlab_rails['artifacts_object_store_connection'] = {
'provider' => 'OpenStack',
'openstack_username' => 'OS_USERNAME',
'openstack_api_key' => 'OS_PASSWORD',
'openstack_temp_url_key' => 'OS_TEMP_URL_KEY',
'openstack_auth_url' => 'https://auth.cloud.ovh.net',
'openstack_region' => 'GRA',
'openstack_tenant_id' => 'OS_TENANT_ID',
}
```
1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Migrate any existing local artifacts to the object storage:
```shell
gitlab-rake gitlab:artifacts:migrate
```
---
**In installations from source:**
_The uploads are stored by default in
`/home/git/gitlab/shared/artifacts`._
1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
lines:
```yaml
uploads:
object_store:
enabled: true
direct_upload: false
background_upload: true
proxy_download: false
remote_directory: "artifacts"
connection:
provider: OpenStack
openstack_username: OS_USERNAME
openstack_api_key: OS_PASSWORD
openstack_temp_url_key: OS_TEMP_URL_KEY
openstack_auth_url: 'https://auth.cloud.ovh.net'
openstack_region: GRA
openstack_tenant_id: OS_TENANT_ID
```
1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
1. Migrate any existing local artifacts to the object storage:
```shell
sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
```
### Migrating from object storage to local storage
**In Omnibus installations:**
......
......@@ -4,7 +4,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/lfs/lfs_administration.h
# GitLab Git LFS Administration
Documentation on how to use Git LFS are under [Managing large binary files with Git LFS doc](manage_large_binaries_with_git_lfs.md).
Documentation on how to use Git LFS are under [Managing large binary files with Git LFS doc](../../topics/git/lfs/index.md).
## Requirements
......
# Migration guide from Git Annex to Git LFS
>**Note:**
Git Annex support [has been removed][issue-remove-annex] in GitLab Enterprise
Edition 9.0 (2017/03/22).
Both [Git Annex][] and [Git LFS][] are tools to manage large files in Git.
## History
Git Annex [was introduced in GitLab Enterprise Edition 7.8][post-3], at a time
where Git LFS didn't yet exist. A few months later, GitLab brought support for
Git LFS in [GitLab 8.2][post-2] and is available for both Community and
Enterprise editions.
## Differences between Git Annex and Git LFS
Some items below are general differences between the two protocols and some are
ones that GitLab developed.
- Git Annex works only through SSH, whereas Git LFS works both with SSH and HTTPS
(SSH support was added in GitLab 8.12).
- Annex files are stored in a sub-directory of the normal repositories, whereas
LFS files are stored outside of the repositories in a place you can define.
- Git Annex requires a more complex setup, but has much more options than Git
LFS. You can compare the commands each one offers by running `man git-annex`
and `man git-lfs`.
- Annex files cannot be browsed directly in GitLab's interface, whereas LFS
files can.
## Migration steps
>**Note:**
Since Git Annex files are stored in a sub-directory of the normal repositories
(`.git/annex/objects`) and LFS files are stored outside of the repositories,
they are not compatible as they are using a different scheme. Therefore, the
migration has to be done manually per repository.
There are basically two steps you need to take in order to migrate from Git
Annex to Git LFS.
### TL; DR
If you know what you are doing and want to skip the reading, this is what you
need to do (we assume you have [git-annex enabled](../git_annex.md#using-gitlab-git-annex) in your
repository and that you have made backups in case something goes wrong).
Fire up a terminal, navigate to your Git repository and:
1. Disable `git-annex`:
```shell
git annex sync --content
git annex direct
git annex uninit
git annex indirect
```
1. Enable `git-lfs`:
```shell
git lfs install
git lfs track <files>
git add .
git commit -m "commit message"
git push
```
### Disabling Git Annex in your repo
Before changing anything, make sure you have a backup of your repository first.
There are a couple of ways to do that, but you can simply clone it to another
local path and maybe push it to GitLab if you want a remote backup as well.
Here you'll find a guide on
[how to back up a **git-annex** repository to an external hard drive][bkp-ext-drive].
Since Annex files are stored as objects with symlinks and cannot be directly
modified, we need to first remove those symlinks.
NOTE: **Note:**
Make sure the you read about the [`direct` mode][annex-direct] as it contains
useful information that may fit in your use case. Note that `annex direct` is
deprecated in Git Annex version 6, so you may need to upgrade your repository
if the server also has Git Annex 6 installed. Read more in the
[Git Annex troubleshooting tips](../git_annex.md#troubleshooting-tips) section.
1. Backup your repository
```shell
cd repository
git annex sync --content
cd ..
git clone repository repository-backup
cd repository-backup
git annex get
cd ..
```
1. Use `annex direct`:
```shell
cd repository
git annex direct
```
The output should be similar to this:
```shell
commit
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
ok
direct debian.iso ok
direct ok
```
1. Disable Git Annex with [`annex uninit`][uninit]:
```shell
git annex uninit
```
The output should be similar to this:
```shell
unannex debian.iso ok
Deleted branch git-annex (was 2534d2c).
```
This will `unannex` every file in the repository, leaving the original files.
1. Switch back to `indirect` mode:
```shell
git annex indirect
```
The output should be similar to this:
```shell
(merging origin/git-annex into git-annex...)
(recording state in git...)
commit (recording state in git...)
ok
(recording state in git...)
[master fac3194] commit before switching to indirect mode
1 file changed, 1 deletion(-)
delete mode 120000 alpine-virt-3.4.4-x86_64.iso
ok
indirect ok
ok
```
---
redirect_to: '../../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md'
---
At this point, you have two options. Either add, commit and push the files
directly back to GitLab or switch to Git LFS. We will tackle the LFS switch in
the next section.
### Enabling Git LFS in your repo
Git LFS is enabled by default on all GitLab products (GitLab CE, GitLab EE,
GitLab.com), therefore, you don't need to do anything server-side.
1. First, make sure you have `git-lfs` installed locally:
```shell
git lfs help
```
If the terminal doesn't prompt you with a full response on `git-lfs` commands,
[install the Git LFS client][install-lfs] first.
1. Inside the repo, run the following command to initiate LFS:
```shell
git lfs install
```
1. Enable `git-lfs` for the group of files you want to track. You
can track specific files, all files containing the same extension, or an
entire directory:
```shell
git lfs track images/01.png # per file
git lfs track **/*.png # per extension
git lfs track images/ # per directory
```
Once you do that, run `git status` and you'll see `.gitattributes` added
to your repo. It collects all file patterns that you chose to track via
`git-lfs`.
1. Add the files, commit and push them to GitLab:
```shell
git add .
git commit -m "commit message"
git push
```
If your remote is set up with HTTP, you will be asked to enter your login
credentials. If you have [2FA enabled](../../user/profile/account/two_factor_authentication.md), make sure to use a
[personal access token](../../user/profile/account/two_factor_authentication.md#personal-access-tokens)
instead of your password.
## Removing the Git Annex branches
After the migration finishes successfully, you can remove all `git-annex`
related branches from your repository.
On GitLab, navigate to your project's **Repository ➔ Branches** and delete all
branches created by Git Annex: `git-annex`, and all under `synced/`.
![repository branches](img/git-annex-branches.png)
You can also do this on the command line with:
```shell
git branch -d synced/master
git branch -d synced/git-annex
git push origin :synced/master
git push origin :synced/git-annex
git push origin :git-annex
git remote prune origin
```
If there are still some Annex objects inside your repository (`.git/annex/`)
or references inside `.git/config`, run `annex uninit` again:
```shell
git annex uninit
```
## Further Reading
- (Blog Post) [Getting Started with Git FLS][post-1]
- (Blog Post) [Announcing LFS Support in GitLab][post-2]
- (Blog Post) [GitLab Annex Solves the Problem of Versioning Large Binaries with Git][post-3]
- (GitLab Docs) [Git Annex](../git_annex.md)
- (GitLab Docs) [Git LFS](manage_large_binaries_with_git_lfs.md)
[annex-direct]: https://git-annex.branchable.com/direct_mode/
[bkp-ext-drive]: https://www.thomas-krenn.com/en/wiki/Git-annex_Repository_on_an_External_Hard_Drive
[Git Annex]: http://git-annex.branchable.com/
[Git LFS]: https://git-lfs.github.com/
[install-lfs]: https://git-lfs.github.com/
[issue-remove-annex]: https://gitlab.com/gitlab-org/gitlab/issues/1648
[lfs-track]: https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/#tracking-files-with-lfs
[post-1]: https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/
[post-2]: https://about.gitlab.com/blog/2015/11/23/announcing-git-lfs-support-in-gitlab/
[post-3]: https://about.gitlab.com/blog/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/
[uninit]: https://git-annex.branchable.com/git-annex-uninit/
This document was moved to [another location](../../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md).
......@@ -4,9 +4,9 @@
> - [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab Community Edition 10.4.
NOTE: **Note:** This document describes a drop-in replacement for the
`authorized_keys` file for normal (non-deploy key) users. Consider
using [SSH certificates](ssh_certificates.md), they are even faster,
but are not a drop-in replacement.
`authorized_keys` file. For normal (non-deploy key) users, consider using
[SSH certificates](ssh_certificates.md). They are even faster, but are not a
drop-in replacement.
Regular SSH operations become slow as the number of users grows because OpenSSH
searches for a key to authorize a user via a linear search. In the worst case,
......
......@@ -235,7 +235,7 @@ CI Artifacts are S3 compatible since **9.4** (GitLab Premium), and available in
##### LFS Objects
[LFS Objects in GitLab](lfs/manage_large_binaries_with_git_lfs.md) implement a similar
[LFS Objects in GitLab](../topics/git/lfs/index.md) implement a similar
storage pattern using 2 chars, 2 level folders, following Git's own implementation:
```ruby
......
This diff is collapsed.
......@@ -5,7 +5,7 @@
In April 2019, Francisco Javier López hosted a [Deep Dive] on GitLab's [Git LFS] implementation to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides on [Google Slides] and in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.10, and while specific details may have changed since then, it should still serve as a good introduction.
[Deep Dive]: https://gitlab.com/gitlab-org/create-stage/issues/1
[Git LFS]: ../administration/lfs/manage_large_binaries_with_git_lfs.md
[Git LFS]: ../topics/git/lfs/index.md
[recording on YouTube]: https://www.youtube.com/watch?v=Yyxwcksr0Qc
[Google Slides]: https://docs.google.com/presentation/d/1E-aw6-z0rYd0346YhIWE7E9A65zISL9iIMAOq2zaw9E/edit
[PDF]: https://gitlab.com/gitlab-org/create-stage/uploads/07a89257a140db067bdfb484aecd35e1/Git_LFS_Deep_Dive__Create_.pdf
......@@ -189,29 +189,47 @@ We also need to create two private route tables so that instances in each privat
1. Associate `gitlab-private-10.0.1.0` with `gitlab-public-a`.
1. Associate `gitlab-private-10.0.3.0` with `gitlab-public-b`.
---
Now that we're done with the network, let's create a security group.
## Load Balancer
## Creating a security group
On the EC2 dashboard, look for Load Balancer in the left navigation bar:
The security group is basically the firewall:
1. Click the **Create Load Balancer** button.
1. Choose the **Classic Load Balancer**.
1. Give it a name (we'll use `gitlab-loadbalancer`) and for the **Create LB Inside** option, select `gitlab-vpc` from the dropdown menu.
1. In the **Listeners** section, set HTTP port 80, HTTPS port 443, and TCP port 22 for both load balancer and instance protocols and ports.
1. In the **Select Subnets** section, select both public subnets from the list.
1. Click **Assign Security Groups** and select **Create a new security group**, give it a name
(we'll use `gitlab-loadbalancer-sec-group`) and description, and allow both HTTP and HTTPS traffic
from anywhere (`0.0.0.0/0, ::/0`).
1. Click **Configure Security Settings** and select an SSL/TLS certificate from ACM or upload a certificate to IAM.
1. Click **Configure Health Check** and set up a health check for your EC2 instances.
1. For **Ping Protocol**, select HTTP.
1. For **Ping Port**, enter 80.
1. For **Ping Path**, enter `/explore`. (We use `/explore` as it's a public endpoint that does
not require authorization.)
1. Keep the default **Advanced Details** or adjust them according to your needs.
1. Click **Add EC2 Instances** but, as we don't have any instances to add yet, come back
to your load balancer after creating your GitLab instances and add them.
1. Click **Add Tags** and add any tags you need.
1. Click **Review and Create**, review all your settings, and click **Create** if you're happy.
1. Select **Security Groups** from the left menu.
1. Click **Create Security Group** and fill in the details. Give it a name,
add a description, and choose the VPC we created previously
1. Select the security group from the list and at the bottom select the
Inbound Rules tab. You will need to open the SSH, HTTP, and HTTPS ports. Set
the source to `0.0.0.0/0`.
After the Load Balancer is up and running, you can revisit your Security
Groups to refine the access only through the ELB and any other requirements
you might have.
![Create security group](img/create_security_group.png)
### Configure DNS for Load Balancer
TIP: **Tip:**
Based on best practices, you should allow SSH traffic from only a known
host or CIDR block. In that case, change the SSH source to be custom and give
it the IP you want to SSH from.
On the Route 53 dashboard, click **Hosted zones** in the left navigation bar:
1. When done, click **Save**.
1. Select an existing hosted zone or, if you do not already have one for your domain, click **Create Hosted Zone**, enter your domain name, and click **Create**.
1. Click **Create Record Set** and provide the following values:
1. **Name:** Use the domain name (the default value) or enter a subdomain.
1. **Type:** Select **A - IPv4 address**.
1. **Alias Target:** Find the **ELB Classic Load Balancers** section and select the classic load balancer we created earlier.
1. **Routing Policy:** We'll use **Simple** but you can choose a different policy based on your use case.
1. **Evaluate Target Health:** We'll set this to **No** but you can choose to have the load balancer route traffic based on target health.
1. Click **Create**.
1. Update your DNS records with your domain registrar. The steps for doing this vary depending on which registrar you use and is beyond the scope of this guide.
## PostgreSQL with RDS
......@@ -265,7 +283,7 @@ Now that the database is created, let's move on to setting up Redis with ElastiC
ElastiCache is an in-memory hosted caching solution. Redis maintains its own
persistence and is used for certain types of the GitLab application.
To set up Redis:
### Redis Subnet Group
1. Navigate to the ElastiCache dashboard from your AWS console.
1. Go to **Subnet Groups** in the left menu, and create a new subnet group.
......@@ -274,6 +292,18 @@ To set up Redis:
![ElastiCache subnet](img/ec_subnet.png)
### Create a Redis Security Group
1. Navigate to the EC2 dashboard.
1. Select **Security Groups** from the left menu.
1. Click **Create security group** and fill in the details. Give it a name (we'll use `gitlab-redis-sec-group`),
add a description, and choose the VPC we created previously
1. In the **Inbound rules** section, click **Add rule** and add a **Custom TCP** rule, set port `6379`, and set the "Custom" source as the `gitlab-loadbalancer-sec-group` we created earlier.
1. When done, click **Create security group**.
### Create the Redis Cluster
1. Navigate back to the ElastiCache dashboard.
1. Select **Redis** on the left menu and click **Create** to create a new
Redis cluster. Depending on your load, you can choose whether to enable
cluster mode or not. Even without cluster mode on, you still get the
......@@ -281,8 +311,9 @@ To set up Redis:
not to enable it.
1. In the settings section:
1. Give the cluster a name (`gitlab-redis`) and a description.
1. For the version, select the latest of `3.2` series (e.g., `3.2.10`).
1. Select the node type and the number of replicas.
1. For the version, select the latest of `5.0` series (e.g., `5.0.6`).
1. Leave the port as `6379` since this is what we used in our Redis security group above.
1. Select the node type (at least `cache.t3.medium`, but adjust to your needs) and the number of replicas.
1. In the advanced settings section:
1. Select the multi-AZ auto-failover option.
1. Select the subnet group we created previously.
......@@ -292,7 +323,7 @@ To set up Redis:
![Redis availability zones](img/ec_az.png)
1. In the security settings, edit the security groups and choose the
`gitlab-security-group` we had previously created.
`gitlab-redis-sec-group` we had previously created.
1. Leave the rest of the settings to their default values or edit to your liking.
1. When done, click **Create**.
......@@ -307,48 +338,6 @@ source.
Similar to the above, jump to the `gitlab-security-group` group
and add a custom TCP rule for port `6379` accessible within itself.
## Load Balancer
On the EC2 dashboard, look for Load Balancer in the left navigation bar:
1. Click the **Create Load Balancer** button.
1. Choose the **Classic Load Balancer**.
1. Give it a name (we'll use `gitlab-loadbalancer`) and for the **Create LB Inside** option, select `gitlab-vpc` from the dropdown menu.
1. In the **Listeners** section, set HTTP port 80, HTTPS port 443, and TCP port 22 for both load balancer and instance protocols and ports.
1. In the **Select Subnets** section, select both public subnets from the list.
1. Click **Assign Security Groups** and select **Create a new security group**, give it a name
(we'll use `gitlab-loadbalancer-sec-group`) and description, and allow both HTTP and HTTPS traffic
from anywhere (`0.0.0.0/0, ::/0`).
1. Click **Configure Security Settings** and select an SSL/TLS certificate from ACM or upload a certificate to IAM.
1. Click **Configure Health Check** and set up a health check for your EC2 instances.
1. For **Ping Protocol**, select HTTP.
1. For **Ping Port**, enter 80.
1. For **Ping Path**, enter `/explore`. (We use `/explore` as it's a public endpoint that does
not require authorization.)
1. Keep the default **Advanced Details** or adjust them according to your needs.
1. Click **Add EC2 Instances** but, as we don't have any instances to add yet, come back
to your load balancer after creating your GitLab instances and add them.
1. Click **Add Tags** and add any tags you need.
1. Click **Review and Create**, review all your settings, and click **Create** if you're happy.
After the Load Balancer is up and running, you can revisit your Security
Groups to refine the access only through the ELB and any other requirements
you might have.
### Configure DNS for Load Balancer
On the Route 53 dashboard, click **Hosted zones** in the left navigation bar:
1. Select an existing hosted zone or, if you do not already have one for your domain, click **Create Hosted Zone**, enter your domain name, and click **Create**.
1. Click **Create Record Set** and provide the following values:
1. **Name:** Use the domain name (the default value) or enter a subdomain.
1. **Type:** Select **A - IPv4 address**.
1. **Alias Target:** Find the **ELB Classic Load Balancers** section and select the classic load balancer we created earlier.
1. **Routing Policy:** We'll use **Simple** but you can choose a different policy based on your use case.
1. **Evaluate Target Health:** We'll set this to **No** but you can choose to have the load balancer route traffic based on target health.
1. Click **Create**.
1. Update your DNS records with your domain registrar. The steps for doing this vary depending on which registrar you use and is beyond the scope of this guide.
## Setting up Bastion Hosts
Since our GitLab instances will be in private subnets, we need a way to connect to these instances via SSH to make configuration changes, perform upgrades, etc. One way of doing this is via a [bastion host](https://en.wikipedia.org/wiki/Bastion_host), sometimes also referred to as a jump box.
......
......@@ -134,7 +134,7 @@ Make sure you have the right version of Git installed:
# Install Git
sudo apt-get install -y git-core
# Make sure Git is version 2.24.1 or higher (minimal supported version is 2.22.0)
# Make sure Git is version 2.26.0 or higher (minimal supported version is 2.22.0)
git --version
```
......@@ -171,9 +171,9 @@ sudo make install
# Download and compile from source
cd /tmp
curl --remote-name --location --progress https://www.kernel.org/pub/software/scm/git/git-2.24.1.tar.gz
echo 'ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02 git-2.24.1.tar.gz' | shasum -a256 -c - && tar -xzf git-2.24.1.tar.gz
cd git-2.24.1/
curl --remote-name --location --progress https://www.kernel.org/pub/software/scm/git/git-2.26.0.tar.gz
echo 'aa168c2318e7187cd295a645f7370cc6d71a324aafc932f80f00c780b6a26bed git-2.26.0.tar.gz' | shasum -a256 -c - && tar -xzf git-2.26.0.tar.gz
cd git-2.26.0/
./configure --with-libpcre
make prefix=/usr/local all
......
......@@ -84,9 +84,9 @@ Git-related queries from GitLab.
The following relate to Git Large File Storage:
- [Getting Started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
- [Migrate an existing Git repo with Git LFS](migrate_to_git_lfs/index.md)
- [Removing objects from LFS](../../administration/lfs/manage_large_binaries_with_git_lfs.md#removing-objects-from-lfs)
- [GitLab Git LFS user documentation](../../administration/lfs/manage_large_binaries_with_git_lfs.md)
- [Migrate an existing Git repo with Git LFS](lfs/migrate_to_git_lfs.md)
- [Removing objects from LFS](lfs/index.md#removing-objects-from-lfs)
- [GitLab Git LFS user documentation](lfs/index.md)
- [GitLab Git LFS admin documentation](../../administration/lfs/lfs_administration.md)
- [git-annex to Git-LFS migration guide](../../administration/lfs/migrate_from_git_annex_to_git_lfs.md)
- [git-annex to Git-LFS migration guide](lfs/migrate_from_git_annex_to_git_lfs.md)
- [Towards a production quality open source Git LFS server](https://about.gitlab.com/blog/2015/08/13/towards-a-production-quality-open-source-git-lfs-server/)
This diff is collapsed.
# Migration guide from Git Annex to Git LFS
>**Note:**
Git Annex support [has been removed][issue-remove-annex] in GitLab Enterprise
Edition 9.0 (2017/03/22).
Both [Git Annex][] and [Git LFS][] are tools to manage large files in Git.
## History
Git Annex [was introduced in GitLab Enterprise Edition 7.8][post-3], at a time
where Git LFS didn't yet exist. A few months later, GitLab brought support for
Git LFS in [GitLab 8.2][post-2] and is available for both Community and
Enterprise editions.
## Differences between Git Annex and Git LFS
Some items below are general differences between the two protocols and some are
ones that GitLab developed.
- Git Annex works only through SSH, whereas Git LFS works both with SSH and HTTPS
(SSH support was added in GitLab 8.12).
- Annex files are stored in a sub-directory of the normal repositories, whereas
LFS files are stored outside of the repositories in a place you can define.
- Git Annex requires a more complex setup, but has much more options than Git
LFS. You can compare the commands each one offers by running `man git-annex`
and `man git-lfs`.
- Annex files cannot be browsed directly in GitLab's interface, whereas LFS
files can.
## Migration steps
>**Note:**
Since Git Annex files are stored in a sub-directory of the normal repositories
(`.git/annex/objects`) and LFS files are stored outside of the repositories,
they are not compatible as they are using a different scheme. Therefore, the
migration has to be done manually per repository.
There are basically two steps you need to take in order to migrate from Git
Annex to Git LFS.
### TL; DR
If you know what you are doing and want to skip the reading, this is what you
need to do (we assume you have [git-annex enabled](../../../administration/git_annex.md#using-gitlab-git-annex) in your
repository and that you have made backups in case something goes wrong).
Fire up a terminal, navigate to your Git repository and:
1. Disable `git-annex`:
```shell
git annex sync --content
git annex direct
git annex uninit
git annex indirect
```
1. Enable `git-lfs`:
```shell
git lfs install
git lfs track <files>
git add .
git commit -m "commit message"
git push
```
### Disabling Git Annex in your repo
Before changing anything, make sure you have a backup of your repository first.
There are a couple of ways to do that, but you can simply clone it to another
local path and maybe push it to GitLab if you want a remote backup as well.
Here you'll find a guide on
[how to back up a **git-annex** repository to an external hard drive][bkp-ext-drive].
Since Annex files are stored as objects with symlinks and cannot be directly
modified, we need to first remove those symlinks.
NOTE: **Note:**
Make sure the you read about the [`direct` mode][annex-direct] as it contains
useful information that may fit in your use case. Note that `annex direct` is
deprecated in Git Annex version 6, so you may need to upgrade your repository
if the server also has Git Annex 6 installed. Read more in the
[Git Annex troubleshooting tips](../../../administration/git_annex.md#troubleshooting-tips) section.
1. Backup your repository
```shell
cd repository
git annex sync --content
cd ..
git clone repository repository-backup
cd repository-backup
git annex get
cd ..
```
1. Use `annex direct`:
```shell
cd repository
git annex direct
```
The output should be similar to this:
```shell
commit
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
ok
direct debian.iso ok
direct ok
```
1. Disable Git Annex with [`annex uninit`][uninit]:
```shell
git annex uninit
```
The output should be similar to this:
```shell
unannex debian.iso ok
Deleted branch git-annex (was 2534d2c).
```
This will `unannex` every file in the repository, leaving the original files.
1. Switch back to `indirect` mode:
```shell
git annex indirect
```
The output should be similar to this:
```shell
(merging origin/git-annex into git-annex...)
(recording state in git...)
commit (recording state in git...)
ok
(recording state in git...)
[master fac3194] commit before switching to indirect mode
1 file changed, 1 deletion(-)
delete mode 120000 alpine-virt-3.4.4-x86_64.iso
ok
indirect ok
ok
```
---
At this point, you have two options. Either add, commit and push the files
directly back to GitLab or switch to Git LFS. We will tackle the LFS switch in
the next section.
### Enabling Git LFS in your repo
Git LFS is enabled by default on all GitLab products (GitLab CE, GitLab EE,
GitLab.com), therefore, you don't need to do anything server-side.
1. First, make sure you have `git-lfs` installed locally:
```shell
git lfs help
```
If the terminal doesn't prompt you with a full response on `git-lfs` commands,
[install the Git LFS client][install-lfs] first.
1. Inside the repo, run the following command to initiate LFS:
```shell
git lfs install
```
1. Enable `git-lfs` for the group of files you want to track. You
can track specific files, all files containing the same extension, or an
entire directory:
```shell
git lfs track images/01.png # per file
git lfs track **/*.png # per extension
git lfs track images/ # per directory
```
Once you do that, run `git status` and you'll see `.gitattributes` added
to your repo. It collects all file patterns that you chose to track via
`git-lfs`.
1. Add the files, commit and push them to GitLab:
```shell
git add .
git commit -m "commit message"
git push
```
If your remote is set up with HTTP, you will be asked to enter your login
credentials. If you have [2FA enabled](../../../user/profile/account/two_factor_authentication.md), make sure to use a
[personal access token](../../../user/profile/account/two_factor_authentication.md#personal-access-tokens)
instead of your password.
## Removing the Git Annex branches
After the migration finishes successfully, you can remove all `git-annex`
related branches from your repository.
On GitLab, navigate to your project's **Repository ➔ Branches** and delete all
branches created by Git Annex: `git-annex`, and all under `synced/`.
![repository branches](img/git-annex-branches.png)
You can also do this on the command line with:
```shell
git branch -d synced/master
git branch -d synced/git-annex
git push origin :synced/master
git push origin :synced/git-annex
git push origin :git-annex
git remote prune origin
```
If there are still some Annex objects inside your repository (`.git/annex/`)
or references inside `.git/config`, run `annex uninit` again:
```shell
git annex uninit
```
## Further Reading
- (Blog Post) [Getting Started with Git FLS][post-1]
- (Blog Post) [Announcing LFS Support in GitLab][post-2]
- (Blog Post) [GitLab Annex Solves the Problem of Versioning Large Binaries with Git][post-3]
- (GitLab Docs) [Git Annex](../../../administration/git_annex.md)
- (GitLab Docs) [Git LFS](index.md)
[annex-direct]: https://git-annex.branchable.com/direct_mode/
[bkp-ext-drive]: https://www.thomas-krenn.com/en/wiki/Git-annex_Repository_on_an_External_Hard_Drive
[Git Annex]: http://git-annex.branchable.com/
[Git LFS]: https://git-lfs.github.com/
[install-lfs]: https://git-lfs.github.com/
[issue-remove-annex]: https://gitlab.com/gitlab-org/gitlab/issues/1648
[post-1]: https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/
[post-2]: https://about.gitlab.com/blog/2015/11/23/announcing-git-lfs-support-in-gitlab/
[post-3]: https://about.gitlab.com/blog/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/
[uninit]: https://git-annex.branchable.com/git-annex-uninit/
---
type: tutorial, concepts
description: "How to migrate an existing Git repository to Git LFS with BFG."
last_updated: 2019-07-11
---
# Migrate a Git repo into Git LFS with BFG
Using Git LFS can help you to reduce the size of your Git
repository and improve its performance.
However, simply adding the
large files that are already in your repository to Git LFS,
will not actually reduce the size of your repository because
the files are still referenced by previous commits.
Through the method described on this document, first migrate
to Git LFS with a tool such as the open source community-maintained [BFG](https://rtyley.github.io/bfg-repo-cleaner/)
through a mirror repo, then clean up the repository's history,
and lastly create LFS tracking rules to prevent new binary files
from being added.
This tutorial was inspired by the guide
[Use BFG to migrate a repo to Git LFS](https://confluence.atlassian.com/bitbucket/use-bfg-to-migrate-a-repo-to-git-lfs-834233484.html).
For more information on Git LFS, see the [references](#references)
below.
CAUTION: **Warning:**
The method described on this guide rewrites Git history. Make
sure to back up your repo before beginning and use it at your
own risk.
## Requirements
Before beginning, make sure:
- You have enough LFS storage for the files you want to convert.
Storage is required for the entire history of all files.
- All the team members you share the repository with have pushed all changes.
Branches based on the repository before applying this method cannot be merged.
Branches based on the repo before applying this method cannot be merged.
To follow this tutorial, you'll need:
- Maintainer permissions to the existing Git repository
you'd like to migrate to LFS with access through the command line.
- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
and [Java Runtime Environment](https://www.java.com/en/download/manual.jsp)
(Java 7 or above) installed locally.
- BFG installed locally:
```shell
brew install bfg
```
- Git LFS installed locally:
```shell
brew install git-lfs
```
NOTE: **Note:**
This guide was tested on macOS Mojave.
## Steps
Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-repo-migration.git`.
1. Back up your repository:
Create a copy of your repository so that you can
recover it in case something goes wrong.
1. Clone `--mirror` the repo:
Cloning with the mirror flag will create a bare repository.
This ensures you get all the branches within the repo.
It creates a directory called `<repo-name>.git`
(in our example, `test-git-lfs-repo-migration.git`),
mirroring the upstream project:
```shell
git clone --mirror git@gitlab.com:gitlab-tests/test-git-lfs-repo-migration.git
```
1. Convert the Git history with BFG:
```shell
bfg --convert-to-git-lfs "*.{png,mp4,jpg,gif}" --no-blob-protection test-git-lfs-repo-migration.git
```
It is scanning all the history, and looking for any files with
that extension, and then converting them to an LFS pointer.
1. Clean up the repository:
```shell
# cd path/to/mirror/repo:
cd test-git-lfs-repo-migration.git
# clean up the repo:
git reflog expire --expire=now --all && git gc --prune=now --aggressive
```
You can also take a look on how to further [clean the repo](../../../user/project/repository/reducing_the_repo_size_using_git.md),
but it's not necessary for the purposes of this guide.
1. Install Git LFS in the mirror repository:
```shell
git lfs install
```
1. [Unprotect the default branch](../../../user/project/protected_branches.md),
so that we can force-push the rewritten repository:
1. Navigate to your project's **Settings > Repository** and
expand **Protected Branches**.
1. Scroll down to locate the protected branches and click
**Unprotect** the default branch.
1. Force-push to GitLab:
```shell
git push --force
```
1. Track the files you want with LFS:
```shell
# cd path/to/upstream/repo:
cd test-git-lfs-repo-migration
# You may need to reset your local copy with upstream's `master` after force-pushing from the mirror:
git reset --hard origin/master
# Track the files with LFS:
git lfs track "*.gif" "*.png" "*.jpg" "*.psd" "*.mp4" "img/"
```
Now all existing the files you converted, as well as the new
ones you add, will be properly tracked with LFS.
1. [Re-protect the default branch](../../../user/project/protected_branches.md):
1. Navigate to your project's **Settings > Repository** and
expand **Protected Branches**.
1. Select the default branch from the **Branch** dropdown menu,
and set up the
**Allowed to push** and **Allowed to merge** rules.
1. Click **Protect**.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
## References
- [Getting Started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
- [Migrate from Git Annex to Git LFS](migrate_from_git_annex_to_git_lfs.md)
- [GitLab's Git LFS user documentation](index.md)
- [GitLab's Git LFS administrator documentation](../../../administration/lfs/lfs_administration.md)
- Alternative method to [migrate an existing repo to Git LFS](https://github.com/git-lfs/git-lfs/wiki/Tutorial#migrating-existing-repository-data-to-lfs)
<!--
Test project:
https://gitlab.com/gitlab-tests/test-git-lfs-repo-migration
-->
---
type: tutorial, concepts
description: "How to migrate an existing Git repository to Git LFS with BFG."
last_updated: 2019-07-11
redirect_to: '../lfs/migrate_to_git_lfs.md'
---
# Migrate a Git repo into Git LFS with BFG
Using Git LFS can help you to reduce the size of your Git
repository and improve its performance.
However, simply adding the
large files that are already in your repository to Git LFS,
will not actually reduce the size of your repository because
the files are still referenced by previous commits.
Through the method described on this document, first migrate
to Git LFS with a tool such as the open source community-maintained [BFG](https://rtyley.github.io/bfg-repo-cleaner/)
through a mirror repo, then clean up the repository's history,
and lastly create LFS tracking rules to prevent new binary files
from being added.
This tutorial was inspired by the guide
[Use BFG to migrate a repo to Git LFS](https://confluence.atlassian.com/bitbucket/use-bfg-to-migrate-a-repo-to-git-lfs-834233484.html).
For more information on Git LFS, see the [references](#references)
below.
CAUTION: **Warning:**
The method described on this guide rewrites Git history. Make
sure to back up your repo before beginning and use it at your
own risk.
## Requirements
Before beginning, make sure:
- You have enough LFS storage for the files you want to convert.
Storage is required for the entire history of all files.
- All the team members you share the repository with have pushed all changes.
Branches based on the repository before applying this method cannot be merged.
Branches based on the repo before applying this method cannot be merged.
To follow this tutorial, you'll need:
- Maintainer permissions to the existing Git repository
you'd like to migrate to LFS with access through the command line.
- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
and [Java Runtime Environment](https://www.java.com/en/download/manual.jsp)
(Java 7 or above) installed locally.
- BFG installed locally:
```shell
brew install bfg
```
- Git LFS installed locally:
```shell
brew install git-lfs
```
NOTE: **Note:**
This guide was tested on macOS Mojave.
## Steps
Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-repo-migration.git`.
1. Back up your repository:
Create a copy of your repository so that you can
recover it in case something goes wrong.
1. Clone `--mirror` the repo:
Cloning with the mirror flag will create a bare repository.
This ensures you get all the branches within the repo.
It creates a directory called `<repo-name>.git`
(in our example, `test-git-lfs-repo-migration.git`),
mirroring the upstream project:
```shell
git clone --mirror git@gitlab.com:gitlab-tests/test-git-lfs-repo-migration.git
```
1. Convert the Git history with BFG:
```shell
bfg --convert-to-git-lfs "*.{png,mp4,jpg,gif}" --no-blob-protection test-git-lfs-repo-migration.git
```
It is scanning all the history, and looking for any files with
that extension, and then converting them to an LFS pointer.
1. Clean up the repository:
```shell
# cd path/to/mirror/repo:
cd test-git-lfs-repo-migration.git
# clean up the repo:
git reflog expire --expire=now --all && git gc --prune=now --aggressive
```
You can also take a look on how to further [clean the repo](../../../user/project/repository/reducing_the_repo_size_using_git.md),
but it's not necessary for the purposes of this guide.
1. Install Git LFS in the mirror repository:
```shell
git lfs install
```
1. [Unprotect the default branch](../../../user/project/protected_branches.md),
so that we can force-push the rewritten repository:
1. Navigate to your project's **Settings > Repository** and
expand **Protected Branches**.
1. Scroll down to locate the protected branches and click
**Unprotect** the default branch.
1. Force-push to GitLab:
```shell
git push --force
```
1. Track the files you want with LFS:
```shell
# cd path/to/upstream/repo:
cd test-git-lfs-repo-migration
# You may need to reset your local copy with upstream's `master` after force-pushing from the mirror:
git reset --hard origin/master
# Track the files with LFS:
git lfs track "*.gif" "*.png" "*.jpg" "*.psd" "*.mp4" "img/"
```
Now all existing the files you converted, as well as the new
ones you add, will be properly tracked with LFS.
1. [Re-protect the default branch](../../../user/project/protected_branches.md):
1. Navigate to your project's **Settings > Repository** and
expand **Protected Branches**.
1. Select the default branch from the **Branch** dropdown menu,
and set up the
**Allowed to push** and **Allowed to merge** rules.
1. Click **Protect**.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
## References
- [Getting Started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
- [Migrate from Git Annex to Git LFS](../../../administration/lfs/migrate_from_git_annex_to_git_lfs.md)
- [GitLab's Git LFS user documentation](../../../administration/lfs/manage_large_binaries_with_git_lfs.md)
- [GitLab's Git LFS administrator documentation](../../../administration/lfs/lfs_administration.md)
- Alternative method to [migrate an existing repo to Git LFS](https://github.com/git-lfs/git-lfs/wiki/Tutorial#migrating-existing-repository-data-to-lfs)
<!--
Test project:
https://gitlab.com/gitlab-tests/test-git-lfs-repo-migration
-->
This document was moved to [another location](../lfs/migrate_to_git_lfs.md).
......@@ -170,7 +170,7 @@ Some tickets need specific knowledge or a deep understanding of a particular com
Move on to understanding some of GitLab's more advanced features. You can make use of GitLab.com to understand the features from an end-user perspective and then use your own instance to understand setup and configuration of the feature from an Administrative perspective
- Set up and try [Git LFS](../../administration/lfs/manage_large_binaries_with_git_lfs.md)
- Set up and try [Git LFS](../../topics/git/lfs/index.md)
- Get to know the [GitLab API](../../api/README.md), its capabilities and shortcomings
- Learn how to [migrate from SVN to Git](../../user/project/import/svn.md)
- Set up [GitLab CI/CD](../../ci/quick_start/README.md)
......
......@@ -44,7 +44,7 @@ For instance, consider the following workflow:
1. Your team develops apps which require large files to be stored in
the application repository.
1. Although you have enabled [Git LFS](../../../administration/lfs/manage_large_binaries_with_git_lfs.md#git-lfs)
1. Although you have enabled [Git LFS](../../../topics/git/lfs/index.md#git-lfs)
to your project, your storage has grown significantly.
1. Before you exceed available storage, you set up a limit of 10 GB
per repository.
......
......@@ -38,9 +38,9 @@ Having an extra job in your pipeline that checks for those vulnerabilities,
and the fact that they are displayed inside a merge request, makes it very easy
to perform audits for your Docker-based apps.
[//]: # "NOTE: The container scanning tool references the following heading in the code, so if you"
[//]: # " make a change to this heading, make sure to update the documentation URLs used in the"
[//]: # " container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar)"
<!-- NOTE: The container scanning tool references the following heading in the code, so if you
make a change to this heading, make sure to update the documentation URLs used in the
container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar) -->
## Requirements
......
......@@ -350,14 +350,6 @@ You can [award an emoji](../../award_emojis.md) to that epic or its comments.
You can [turn on notifications](../../profile/notifications.md) to be alerted about epic events.
## Limits
This section gives an overview of limits of Epics and an overview of their background.
### Description and comment length
See [Issues: Description and comment length](../../project/issues/index.md#description-and-comment-length)
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
......
......@@ -22,7 +22,7 @@ For an overview, see the video [Design Management (GitLab 12.2)](https://www.you
## Requirements
Design Management requires
[Large File Storage (LFS)](../../../administration/lfs/manage_large_binaries_with_git_lfs.md)
[Large File Storage (LFS)](../../../topics/git/lfs/index.md)
to be enabled:
- For GitLab.com, LFS is already enabled.
......
......@@ -201,18 +201,3 @@ Feature.disable(:save_issuable_health_status)
- [Issues API](../../../api/issues.md)
- Configure an [external issue tracker](../../../integration/external-issue-tracker.md)
such as Jira, Redmine, or Bugzilla.
## Limits
This section gives an overview of limits of Issues and an overview of their background.
### Description and comment length
> Introduced in [GitLab 12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61974).
Descriptions and comments on [issuable](../../../development/issuable-like-models.md) can be no
longer than 1 million characters.
Previously, there was no limit to issuable description size, which created a
[possibility of a DoS attack](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61974) by allowing
very long descriptions. It's possible that we will set this limit to a lower number in the future.
......@@ -124,11 +124,3 @@ There are two main ways to have a merge request flow with GitLab:
1. Working with forks of an authoritative project
[Learn more about the authorization for merge requests.](authorization_for_merge_requests.md)
## Limits
This section gives an overview of limits of Merge Requests and an overview of their background.
### Description and comment length
See [Issues: Description and comment length](../issues/index.md#description-and-comment-length)
......@@ -46,7 +46,7 @@ Use the switches to enable or disable the following features:
| **Forks** | ✓ | Enables [forking](../index.md#fork-a-project) functionality |
| **Pipelines** | ✓ | Enables [CI/CD](../../../ci/README.md) functionality |
| **Container Registry** | | Activates a [registry](../../packages/container_registry/) for your docker images |
| **Git Large File Storage** | | Enables the use of [large files](../../../administration/lfs/manage_large_binaries_with_git_lfs.md#git-lfs) |
| **Git Large File Storage** | | Enables the use of [large files](../../../topics/git/lfs/index.md#git-lfs) |
| **Packages** | | Supports configuration of a [package registry](../../../administration/packages/index.md#gitlab-package-registry-administration-premium-only) functionality |
| **Wiki** | ✓ | Enables a separate system for [documentation](../wiki/) |
| **Snippets** | ✓ | Enables [sharing of code and text](../../snippets.md) |
......
---
redirect_to: '../administration/lfs/manage_large_binaries_with_git_lfs.md'
redirect_to: '../topics/git/lfs/index.md'
---
This document was moved to [another location](../administration/lfs/manage_large_binaries_with_git_lfs.md).
This document was moved to [another location](../topics/git/lfs/index.md).
---
redirect_to: '../../administration/lfs/manage_large_binaries_with_git_lfs.md'
redirect_to: '../../topics/git/lfs/index.md'
---
This document was moved to [another location](../../administration/lfs/manage_large_binaries_with_git_lfs.md).
This document was moved to [another location](../../topics/git/lfs/index.md).
---
redirect_to: '../../administration/lfs/migrate_from_git_annex_to_git_lfs.md'
redirect_to: '../../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md'
---
This document was moved to [another location](../../administration/lfs/migrate_from_git_annex_to_git_lfs.md).
This document was moved to [another location](../../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md).
......@@ -11,7 +11,7 @@ module Gitlab
def with_measuring
logger.info "Measuring enabled..."
with_gc_counter do
with_gc_stats do
with_count_queries do
with_measure_time do
yield
......@@ -39,15 +39,17 @@ module Gitlab
logger.info "Number of sql calls: #{count}"
end
def with_gc_counter
gc_counts_before = GC.stat.select { |k, _v| k =~ /count/ }
def with_gc_stats
GC.start # perform a full mark-and-sweep
stats_before = GC.stat
yield
gc_counts_after = GC.stat.select { |k, _v| k =~ /count/ }
stats = gc_counts_before.merge(gc_counts_after) { |_k, vb, va| va - vb }
logger.info "Total GC count: #{stats[:count]}"
logger.info "Minor GC count: #{stats[:minor_gc_count]}"
logger.info "Major GC count: #{stats[:major_gc_count]}"
stats_after = GC.stat
stats_diff = stats_after.map do |key, after_value|
before_value = stats_before[key]
[key, before: before_value, after: after_value, diff: after_value - before_value]
end.to_h
logger.info "GC stats:"
logger.info JSON.pretty_generate(stats_diff)
end
def with_measure_time
......
import $ from 'jquery';
import blobBundle from '~/blob_edit/blob_bundle';
import { mockTracking, unmockTracking } from 'helpers/tracking_helper';
jest.mock('~/blob_edit/edit_blob');
describe('BlobBundle', () => {
beforeEach(() => {
setFixtures(`
describe('No Suggest Popover', () => {
beforeEach(() => {
setFixtures(`
<div class="js-edit-blob-form" data-blob-filename="blah">
<button class="js-commit-button"></button>
<a class="btn btn-cancel" href="#"></a>
</div>`);
blobBundle();
});
it('sets the window beforeunload listener to a function returning a string', () => {
expect(window.onbeforeunload()).toBe('');
});
blobBundle();
});
it('sets the window beforeunload listener to a function returning a string', () => {
expect(window.onbeforeunload()).toBe('');
});
it('removes beforeunload listener if commit button is clicked', () => {
$('.js-commit-button').click();
it('removes beforeunload listener if commit button is clicked', () => {
$('.js-commit-button').click();
expect(window.onbeforeunload).toBeNull();
expect(window.onbeforeunload).toBeNull();
});
it('removes beforeunload listener when cancel link is clicked', () => {
$('.btn.btn-cancel').click();
expect(window.onbeforeunload).toBeNull();
});
});
it('removes beforeunload listener when cancel link is clicked', () => {
$('.btn.btn-cancel').click();
describe('Suggest Popover', () => {
let trackingSpy;
beforeEach(() => {
setFixtures(`
<div class="js-edit-blob-form" data-blob-filename="blah" id="target">
<div class="js-suggest-gitlab-ci-yml"
data-target="#target"
data-track-label="suggest_gitlab_ci_yml"
data-dismiss-key="1"
data-human-access="owner">
<button id='commit-changes' class="js-commit-button"></button>
<a class="btn btn-cancel" href="#"></a>
</div>
</div>`);
trackingSpy = mockTracking('_category_', $('#commit-changes').element, jest.spyOn);
document.body.dataset.page = 'projects:blob:new';
blobBundle();
});
afterEach(() => {
unmockTracking();
});
it('sends a tracking event when the commit button is clicked', () => {
$('#commit-changes').click();
expect(window.onbeforeunload).toBeNull();
expect(trackingSpy).toHaveBeenCalledTimes(1);
expect(trackingSpy).toHaveBeenCalledWith(undefined, undefined, {
label: 'suggest_gitlab_ci_yml',
property: 'owner',
});
});
});
});
......@@ -34,7 +34,7 @@ export const utilsMockData = [
content: [
{
text:
'Using Docker executor with image dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.34',
'Using Docker executor with image dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.6.5-golang-1.12-git-2.26-lfs-2.9-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.34',
},
],
section: 'prepare-executor',
......
......@@ -20,25 +20,25 @@ describe('Single Stat Chart component', () => {
describe('computed', () => {
describe('statValue', () => {
it('should interpolate the value and unit props', () => {
expect(singleStatChart.vm.statValue).toBe('91MB');
expect(singleStatChart.vm.statValue).toBe('91.00MB');
});
it('should change the value representation to a percentile one', () => {
singleStatChart.setProps({
graphData: {
...graphDataPrometheusQuery,
max_value: 120,
maxValue: 120,
},
});
expect(singleStatChart.vm.statValue).toContain('75.8');
expect(singleStatChart.vm.statValue).toContain('75.83%');
});
it('should display NaN for non numeric max_value values', () => {
it('should display NaN for non numeric maxValue values', () => {
singleStatChart.setProps({
graphData: {
...graphDataPrometheusQuery,
max_value: 'not a number',
maxValue: 'not a number',
},
});
......@@ -60,7 +60,7 @@ describe('Single Stat Chart component', () => {
],
},
],
max_value: 120,
maxValue: 120,
},
});
......
import { shallowMount } from '@vue/test-utils';
import { mount } from '@vue/test-utils';
import { setTestTimeout } from 'helpers/timeout';
import { GlLink } from '@gitlab/ui';
import { GlAreaChart, GlLineChart, GlChartSeriesLabel } from '@gitlab/ui/dist/charts';
import {
GlAreaChart,
GlLineChart,
GlChartSeriesLabel,
GlChartLegend,
} from '@gitlab/ui/dist/charts';
import { cloneDeep } from 'lodash';
import { shallowWrapperContainsSlotText } from 'helpers/vue_test_utils_helper';
import { chartColorValues } from '~/monitoring/constants';
import { createStore } from '~/monitoring/stores';
import TimeSeries from '~/monitoring/components/charts/time_series.vue';
import * as types from '~/monitoring/stores/mutation_types';
......@@ -42,13 +46,16 @@ describe('Time series component', () => {
let store;
const makeTimeSeriesChart = (graphData, type) =>
shallowMount(TimeSeries, {
mount(TimeSeries, {
propsData: {
graphData: { ...graphData, type },
deploymentData: store.state.monitoringDashboard.deploymentData,
projectPath: `${mockHost}${mockProjectDir}`,
},
store,
stubs: {
GlPopover: true,
},
});
describe('With a single time series', () => {
......@@ -308,10 +315,6 @@ describe('Time series component', () => {
it('formats line width correctly', () => {
expect(chartData[0].lineStyle.width).toBe(2);
});
it('formats line color correctly', () => {
expect(chartData[0].lineStyle.color).toBe(chartColorValues[0]);
});
});
describe('chartOptions', () => {
......@@ -557,19 +560,39 @@ describe('Time series component', () => {
timeSeriesChart.destroy();
});
describe('computed', () => {
let chartData;
describe('Color match', () => {
let lineColors;
beforeEach(() => {
({ chartData } = timeSeriesChart.vm);
lineColors = timeSeriesChart
.find(GlAreaChart)
.vm.series.map(item => item.lineStyle.color);
});
it('should contain different colors for contiguous time series', () => {
lineColors.forEach((color, index) => {
expect(color).not.toBe(lineColors[index + 1]);
});
});
it('should contain different colors for each time series', () => {
expect(chartData[0].lineStyle.color).toBe('#1f78d1');
expect(chartData[1].lineStyle.color).toBe('#1aaa55');
expect(chartData[2].lineStyle.color).toBe('#fc9403');
expect(chartData[3].lineStyle.color).toBe('#6d49cb');
expect(chartData[4].lineStyle.color).toBe('#1f78d1');
it('should match series color with tooltip label color', () => {
const labels = timeSeriesChart.findAll(GlChartSeriesLabel);
lineColors.forEach((color, index) => {
const labelColor = labels.at(index).props('color');
expect(color).toBe(labelColor);
});
});
it('should match series color with legend color', () => {
const legendColors = timeSeriesChart
.find(GlChartLegend)
.props('seriesInfo')
.map(item => item.color);
lineColors.forEach((color, index) => {
expect(color).toBe(legendColors[index]);
});
});
});
});
......
......@@ -220,6 +220,15 @@ describe('mapToDashboardViewModel', () => {
expect(getMappedPanel().yAxis.format).toBe(SUPPORTED_FORMATS.number);
});
// This property allows single_stat panels to render percentile values
it('group maxValue', () => {
setupWithPanel({
max_value: 100,
});
expect(getMappedPanel().maxValue).toBe(100);
});
});
describe('metrics mapping', () => {
......
......@@ -31,9 +31,9 @@ const defaultProps = {
registryAvailable: false,
registryHelpPath: '/help/user/packages/container_registry/index',
lfsAvailable: true,
lfsHelpPath: '/help/workflow/lfs/manage_large_binaries_with_git_lfs',
lfsHelpPath: '/help/topics/git/lfs/index',
lfsObjectsExist: false,
lfsObjectsRemovalHelpPath: `/help/administration/lfs/manage_large_binaries_with_git_lfs#removing-objects-from-lfs`,
lfsObjectsRemovalHelpPath: `/help/topics/git/lfs/index#removing-objects-from-lfs`,
pagesAvailable: true,
pagesAccessControlEnabled: false,
pagesAccessControlForced: false,
......@@ -363,7 +363,7 @@ describe('Settings Panel', () => {
);
expect(link.text()).toEqual('How do I remove them?');
expect(link.attributes('href')).toEqual(
'/help/administration/lfs/manage_large_binaries_with_git_lfs#removing-objects-from-lfs',
'/help/topics/git/lfs/index#removing-objects-from-lfs',
);
});
} else {
......
......@@ -5,7 +5,7 @@ RSpec.shared_examples 'measurable' do
let(:measurement_enabled) { true }
it 'prints measurement results' do
expect { subject }.to output(including('Measuring enabled...', 'Number of sql calls:', 'Total GC count:', 'Total GC count:')).to_stdout
expect { subject }.to output(including('Measuring enabled...', 'Number of sql calls:', 'GC stats:')).to_stdout
end
end
......
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