Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
7131f9028d
commit
6f5b1492ab
|
@ -1 +1 @@
|
|||
4e5fe176e6b36866ba305e5af1ca494b031cadc8
|
||||
ec5dd7b3c441c744e4b74a083deec1f41435cb71
|
||||
|
|
|
@ -0,0 +1,64 @@
|
|||
<script>
|
||||
import { GlButton, GlModalDirective, GlTooltipDirective } from '@gitlab/ui';
|
||||
import { formType } from '~/boards/constants';
|
||||
import eventHub from '~/boards/eventhub';
|
||||
import { s__, __ } from '~/locale';
|
||||
|
||||
export default {
|
||||
components: {
|
||||
GlButton,
|
||||
},
|
||||
directives: {
|
||||
GlTooltip: GlTooltipDirective,
|
||||
GlModalDirective,
|
||||
},
|
||||
props: {
|
||||
boardsStore: {
|
||||
type: Object,
|
||||
required: true,
|
||||
},
|
||||
canAdminList: {
|
||||
type: Boolean,
|
||||
required: true,
|
||||
},
|
||||
hasScope: {
|
||||
type: Boolean,
|
||||
required: true,
|
||||
},
|
||||
},
|
||||
data() {
|
||||
return {
|
||||
state: this.boardsStore.state,
|
||||
};
|
||||
},
|
||||
computed: {
|
||||
buttonText() {
|
||||
return this.canAdminList ? s__('Boards|Edit board') : s__('Boards|View scope');
|
||||
},
|
||||
tooltipTitle() {
|
||||
return this.hasScope ? __("This board's scope is reduced") : '';
|
||||
},
|
||||
},
|
||||
methods: {
|
||||
showPage() {
|
||||
eventHub.$emit('showBoardModal', formType.edit);
|
||||
return this.boardsStore.showPage(formType.edit);
|
||||
},
|
||||
},
|
||||
};
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<div class="gl-ml-3 gl-display-flex gl-align-items-center">
|
||||
<gl-button
|
||||
v-gl-modal-directive="'board-config-modal'"
|
||||
v-gl-tooltip
|
||||
:title="tooltipTitle"
|
||||
:class="{ 'dot-highlight': hasScope }"
|
||||
data-qa-selector="boards_config_button"
|
||||
@click.prevent="showPage"
|
||||
>
|
||||
{{ buttonText }}
|
||||
</gl-button>
|
||||
</div>
|
||||
</template>
|
|
@ -1 +1,24 @@
|
|||
export default () => {};
|
||||
import Vue from 'vue';
|
||||
import { parseBoolean } from '~/lib/utils/common_utils';
|
||||
import ConfigToggle from './components/config_toggle.vue';
|
||||
|
||||
export default (boardsStore) => {
|
||||
const el = document.querySelector('.js-board-config');
|
||||
|
||||
if (!el) {
|
||||
return;
|
||||
}
|
||||
|
||||
gl.boardConfigToggle = new Vue({
|
||||
el,
|
||||
render(h) {
|
||||
return h(ConfigToggle, {
|
||||
props: {
|
||||
boardsStore,
|
||||
canAdminList: parseBoolean(el.dataset.canAdminList),
|
||||
hasScope: parseBoolean(el.dataset.hasScope),
|
||||
},
|
||||
});
|
||||
},
|
||||
});
|
||||
};
|
||||
|
|
|
@ -6,7 +6,6 @@ import 'ee_else_ce/boards/models/issue';
|
|||
import 'ee_else_ce/boards/models/list';
|
||||
import BoardSidebar from 'ee_else_ce/boards/components/board_sidebar';
|
||||
import initNewListDropdown from 'ee_else_ce/boards/components/new_list_dropdown';
|
||||
import boardConfigToggle from 'ee_else_ce/boards/config_toggle';
|
||||
import {
|
||||
setWeightFetchingState,
|
||||
setEpicFetchingState,
|
||||
|
@ -40,6 +39,7 @@ import {
|
|||
} from '~/lib/utils/common_utils';
|
||||
import { __ } from '~/locale';
|
||||
import sidebarEventHub from '~/sidebar/event_hub';
|
||||
import boardConfigToggle from './config_toggle';
|
||||
import mountMultipleBoardsSwitcher from './mount_multiple_boards_switcher';
|
||||
|
||||
Vue.use(VueApollo);
|
||||
|
|
|
@ -3,8 +3,6 @@ import GLForm from '../../../../gl_form';
|
|||
import RefSelectDropdown from '../../../../ref_select_dropdown';
|
||||
import ZenMode from '../../../../zen_mode';
|
||||
|
||||
document.addEventListener('DOMContentLoaded', () => {
|
||||
new ZenMode(); // eslint-disable-line no-new
|
||||
new GLForm($('.tag-form')); // eslint-disable-line no-new
|
||||
new RefSelectDropdown($('.js-branch-select')); // eslint-disable-line no-new
|
||||
});
|
||||
new ZenMode(); // eslint-disable-line no-new
|
||||
new GLForm($('.tag-form')); // eslint-disable-line no-new
|
||||
new RefSelectDropdown($('.js-branch-select')); // eslint-disable-line no-new
|
||||
|
|
|
@ -24,6 +24,7 @@ module Types
|
|||
mount_mutation Mutations::AwardEmojis::Toggle
|
||||
mount_mutation Mutations::Boards::Create
|
||||
mount_mutation Mutations::Boards::Destroy
|
||||
mount_mutation Mutations::Boards::Update
|
||||
mount_mutation Mutations::Boards::Issues::IssueMoveList
|
||||
mount_mutation Mutations::Boards::Lists::Create
|
||||
mount_mutation Mutations::Boards::Lists::Update
|
||||
|
|
|
@ -14,6 +14,7 @@ class List < ApplicationRecord
|
|||
validates :label_id, uniqueness: { scope: :board_id }, if: :label?
|
||||
|
||||
scope :preload_associated_models, -> { preload(:board, label: :priorities) }
|
||||
scope :without_types, ->(list_types) { where.not(list_type: list_types) }
|
||||
|
||||
alias_method :preferences, :list_user_preferences
|
||||
|
||||
|
|
|
@ -3,6 +3,8 @@
|
|||
class CurrentBoardEntity < Grape::Entity
|
||||
expose :id
|
||||
expose :name
|
||||
expose :hide_backlog_list
|
||||
expose :hide_closed_list
|
||||
end
|
||||
|
||||
CurrentBoardEntity.prepend_if_ee('EE::CurrentBoardEntity')
|
||||
|
|
|
@ -9,7 +9,26 @@ module Boards
|
|||
end
|
||||
|
||||
lists = board.lists.preload_associated_models
|
||||
params[:list_id].present? ? lists.where(id: params[:list_id]) : lists # rubocop: disable CodeReuse/ActiveRecord
|
||||
|
||||
return lists.id_in(params[:list_id]) if params[:list_id].present?
|
||||
|
||||
list_types = unavailable_list_types_for(board)
|
||||
lists.without_types(list_types)
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def unavailable_list_types_for(board)
|
||||
hidden_lists_for(board)
|
||||
end
|
||||
|
||||
def hidden_lists_for(board)
|
||||
hidden = []
|
||||
|
||||
hidden << ::List.list_types[:backlog] if board.hide_backlog_list
|
||||
hidden << ::List.list_types[:closed] if board.hide_closed_list
|
||||
|
||||
hidden
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
@ -33,5 +33,5 @@
|
|||
= visibility_level_icon(group.visibility_level)
|
||||
|
||||
.controls.gl-flex-shrink-0.gl-ml-5
|
||||
= link_to _('Edit'), admin_group_edit_path(group), id: "edit_#{dom_id(group)}", class: 'gl-button btn'
|
||||
= link_to _('Edit'), admin_group_edit_path(group), id: "edit_#{dom_id(group)}", class: 'btn gl-button btn-default'
|
||||
= link_to _('Delete'), [:admin, group], data: { confirm: _("Are you sure you want to remove %{group_name}?") % { group_name: group.name } }, method: :delete, class: 'gl-button btn btn-danger'
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
- @projects.each_with_index do |project|
|
||||
%li.project-row{ class: ('no-description' if project.description.blank?) }
|
||||
.controls
|
||||
= link_to 'Edit', edit_project_path(project), id: "edit_#{dom_id(project)}", class: "gl-button btn"
|
||||
= link_to 'Edit', edit_project_path(project), id: "edit_#{dom_id(project)}", class: "btn gl-button btn-default"
|
||||
%button.delete-project-button.gl-button.btn.btn-danger{ data: { delete_project_url: admin_project_path(project), project_name: project.name } }
|
||||
= s_('AdminProjects|Delete')
|
||||
|
||||
|
|
|
@ -195,7 +195,7 @@
|
|||
#js-board-labels-toggle
|
||||
- if current_user
|
||||
#js-board-epics-swimlanes-toggle
|
||||
.js-board-config{ data: { can_admin_list: user_can_admin_list, has_scope: board.scoped? } }
|
||||
.js-board-config{ data: { can_admin_list: user_can_admin_list.to_s, has_scope: board.scoped?.to_s } }
|
||||
- if user_can_admin_list
|
||||
- if Feature.enabled?(:board_new_list, board.resource_parent, default_enabled: :yaml)
|
||||
.js-create-column-trigger{ data: board_list_data }
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add btn-default class for edit buttons in admin projects and groups
|
||||
merge_request: 53453
|
||||
author:
|
||||
type: other
|
|
@ -41,6 +41,7 @@ autoscales
|
|||
autoscaling
|
||||
awardable
|
||||
awardables
|
||||
Ayoa
|
||||
Axios
|
||||
Azure
|
||||
B-tree
|
||||
|
@ -111,6 +112,8 @@ Contentful
|
|||
Corosync
|
||||
Coursier
|
||||
cron
|
||||
cronjob
|
||||
cronjobs
|
||||
crons
|
||||
crontab
|
||||
crontabs
|
||||
|
@ -280,6 +283,7 @@ kaniko
|
|||
Karma
|
||||
Kerberos
|
||||
keyset
|
||||
keyspace
|
||||
keytab
|
||||
keytabs
|
||||
Kibana
|
||||
|
@ -350,6 +354,7 @@ mixins
|
|||
mockup
|
||||
mockups
|
||||
ModSecurity
|
||||
Monokai
|
||||
monorepo
|
||||
monorepos
|
||||
multiline
|
||||
|
@ -408,6 +413,7 @@ pooler
|
|||
postgres.ai
|
||||
PostgreSQL
|
||||
precompile
|
||||
precompiled
|
||||
preconfigure
|
||||
preconfigured
|
||||
preconfigures
|
||||
|
@ -445,6 +451,7 @@ queryable
|
|||
Quicktime
|
||||
Rackspace
|
||||
Raspbian
|
||||
rbtrace
|
||||
Rdoc
|
||||
reachability
|
||||
Realplayer
|
||||
|
@ -479,6 +486,7 @@ reinitialize
|
|||
reinitializing
|
||||
relicensing
|
||||
remediations
|
||||
replicables
|
||||
repmgr
|
||||
repmgrd
|
||||
repurposing
|
||||
|
@ -521,6 +529,7 @@ Salesforce
|
|||
sandboxing
|
||||
sanitization
|
||||
sbt
|
||||
scalers
|
||||
scatterplot
|
||||
scatterplots
|
||||
Schemastore
|
||||
|
@ -546,6 +555,7 @@ Slackbot
|
|||
Slony
|
||||
smartcard
|
||||
smartcards
|
||||
snapshotting
|
||||
Sobelow
|
||||
Solarized
|
||||
Sourcegraph
|
||||
|
@ -564,6 +574,7 @@ strace
|
|||
strikethrough
|
||||
strikethroughs
|
||||
stunnel
|
||||
stylelint
|
||||
subfolder
|
||||
subfolders
|
||||
subgraph
|
||||
|
@ -629,6 +640,7 @@ toolkit
|
|||
toolkits
|
||||
tooltip
|
||||
tooltips
|
||||
transactionally
|
||||
transpile
|
||||
transpiled
|
||||
transpiles
|
||||
|
@ -637,6 +649,7 @@ Trello
|
|||
triaged
|
||||
triages
|
||||
triaging
|
||||
Trivy
|
||||
truthy
|
||||
Truststore
|
||||
Twilio
|
||||
|
|
|
@ -67,7 +67,7 @@ We have the following documentation to rapidly uplift your GitLab knowledge:
|
|||
| Topic | Description |
|
||||
|:--------------------------------------------------------------------------------------------------|:------------|
|
||||
| [GitLab basics guides](gitlab-basics/index.md) | Start working on the command line and with GitLab. |
|
||||
| [GitLab workflow overview](https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/) | Enhance your workflow with the best of GitLab Workflow. |
|
||||
| [GitLab workflow overview](https://about.gitlab.com/topics/version-control/what-is-gitlab-workflow/) | Enhance your workflow with the best of GitLab Workflow. |
|
||||
| [Get started with GitLab CI/CD](ci/quick_start/index.md) | Quickly implement GitLab CI/CD. |
|
||||
| [Auto DevOps](topics/autodevops/index.md) | Learn more about Auto DevOps in GitLab. |
|
||||
| [GitLab Markdown](user/markdown.md) | Advanced formatting system (GitLab Flavored Markdown). |
|
||||
|
|
|
@ -146,7 +146,7 @@ sudo gitlab-ctl restart consul
|
|||
### Consul nodes unable to communicate
|
||||
|
||||
By default, Consul will attempt to
|
||||
[bind](https://www.consul.io/docs/agent/options.html#_bind) to `0.0.0.0`, but
|
||||
[bind](https://www.consul.io/docs/agent/options#_bind) to `0.0.0.0`, but
|
||||
it will advertise the first private IP address on the node for other Consul nodes
|
||||
to communicate with it. If the other nodes cannot communicate with a node on
|
||||
this address, then the cluster will have a failed status.
|
||||
|
|
|
@ -19,8 +19,8 @@ before/after the brackets. Also, some shells (for example, `zsh`) can interpret
|
|||
|
||||
## Caveats
|
||||
|
||||
If the GitHub [rate limit](https://docs.github.com/v3/#rate-limiting) is reached while importing,
|
||||
the importing process waits (`sleep()`) until it can continue importing.
|
||||
If the GitHub [rate limit](https://docs.github.com/en/rest/reference/rate-limit) is reached while
|
||||
importing, the importing process waits (`sleep()`) until it can continue importing.
|
||||
|
||||
## Importing multiple projects
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ cannot be used to authenticate with GitHub as an external CI/CD repository.
|
|||
## Connect with Personal Access Token
|
||||
|
||||
Personal access tokens can only be used to connect GitHub.com
|
||||
repositories to GitLab, and the GitHub user must have the [owner role](https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/access-permissions-on-github).
|
||||
repositories to GitLab, and the GitHub user must have the [owner role](https://docs.github.com/en/github/getting-started-with-github/access-permissions-on-github).
|
||||
|
||||
To perform a one-off authorization with GitHub to grant GitLab access your
|
||||
repositories:
|
||||
|
|
|
@ -319,4 +319,4 @@ For a video walkthrough of this configuration process, see [Auto Deploy to EC2](
|
|||
|
||||
## Deploy to Google Cloud
|
||||
|
||||
- [Deploying with GitLab on Google Cloud](https://about.gitlab.com/solutions/google-cloud-platform/)
|
||||
- [Deploying with GitLab on Google Cloud](https://about.gitlab.com/partners/technology-partners/google-cloud-platform/)
|
||||
|
|
|
@ -872,4 +872,4 @@ If:
|
|||
- This is the first time setting it up, carefully read
|
||||
[using Docker in Docker workflow](#use-the-docker-executor-with-the-docker-image-docker-in-docker).
|
||||
- You are upgrading from v18.09 or earlier, read our
|
||||
[upgrade guide](https://about.gitlab.com/releases/2019/07/31/docker-in-docker-with-docker-19-dot-03/).
|
||||
[upgrade guide](https://about.gitlab.com/blog/2019/07/31/docker-in-docker-with-docker-19-dot-03/).
|
||||
|
|
|
@ -1069,7 +1069,7 @@ Re-using variables defined inside `script` as part of the environment name doesn
|
|||
Below are some links you may find interesting:
|
||||
|
||||
- [The `.gitlab-ci.yml` definition of environments](../yaml/README.md#environment)
|
||||
- [A blog post on Deployments & Environments](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/)
|
||||
- [A blog post on Deployments & Environments](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/)
|
||||
- [Review Apps - Use dynamic environments to deploy your code for every branch](../review_apps/index.md)
|
||||
- [Deploy Boards for your applications running on Kubernetes](../../user/project/deploy_boards.md)
|
||||
|
||||
|
|
|
@ -70,7 +70,7 @@ Alternatively, you can use the API to protect an environment:
|
|||
name: ${CI_JOB_NAME}
|
||||
```
|
||||
|
||||
1. Use the UI to [create a new group](../../user/group/index.md#create-a-new-group).
|
||||
1. Use the UI to [create a new group](../../user/group/index.md#create-a-group).
|
||||
For example, this group is called `protected-access-group` and has the group ID `9899826`. Note
|
||||
that the rest of the examples in these steps use this group.
|
||||
|
||||
|
|
|
@ -7,8 +7,6 @@ type: tutorial
|
|||
|
||||
# Authenticating and Reading Secrets With HashiCorp Vault
|
||||
|
||||
> HashiCorp Vault JWT token support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294440) in GitLab 13.9.
|
||||
|
||||
This tutorial demonstrates how to authenticate, configure, and read secrets with HashiCorp's Vault from GitLab CI/CD.
|
||||
|
||||
NOTE:
|
||||
|
@ -56,8 +54,8 @@ The JWT's payload looks like this:
|
|||
"ref": "auto-deploy-2020-04-01", # Git ref for this job
|
||||
"ref_type": "branch", # Git ref type, branch or tag
|
||||
"ref_protected": "true", # true if this git ref is protected, false otherwise
|
||||
"environment": "production", # Environment this job deploys to, if present
|
||||
"environment_protected": "true" # true if deployed environment is protected, false otherwise
|
||||
"environment": "production", # Environment this job deploys to, if present (GitLab 13.9 and later)
|
||||
"environment_protected": "true" # true if deployed environment is protected, false otherwise (GitLab 13.9 and later)
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
@ -10,6 +10,7 @@ description: 'Confidence checking your entire app every time a new feature is ad
|
|||
---
|
||||
|
||||
<!-- vale off -->
|
||||
<!-- Needs review for fixing the broken Webdriver links, which link to a deprecated version of Webdriver. -->
|
||||
|
||||
# End-to-end testing with GitLab CI/CD and WebdriverIO
|
||||
|
||||
|
@ -83,7 +84,7 @@ multiple tests, such as making sure you are logged in.
|
|||
The function `it` defines an individual test.
|
||||
|
||||
[The `browser` object](https://webdriver.io/guide/testrunner/browserobject.html) is WebdriverIO's
|
||||
special sauce. It provides most of [the WebdriverIO API methods](https://webdriver.io/api.html) that are the key to
|
||||
special sauce. It provides most of [the WebdriverIO API methods](https://webdriver.io/docs/api/) that are the key to
|
||||
steering the browser. In this case, we can use
|
||||
[`browser.url`](https://webdriver.io/api/protocol/url.html) to visit `/page-that-does-not-exist` to
|
||||
hit our 404 page. We can then use [`browser.getUrl`](https://webdriver.io/api/property/getUrl.html)
|
||||
|
|
|
@ -619,7 +619,7 @@ deploy_production:
|
|||
- master
|
||||
```
|
||||
|
||||
You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/), to final test your application before deploying to production.
|
||||
You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/), to final test your application before deploying to production.
|
||||
|
||||
### Turn on GitLab CI/CD
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Kubernetes Agent user stories **(PREMIUM SELF)**
|
||||
|
||||
The [personas in action](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#user-personas)
|
||||
The [personas in action](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#user-personas)
|
||||
for the Kubernetes Agent are:
|
||||
|
||||
- [Sasha, the Software Developer](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#sasha-software-developer).
|
||||
|
|
|
@ -13,7 +13,7 @@ This document outlines the style guide for the GitLab [GraphQL API](../api/graph
|
|||
<!-- vale gitlab.Spelling = NO -->
|
||||
We use the [GraphQL Ruby gem](https://graphql-ruby.org/) written by [Robert Mosolgo](https://github.com/rmosolgo/).
|
||||
<!-- vale gitlab.Spelling = YES -->
|
||||
In addition, we have a subscription to [GraphQL Pro](https://www.graphql.pro). For details see [GraphQL Pro subscription](graphql_guide/graphql_pro.md).
|
||||
In addition, we have a subscription to [GraphQL Pro](https://graphql.pro/). For details see [GraphQL Pro subscription](graphql_guide/graphql_pro.md).
|
||||
|
||||
All GraphQL queries are directed to a single endpoint
|
||||
([`app/controllers/graphql_controller.rb#execute`](https://gitlab.com/gitlab-org/gitlab/blob/master/app%2Fcontrollers%2Fgraphql_controller.rb)),
|
||||
|
|
|
@ -88,7 +88,7 @@ for example `Jobs/Deploy.gitlab-ci.yml`.
|
|||
You can make a new stable template by copying [the latest template](#latest-version)
|
||||
available in a major milestone release of GitLab like `13.0`. All breaking changes
|
||||
must be announced in a blog post before the official release, for example
|
||||
[GitLab.com is moving to 13.0, with narrow breaking changes](https://about.gitlab.com/releases/2020/05/06/gitlab-com-13-0-breaking-changes/)
|
||||
[GitLab.com is moving to 13.0, with narrow breaking changes](https://about.gitlab.com/blog/2020/05/06/gitlab-com-13-0-breaking-changes/)
|
||||
|
||||
You can change a stable template version in a minor GitLab release like `13.1` if:
|
||||
|
||||
|
|
|
@ -181,7 +181,7 @@ For instance, the "DevOps Report" category is represented by the
|
|||
`devops_reports.name` value is "DevOps Reports".
|
||||
|
||||
If a category's label doesn't respect this naming convention, it should be specified
|
||||
with [the `label` attribute](https://about.gitlab.com/handbook/marketing/website/#category-attributes)
|
||||
with [the `label` attribute](https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/website/#category-attributes)
|
||||
in <https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml>.
|
||||
|
||||
### Feature labels
|
||||
|
|
|
@ -206,7 +206,7 @@ If `GITLAB_TRACING` is not configured correctly, this issue is logged:
|
|||
|
||||
By default, GitLab ships with the Jaeger tracer, but other tracers can be included at compile time.
|
||||
Details of how this can be done are included in the [LabKit tracing
|
||||
documentation](https://godoc.org/gitlab.com/gitlab-org/labkit/tracing).
|
||||
documentation](https://pkg.go.dev/gitlab.com/gitlab-org/labkit/tracing).
|
||||
|
||||
If no log messages about tracing are emitted, the `GITLAB_TRACING` environment variable is likely
|
||||
not set.
|
||||
|
|
|
@ -272,7 +272,11 @@ To configure Vale in your editor, install one of the following as appropriate:
|
|||
In the extension's settings:
|
||||
|
||||
- Select the **Use CLI** checkbox.
|
||||
- In the **Config** setting, enter an absolute path to [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini) in one of the cloned GitLab repositories on your computer.
|
||||
- In the <!-- vale gitlab.Spelling = NO --> **Config** setting, enter an absolute
|
||||
path to [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini)
|
||||
in one of the cloned GitLab repositories on your computer.
|
||||
<!-- vale gitlab.Spelling = YES -->
|
||||
|
||||
- In the **Path** setting, enter the absolute path to the Vale binary. In most
|
||||
cases, `vale` should work. To find the location, run `which vale` in a terminal.
|
||||
|
||||
|
|
|
@ -202,9 +202,9 @@ code readability and test output.
|
|||
### Better output in tests
|
||||
|
||||
When comparing expected and actual values in tests, use
|
||||
[`testify/require.Equal`](https://godoc.org/github.com/stretchr/testify/require#Equal),
|
||||
[`testify/require.EqualError`](https://godoc.org/github.com/stretchr/testify/require#EqualError),
|
||||
[`testify/require.EqualValues`](https://godoc.org/github.com/stretchr/testify/require#EqualValues),
|
||||
[`testify/require.Equal`](https://pkg.go.dev/github.com/stretchr/testify/require#Equal),
|
||||
[`testify/require.EqualError`](https://pkg.go.dev/github.com/stretchr/testify/require#EqualError),
|
||||
[`testify/require.EqualValues`](https://pkg.go.dev/github.com/stretchr/testify/require#EqualValues),
|
||||
and others to improve readability when comparing structs, errors,
|
||||
large portions of text, or JSON documents:
|
||||
|
||||
|
@ -363,12 +363,12 @@ There are a few guidelines one should follow when using the
|
|||
[Logrus](https://github.com/sirupsen/logrus) package:
|
||||
|
||||
- When printing an error use
|
||||
[WithError](https://godoc.org/github.com/sirupsen/logrus#WithError). For
|
||||
[WithError](https://pkg.go.dev/github.com/sirupsen/logrus#WithError). For
|
||||
example, `logrus.WithError(err).Error("Failed to do something")`.
|
||||
- Since we use [structured logging](#structured-json-logging) we can log
|
||||
fields in the context of that code path, such as the URI of the request using
|
||||
[`WithField`](https://godoc.org/github.com/sirupsen/logrus#WithField) or
|
||||
[`WithFields`](https://godoc.org/github.com/sirupsen/logrus#WithFields). For
|
||||
[`WithField`](https://pkg.go.dev/github.com/sirupsen/logrus#WithField) or
|
||||
[`WithFields`](https://pkg.go.dev/github.com/sirupsen/logrus#WithFields). For
|
||||
example, `logrus.WithField("file", "/app/go").Info("Opening dir")`. If you
|
||||
have to log multiple keys, always use `WithFields` instead of calling
|
||||
`WithField` more than once.
|
||||
|
@ -488,7 +488,7 @@ The following are some style guidelines that are specific to the Secure Team.
|
|||
### Code style and format
|
||||
|
||||
Use `goimports -local gitlab.com/gitlab-org` before committing.
|
||||
[`goimports`](https://godoc.org/golang.org/x/tools/cmd/goimports)
|
||||
[`goimports`](https://pkg.go.dev/golang.org/x/tools/cmd/goimports)
|
||||
is a tool that automatically formats Go source code using
|
||||
[`Gofmt`](https://golang.org/cmd/gofmt/), in addition to formatting import lines,
|
||||
adding missing ones and removing unreferenced ones.
|
||||
|
|
|
@ -73,7 +73,7 @@ we simply follow the path we take to serve any ordinary upload.
|
|||
### Workhorse
|
||||
|
||||
Assuming Rails decided the request to be valid, Workhorse will take over. Upon receiving the `send-scaled-image`
|
||||
instruction through the Rails response, a [special response injecter](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/master/internal/imageresizer/image_resizer.go)
|
||||
instruction through the Rails response, a [special response injector](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/master/internal/imageresizer/image_resizer.go)
|
||||
will be invoked that knows how to rescale images. The only inputs it requires are the location of the image
|
||||
(a path if the image resides in block storage, or a URL to remote storage otherwise) and the desired width.
|
||||
Workhorse will handle the location transparently so Rails does not need to be concerned with where the image
|
||||
|
|
|
@ -13,7 +13,7 @@ guidelines so you can build an integration that fits with the workflow GitLab
|
|||
users are already familiar with.
|
||||
|
||||
This page also provides resources for the technical work associated
|
||||
with [onboarding as a partner](https://about.gitlab.com/partners/integrate/).
|
||||
with [onboarding as a partner](https://about.gitlab.com/partners/technology-partners/integrate/).
|
||||
The steps below are a high-level view of what needs to be done to complete an
|
||||
integration as well as linking to more detailed resources for how to do so.
|
||||
|
||||
|
|
|
@ -140,7 +140,7 @@ Even though this approach would make aggregating much easier, it has some major
|
|||
- We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost would be significant. The background migration would take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29772>.
|
||||
- Background migration has to be shipped one release before, delaying the functionality by another milestone.
|
||||
|
||||
### Attempt E (final): Update the namespace storage statistics in async way
|
||||
### Attempt E (final): Update the namespace storage statistics asynchronously
|
||||
|
||||
This approach consists of continuing to use the incremental statistics updates we already have,
|
||||
but we refresh them through Sidekiq jobs and in different transactions:
|
||||
|
@ -149,7 +149,7 @@ but we refresh them through Sidekiq jobs and in different transactions:
|
|||
1. Whenever the statistics of a project changes, insert a row into `namespace_aggregation_schedules`
|
||||
- We don't insert a new row if there's already one related to the root namespace.
|
||||
- Keeping in mind the length of the transaction that involves updating `project_statistics`(<https://gitlab.com/gitlab-org/gitlab/-/issues/29070>), the insertion should be done in a different transaction and through a Sidekiq Job.
|
||||
1. After inserting the row, we schedule another worker to be executed async at two different moments:
|
||||
1. After inserting the row, we schedule another worker to be executed asynchronously at two different moments:
|
||||
- One enqueued for immediate execution and another one scheduled in `1.5h` hours.
|
||||
- We only schedule the jobs, if we can obtain a `1.5h` lease on Redis on a key based on the root namespace ID.
|
||||
- If we can't obtain the lease, it indicates there's another aggregation already in progress, or scheduled in no more than `1.5h`.
|
||||
|
@ -161,7 +161,7 @@ but we refresh them through Sidekiq jobs and in different transactions:
|
|||
|
||||
This implementation has the following benefits:
|
||||
|
||||
- All the updates are done async, so we're not increasing the length of the transactions for `project_statistics`.
|
||||
- All the updates are done asynchronously, so we're not increasing the length of the transactions for `project_statistics`.
|
||||
- We're doing the update in a single SQL query.
|
||||
- It is compatible with PostgreSQL and MySQL.
|
||||
- No background migration required.
|
||||
|
|
|
@ -19,7 +19,7 @@ D3 is very popular across many projects outside of GitLab:
|
|||
|
||||
- [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html)
|
||||
- [plot.ly](https://plotly.com/)
|
||||
- [Droptask](https://www.ayoa.com/previously-droptask/)
|
||||
- [Ayoa](https://www.ayoa.com/previously-droptask/)
|
||||
|
||||
Within GitLab, D3 has been used for the following notable features
|
||||
|
||||
|
|
|
@ -256,7 +256,7 @@ The following configuration options can be configured:
|
|||
- `STACKPROF_MODE`: See [sampling modes](https://github.com/tmm1/stackprof#sampling).
|
||||
Defaults to `cpu`.
|
||||
- `STACKPROF_INTERVAL`: Sampling interval. Unit semantics depend on `STACKPROF_MODE`.
|
||||
For `object` mode this is a per-event interval (every `n`th event is sampled)
|
||||
For `object` mode this is a per-event interval (every `nth` event is sampled)
|
||||
and defaults to `1000`.
|
||||
For other modes such as `cpu` this is a frequency and defaults to `10000` μs (100hz).
|
||||
- `STACKPROF_FILE_PREFIX`: File path prefix where profiles are stored. Defaults
|
||||
|
@ -293,7 +293,7 @@ worker processes), selecting the latter.
|
|||
|
||||
For Sidekiq, the signal can be sent to the `sidekiq-cluster` process via `pkill
|
||||
-USR2 bin/sidekiq-cluster`, which forwards the signal to all Sidekiq
|
||||
children. Alternatively, you can also select a specific pid of interest.
|
||||
children. Alternatively, you can also select a specific PID of interest.
|
||||
|
||||
Production profiles can be especially noisy. It can be helpful to visualize them
|
||||
as a [flame graph](https://github.com/brendangregg/FlameGraph). This can be done
|
||||
|
@ -306,7 +306,7 @@ bundle exec stackprof --stackcollapse /tmp/stackprof.55769.c6c3906452.profile |
|
|||
## RSpec profiling
|
||||
|
||||
The GitLab development environment also includes the
|
||||
[rspec_profiling](https://github.com/foraker/rspec_profiling) gem, which is used
|
||||
[`rspec_profiling`](https://github.com/foraker/rspec_profiling) gem, which is used
|
||||
to collect data on spec execution times. This is useful for analyzing the
|
||||
performance of the test suite itself, or seeing how the performance of a spec
|
||||
may have changed over time.
|
||||
|
@ -409,7 +409,7 @@ Fragmented Ruby heap snapshot could look like this:
|
|||
|
||||
![Ruby heap fragmentation](img/memory_ruby_heap_fragmentation.png)
|
||||
|
||||
Memory fragmentation could be reduced by tuning GC parameters as described in [this post by Nate Berkopec](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html). This should be considered as a tradeoff, as it may affect overall performance of memory allocation and GC cycles.
|
||||
Memory fragmentation could be reduced by tuning GC parameters [as described in this post](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html). This should be considered as a tradeoff, as it may affect overall performance of memory allocation and GC cycles.
|
||||
|
||||
## Importance of Changes
|
||||
|
||||
|
|
|
@ -426,7 +426,7 @@ We are using a custom mapping between source file to test files, maintained in t
|
|||
|
||||
### PostgreSQL versions testing
|
||||
|
||||
Even though [Omnibus defaults to PG12 for new installs and upgrades](https://docs.gitlab.com/omnibus/package-information/postgresql_versions.md),
|
||||
Even though [Omnibus defaults to PG12 for new installs and upgrades](https://docs.gitlab.com/omnibus/package-information/postgresql_versions.html),
|
||||
our test suite is currently running against PG11, since GitLab.com still runs on PG11.
|
||||
|
||||
We do run our test suite against PG12 on nightly scheduled pipelines as well as upon specific
|
||||
|
|
|
@ -25,7 +25,7 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent
|
|||
|
||||
- When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
|
||||
- When working with batched queries, change the range and batch size to see how it effects the query timing and caching.
|
||||
- If an existing query is already underperforming, make an effort to improve it. If it is too complex or would stall development, create a follow-up so it can be addressed in a timely manner. You can always ask the database reviewer or maintainer for help and guidance.
|
||||
- If an existing query is not performing well, make an effort to improve it. If it is too complex or would stall development, create a follow-up so it can be addressed in a timely manner. You can always ask the database reviewer or maintainer for help and guidance.
|
||||
|
||||
## Cold and warm cache
|
||||
|
||||
|
|
|
@ -120,14 +120,13 @@ This shows commands that have taken a long time and may be a performance
|
|||
concern.
|
||||
|
||||
The
|
||||
[fluent-plugin-redis-slowlog](https://gitlab.com/gitlab-org/fluent-plugin-redis-slowlog)
|
||||
project is responsible for taking the slowlog entries from Redis and
|
||||
passing to fluentd (and ultimately Elasticsearch).
|
||||
[`fluent-plugin-redis-slowlog`](https://gitlab.com/gitlab-org/fluent-plugin-redis-slowlog)
|
||||
project is responsible for taking the `slowlog` entries from Redis and
|
||||
passing to Fluentd (and ultimately Elasticsearch).
|
||||
|
||||
## Analyzing the entire keyspace
|
||||
|
||||
The [Redis Keyspace
|
||||
Analyzer](https://gitlab.com/gitlab-com/gl-infra/redis-keyspace-analyzer)
|
||||
The [Redis Keyspace Analyzer](https://gitlab.com/gitlab-com/gl-infra/redis-keyspace-analyzer)
|
||||
project contains tools for dumping the full key list and memory usage of a Redis
|
||||
instance, and then analyzing those lists while eliminating potentially sensitive
|
||||
data from the results. It can be used to find the most frequent key patterns, or
|
||||
|
|
|
@ -195,7 +195,7 @@ Go's [`regexp`](https://golang.org/pkg/regexp/) package uses `re2` and isn't vul
|
|||
- [Rubular](https://rubular.com/) is a nice online tool to fiddle with Ruby Regexps.
|
||||
- [Runaway Regular Expressions](https://www.regular-expressions.info/catastrophic.html)
|
||||
- [The impact of regular expression denial of service (ReDoS) in practice: an empirical study at the ecosystem scale](https://people.cs.vt.edu/~davisjam/downloads/publications/DavisCoghlanServantLee-EcosystemREDOS-ESECFSE18.pdf). This research paper discusses approaches to automatically detect ReDoS vulnerabilities.
|
||||
- [Freezing the web: A study of redos vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.
|
||||
- [Freezing the web: A study of ReDoS vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.
|
||||
|
||||
## Server Side Request Forgery (SSRF)
|
||||
|
||||
|
|
|
@ -588,7 +588,7 @@ the `.with_route` scope defined on all `Routable`s.
|
|||
|
||||
### Cron workers
|
||||
|
||||
The context is automatically cleared for workers in the Cronjob queue
|
||||
The context is automatically cleared for workers in the cronjob queue
|
||||
(`include CronjobQueue`), even when scheduling them from
|
||||
requests. We do this to avoid incorrect metadata when other jobs are
|
||||
scheduled from the cron worker.
|
||||
|
|
|
@ -800,10 +800,11 @@ end
|
|||
```
|
||||
|
||||
WARNING:
|
||||
Only use simple values as input in the `where` block. Using procs, stateful
|
||||
Only use simple values as input in the `where` block. Using
|
||||
<!-- vale gitlab.Spelling = NO --> procs, stateful
|
||||
objects, FactoryBot-created objects, and similar items can lead to
|
||||
[unexpected results](https://github.com/tomykaira/rspec-parameterized/issues/8).
|
||||
|
||||
<!-- vale gitlab.Spelling = YES -->
|
||||
### Prometheus tests
|
||||
|
||||
Prometheus metrics may be preserved from one test run to another. To ensure that metrics are
|
||||
|
|
|
@ -193,7 +193,7 @@ When it comes to querying DOM elements in your tests, it is best to uniquely and
|
|||
the element.
|
||||
|
||||
Preferentially, this is done by targeting what the user actually sees using [DOM Testing Library](https://testing-library.com/docs/dom-testing-library/intro/).
|
||||
When selecting by text it is best to use [`getByRole` or `findByRole`](https://testing-library.com/docs/dom-testing-library/api-queries/#byrole)
|
||||
When selecting by text it is best to use [`getByRole` or `findByRole`](https://testing-library.com/docs/queries/byrole)
|
||||
as these enforce accessibility best practices as well. The examples below demonstrate the order of preference.
|
||||
|
||||
When writing Vue component unit tests, it can be wise to query children by component, so that the unit test can focus on comprehensive value coverage
|
||||
|
@ -687,7 +687,7 @@ Similarly, if you really need to use the real `Date` class, then you can import
|
|||
```javascript
|
||||
import { useRealDate } from 'helpers/fake_date';
|
||||
|
||||
// NOTE: `useRealDate` cannot be called during test execution (i.e. inside `it`, `beforeEach`, `beforeAll`, etc.).
|
||||
// NOTE: `useRealDate` cannot be called during test execution (i.e. inside `it`, `beforeEach`, `beforeAll`, etc.).
|
||||
describe('with real date', () => {
|
||||
useRealDate();
|
||||
});
|
||||
|
@ -1034,7 +1034,7 @@ describe "Admin::AbuseReports", :js do
|
|||
end
|
||||
```
|
||||
|
||||
### Jest test timeout due to async imports
|
||||
### Jest test timeout due to asynchronous imports
|
||||
|
||||
If a module asynchronously imports some other modules at runtime, these modules must be
|
||||
transpiled by the Jest loaders at runtime. It's possible that this can cause [Jest to timeout](https://gitlab.com/gitlab-org/gitlab/-/issues/280809).
|
||||
|
|
|
@ -840,7 +840,9 @@ We also use `#database-lab` and [explain.depesz.com](https://explain.depesz.com/
|
|||
|
||||
### 5. Add the metric definition
|
||||
|
||||
When adding, changing, or updating metrics, please update the [Event Dictionary's **Usage Ping** table](https://about.gitlab.com/handbook/product/product-intelligence-guide/#event-dictionary).
|
||||
[Check Metrics Dictionary Guide](usage_ping/metrics_dictionary.md)
|
||||
|
||||
When adding, updating, or removing metrics, please update the [Metrics Dictionary](usage_ping/dictionary.md).
|
||||
|
||||
### 6. Add new metric to Versions Application
|
||||
|
||||
|
|
|
@ -23,7 +23,7 @@ The following are guides to basic GitLab functionality:
|
|||
|
||||
- [Create and add your SSH public key](../ssh/README.md), for enabling Git over SSH.
|
||||
- [Create a project](../user/project/working_with_projects.md#create-a-project), to start using GitLab.
|
||||
- [Create a group](../user/group/index.md#create-a-new-group), to combine and administer
|
||||
- [Create a group](../user/group/index.md#create-a-group), to combine and administer
|
||||
projects together.
|
||||
- [Create a branch](create-branch.md), to make changes to files stored in a project's repository.
|
||||
- [Feature branch workflow](feature_branch_workflow.md).
|
||||
|
|
|
@ -13,15 +13,15 @@ You should also reference the [OmniAuth documentation](omniauth.md) for general
|
|||
|
||||
## Common SAML Terms
|
||||
|
||||
| Term | Description |
|
||||
|------|-------------|
|
||||
| Identity Provider (IdP) | The service which manages your user identities such as ADFS, Okta, Onelogin, or Ping Identity. |
|
||||
| Service Provider (SP) | SAML considers GitLab to be a service provider. |
|
||||
| Assertion | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
|
||||
| SSO | Single Sign-On. |
|
||||
| Term | Description |
|
||||
|--------------------------------|-------------|
|
||||
| Identity Provider (IdP) | The service which manages your user identities, such as ADFS, Okta, OneLogin, or Ping Identity. |
|
||||
| Service Provider (SP) | SAML considers GitLab to be a service provider. |
|
||||
| Assertion | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
|
||||
| SSO | Single Sign-On. |
|
||||
| Assertion consumer service URL | The callback on GitLab where users will be redirected after successfully authenticating with the identity provider. |
|
||||
| Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
|
||||
| Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
|
||||
| Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
|
||||
| Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
|
||||
|
||||
## General Setup
|
||||
|
||||
|
@ -265,7 +265,7 @@ considered admin users.
|
|||
|
||||
### Auditor groups **(PREMIUM SELF)**
|
||||
|
||||
> Introduced in [GitLab Starter](https://about.gitlab.com/pricing/) 11.4.
|
||||
> Introduced in GitLab 11.4.
|
||||
|
||||
The requirements are the same as the previous settings, your IdP needs to pass Group information to GitLab, you need to tell
|
||||
GitLab where to look for the groups in the SAML response, and which group(s) should be
|
||||
|
@ -454,8 +454,6 @@ args: {
|
|||
|
||||
### `uid_attribute`
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17734) in GitLab 10.7.
|
||||
|
||||
By default, the `uid` is set as the `name_id` in the SAML response. If you'd like to designate a unique attribute for the `uid`, you can set the `uid_attribute`. In the example below, the value of `uid` attribute in the SAML response is set as the `uid_attribute`.
|
||||
|
||||
```yaml
|
||||
|
|
|
@ -12,7 +12,7 @@ comments: false
|
|||
Create projects and groups.
|
||||
|
||||
- [Create a new project](../user/project/working_with_projects.md#create-a-project)
|
||||
- [Create a new group](../user/group/index.md#create-a-new-group)
|
||||
- [Create a new group](../user/group/index.md#create-a-group)
|
||||
|
||||
## Prioritize
|
||||
|
||||
|
|
|
@ -77,7 +77,7 @@ If you do not have an existing SSH key pair, generate a new one.
|
|||
1. Type `ssh-keygen -t` followed by the key type and an optional comment.
|
||||
This comment is included in the `.pub` file that's created.
|
||||
You may want to use an email address for the comment.
|
||||
|
||||
|
||||
For example, for ED25519:
|
||||
|
||||
```shell
|
||||
|
@ -111,7 +111,7 @@ If you do not have an existing SSH key pair, generate a new one.
|
|||
|
||||
1. A confirmation is displayed, including information about where your files are stored.
|
||||
|
||||
A public and private key are generated.
|
||||
A public and private key are generated.
|
||||
[Add the public SSH key to your GitLab account](#add-an-ssh-key-to-your-gitlab-account) and keep
|
||||
the private key secure.
|
||||
|
||||
|
@ -278,7 +278,7 @@ Instead, you can assign aliases to hosts in the `~.ssh/config` file.
|
|||
- For the `Host`, use an alias like `user_1.gitlab.com` and
|
||||
`user_2.gitlab.com`. Advanced configurations
|
||||
are more difficult to maintain, and these strings are easier to
|
||||
understand when you use tools like `git remote`.
|
||||
understand when you use tools like `git remote`.
|
||||
- For the `IdentityFile`, use the path the private key.
|
||||
|
||||
```conf
|
||||
|
|
|
@ -17,7 +17,7 @@ staging and canary deployments,
|
|||
## Custom buildpacks
|
||||
|
||||
If the automatic buildpack detection fails for your project, or if you want to
|
||||
use a custom buildpack, you can override the buildpack using a project variable
|
||||
use a custom buildpack, you can override the buildpack using a project CI/CD variable
|
||||
or a `.buildpacks` file in your project:
|
||||
|
||||
- **Project variable** - Create a project variable `BUILDPACK_URL` with the URL
|
||||
|
@ -43,7 +43,7 @@ can't use the `.buildpacks` file. The buildpack
|
|||
in the backend to parse the `.buildpacks` file, does not provide the necessary commands
|
||||
`bin/test-compile` and `bin/test`.
|
||||
|
||||
If your goal is to use only a single custom buildpack, you should provide the project variable
|
||||
If your goal is to use only a single custom buildpack, you should provide the project CI/CD variable
|
||||
`BUILDPACK_URL` instead.
|
||||
|
||||
## Custom `Dockerfile`
|
||||
|
@ -55,13 +55,13 @@ builds a Docker image based on the Dockerfile, rather than using buildpacks.
|
|||
This can be much faster and result in smaller images, especially if your
|
||||
Dockerfile is based on [Alpine](https://hub.docker.com/_/alpine/).
|
||||
|
||||
If you set the `DOCKERFILE_PATH` CI variable, Auto Build looks for a Dockerfile there
|
||||
If you set the `DOCKERFILE_PATH` CI/CD variable, Auto Build looks for a Dockerfile there
|
||||
instead.
|
||||
|
||||
## Passing arguments to `docker build`
|
||||
|
||||
Arguments can be passed to the `docker build` command using the
|
||||
`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` project variable. For example, to build a
|
||||
`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` project CI/CD variable. For example, to build a
|
||||
Docker image based on based on the `ruby:alpine` instead of the default `ruby:latest`:
|
||||
|
||||
1. Set `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` to `--build-arg=RUBY_VERSION=alpine`.
|
||||
|
@ -93,12 +93,12 @@ You can extend and manage your Auto DevOps configuration with GitLab APIs:
|
|||
- [Editing groups](../../api/groups.md#update-group).
|
||||
- [Editing projects](../../api/projects.md#edit-project).
|
||||
|
||||
## Forward CI variables to the build environment
|
||||
## Forward CI/CD variables to the build environment
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25514) in GitLab 12.3, but available in versions 11.9 and above.
|
||||
|
||||
CI variables can be forwarded into the build environment using the
|
||||
`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI variable.
|
||||
CI/CD variables can be forwarded into the build environment using the
|
||||
`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI/CD variable.
|
||||
The forwarded variables should be specified by name in a comma-separated
|
||||
list. For example, to forward the variables `CI_COMMIT_SHA` and
|
||||
`CI_ENVIRONMENT_NAME`, set `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES`
|
||||
|
@ -130,7 +130,7 @@ feature to use the `--secret` flag.
|
|||
|
||||
Auto DevOps uses [Helm](https://helm.sh/) to deploy your application to Kubernetes.
|
||||
You can override the Helm chart used by bundling up a chart into your project
|
||||
repository or by specifying a project variable:
|
||||
repository or by specifying a project CI/CD variable:
|
||||
|
||||
- **Bundled chart** - If your project has a `./chart` directory with a `Chart.yaml`
|
||||
file in it, Auto DevOps detects the chart and uses it instead of the
|
||||
|
@ -151,17 +151,17 @@ You can override the default values in the `values.yaml` file in the
|
|||
- Adding a file named `.gitlab/auto-deploy-values.yaml` to your repository, which is
|
||||
automatically used, if found.
|
||||
- Adding a file with a different name or path to the repository, and setting the
|
||||
`HELM_UPGRADE_VALUES_FILE` [environment variable](#environment-variables) with
|
||||
`HELM_UPGRADE_VALUES_FILE` [CI/CD variable](#cicd-variables) with
|
||||
the path and name.
|
||||
|
||||
NOTE:
|
||||
For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` environment variable
|
||||
For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` variable
|
||||
to override the default chart values by setting `HELM_UPGRADE_EXTRA_ARGS` to `--values <my-values.yaml>`.
|
||||
|
||||
## Customize the `helm upgrade` command
|
||||
|
||||
You can customize the `helm upgrade` command used in the [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image)
|
||||
by passing options to the command with the `HELM_UPGRADE_EXTRA_ARGS` variable.
|
||||
by passing options to the command with the `HELM_UPGRADE_EXTRA_ARGS` CI/CD variable.
|
||||
For example, set the value of `HELM_UPGRADE_EXTRA_ARGS` to `--no-hooks` to disable
|
||||
pre-upgrade and post-upgrade hooks when the command is executed.
|
||||
|
||||
|
@ -170,7 +170,7 @@ list of options.
|
|||
|
||||
## Custom Helm chart per environment
|
||||
|
||||
You can specify the use of a custom Helm chart per environment by scoping the environment variable
|
||||
You can specify the use of a custom Helm chart per environment by scoping the CI/CD variable
|
||||
to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables).
|
||||
|
||||
## Customizing `.gitlab-ci.yml`
|
||||
|
@ -260,7 +260,7 @@ the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12
|
|||
To support applications requiring a database,
|
||||
[PostgreSQL](https://www.postgresql.org/) is provisioned by default. The credentials to access
|
||||
the database are preconfigured, but can be customized by setting the associated
|
||||
[variables](#environment-variables). You can use these credentials to define a `DATABASE_URL`:
|
||||
[CI/CD variables](#cicd-variables). You can use these credentials to define a `DATABASE_URL`:
|
||||
|
||||
```yaml
|
||||
postgres://user:password@postgres-host:postgres-port/postgres-database
|
||||
|
@ -269,7 +269,7 @@ postgres://user:password@postgres-host:postgres-port/postgres-database
|
|||
### Upgrading PostgresSQL
|
||||
|
||||
WARNING:
|
||||
The variable `AUTO_DEVOPS_POSTGRES_CHANNEL` that controls default provisioned
|
||||
The CI/CD variable `AUTO_DEVOPS_POSTGRES_CHANNEL` that controls default provisioned
|
||||
PostgreSQL was changed to `2` in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/210499).
|
||||
To keep using the old PostgreSQL, set the `AUTO_DEVOPS_POSTGRES_CHANNEL` variable to
|
||||
`1`.
|
||||
|
@ -290,17 +290,17 @@ production environments, for some use cases, it may not be sufficiently secure o
|
|||
resilient, and you may want to use an external managed provider (such as
|
||||
AWS Relational Database Service) for PostgreSQL.
|
||||
|
||||
You must define environment-scoped variables for `POSTGRES_ENABLED` and
|
||||
You must define environment-scoped CI/CD variables for `POSTGRES_ENABLED` and
|
||||
`DATABASE_URL` in your project's CI/CD settings:
|
||||
|
||||
1. Disable the built-in PostgreSQL installation for the required environments using
|
||||
scoped [environment variables](../../ci/environments/index.md#scoping-environments-with-specs).
|
||||
environment-scoped [CI/CD variables](../../ci/environments/index.md#scoping-environments-with-specs).
|
||||
For this use case, it's likely that only `production` must be added to this
|
||||
list. The built-in PostgreSQL setup for Review Apps and staging is sufficient.
|
||||
|
||||
![Auto Metrics](img/disable_postgres.png)
|
||||
|
||||
1. Define the `DATABASE_URL` CI variable as a scoped environment variable that is
|
||||
1. Define the `DATABASE_URL` variable as an environment-scoped variable that is
|
||||
available to your application. This should be a URL in the following format:
|
||||
|
||||
```yaml
|
||||
|
@ -310,7 +310,7 @@ You must define environment-scoped variables for `POSTGRES_ENABLED` and
|
|||
You must ensure that your Kubernetes cluster has network access to wherever
|
||||
PostgreSQL is hosted.
|
||||
|
||||
## Environment variables
|
||||
## CI/CD variables
|
||||
|
||||
The following variables can be used for setting up the Auto DevOps domain,
|
||||
providing a custom Helm chart, or scaling your application. PostgreSQL can
|
||||
|
@ -318,10 +318,10 @@ also be customized, and you can use a [custom buildpack](#custom-buildpacks).
|
|||
|
||||
### Build and deployment
|
||||
|
||||
The following table lists variables related to building and deploying
|
||||
The following table lists CI/CD variables related to building and deploying
|
||||
applications.
|
||||
|
||||
| **Variable** | **Description** |
|
||||
| **CI/CD Variable** | **Description** |
|
||||
|-----------------------------------------|------------------------------------|
|
||||
| `ADDITIONAL_HOSTS` | Fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. |
|
||||
| `<ENVIRONMENT>_ADDITIONAL_HOSTS` | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. |
|
||||
|
@ -329,7 +329,7 @@ applications.
|
|||
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` | When set to a non-empty value and no `Dockerfile` is present, Auto Build builds your application using Cloud Native Buildpacks instead of Herokuish. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
|
||||
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` | The builder used when building with Cloud Native Buildpacks. The default builder is `heroku/buildpacks:18`. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
|
||||
| `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` | Extra arguments to be passed to the `docker build` command. Note that using quotes doesn't prevent word splitting. [More details](#passing-arguments-to-docker-build). |
|
||||
| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#forward-ci-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
|
||||
| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI/CD variable names](#forward-cicd-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
|
||||
| `AUTO_DEVOPS_CHART` | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app). |
|
||||
| `AUTO_DEVOPS_CHART_REPOSITORY` | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. |
|
||||
| `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. |
|
||||
|
@ -367,9 +367,9 @@ Auto DevOps can undo your changes.
|
|||
|
||||
### Database
|
||||
|
||||
The following table lists variables related to the database.
|
||||
The following table lists CI/CD variables related to the database.
|
||||
|
||||
| **Variable** | **Description** |
|
||||
| **CI/CD Variable** | **Description** |
|
||||
|-----------------------------------------|------------------------------------|
|
||||
| `DB_INITIALIZE` | From GitLab 11.4, used to specify the command to run to initialize the application's PostgreSQL database. Runs inside the application pod. |
|
||||
| `DB_MIGRATE` | From GitLab 11.4, used to specify the command to run to migrate the application's PostgreSQL database. Runs inside the application pod. |
|
||||
|
@ -383,7 +383,7 @@ The following table lists variables related to the database.
|
|||
|
||||
The following table lists variables used to disable jobs.
|
||||
|
||||
| **Job Name** | **Variable** | **GitLab version** | **Description** |
|
||||
| **Job Name** | **CI/CDVariable** | **GitLab version** | **Description** |
|
||||
|----------------------------------------|---------------------------------|-----------------------|-----------------|
|
||||
| `.fuzz_base` | `COVFUZZ_DISABLED` | [From GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34984) | [Read more](../../user/application_security/coverage_fuzzing/) about how `.fuzz_base` provide capability for your own jobs. If the variable is present, your jobs aren't created. |
|
||||
| `apifuzzer_fuzz` | `API_FUZZING_DISABLED` | [From GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39135) | If the variable is present, the job isn't created. |
|
||||
|
@ -433,7 +433,7 @@ The following table lists variables used to disable jobs.
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) in GitLab 11.7.
|
||||
|
||||
Some applications need to define secret variables that are accessible by the deployed
|
||||
application. Auto DevOps detects variables starting with `K8S_SECRET_`, and makes
|
||||
application. Auto DevOps detects CI/CD variables starting with `K8S_SECRET_`, and makes
|
||||
these prefixed variables available to the deployed application as environment variables.
|
||||
|
||||
To configure your application variables:
|
||||
|
@ -545,7 +545,7 @@ The normal behavior of Auto DevOps is to use continuous deployment, pushing
|
|||
automatically to the `production` environment every time a new pipeline is run
|
||||
on the default branch. However, there are cases where you might want to use a
|
||||
staging environment, and deploy to production manually. For this scenario, the
|
||||
`STAGING_ENABLED` environment variable was introduced.
|
||||
`STAGING_ENABLED` CI/CD variable was introduced.
|
||||
|
||||
If you define `STAGING_ENABLED` with a non-empty value, then GitLab automatically deploys the application
|
||||
to a `staging` environment, and creates a `production_manual` job for
|
||||
|
@ -584,7 +584,7 @@ are created:
|
|||
1. `rollout 50%`
|
||||
1. `rollout 100%`
|
||||
|
||||
The percentage is based on the `REPLICAS` variable, and defines the number of
|
||||
The percentage is based on the `REPLICAS` CI/CD variable, and defines the number of
|
||||
pods you want to have for your deployment. If the value is `10`, and you run the
|
||||
`10%` rollout job, there is `1` new pod and `9` old ones.
|
||||
|
||||
|
@ -616,8 +616,8 @@ With `INCREMENTAL_ROLLOUT_MODE` set to `manual` and with `STAGING_ENABLED`
|
|||
![Rollout and staging enabled](img/rollout_staging_enabled.png)
|
||||
|
||||
WARNING:
|
||||
Before GitLab 11.4, the presence of the `INCREMENTAL_ROLLOUT_ENABLED` environment
|
||||
variable enabled this feature. This configuration is deprecated, and is scheduled to be
|
||||
Before GitLab 11.4, the presence of the `INCREMENTAL_ROLLOUT_ENABLED` CI/CD variable
|
||||
enabled this feature. This configuration is deprecated, and is scheduled to be
|
||||
removed in the future.
|
||||
|
||||
### Timed incremental rollout to production **(PREMIUM)**
|
||||
|
@ -632,7 +632,7 @@ This configuration is based on
|
|||
|
||||
Everything behaves the same way, except:
|
||||
|
||||
- To enable it, set the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.
|
||||
- To enable it, set the `INCREMENTAL_ROLLOUT_MODE` CI/CD variable to `timed`.
|
||||
- Instead of the standard `production` job, the following jobs are created with
|
||||
a 5 minute delay between each:
|
||||
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
Before Width: | Height: | Size: 39 KiB |
|
@ -31,25 +31,12 @@ management of processes, and faster creation of new projects: push your code,
|
|||
and GitLab does the rest, improving your productivity and efficiency.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4).
|
||||
For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4) or see this [overview](https://about.gitlab.com/stages-devops-lifecycle/auto-devops/).
|
||||
|
||||
For requirements, read [Requirements for Auto DevOps](requirements.md) for more information.
|
||||
|
||||
For a developer's guide, read [Auto DevOps development guide](../../development/auto_devops.md).
|
||||
|
||||
### Share your feedback
|
||||
|
||||
As Auto DevOps continues to gain popularity, and lowers the barrier to entry for
|
||||
getting started with DevOps and CI/CD, see what our wider community is saying:
|
||||
|
||||
From [AlexJonesax](https://twitter.com/AlexJonesax) and [KaiPMDH](https://twitter.com/KaiPMDH) on Twitter:
|
||||
|
||||
![Alex on Twitter: Auto DevOps in GitLab doesn't just lower the bar to entry, it removes the bar and holds your hand.](img/alexj_autodevops_min_v13_8.png)
|
||||
|
||||
![Kai on Twitter: When I saw this on the Auto DevOps stuff, my mind was blown...](img/kai_autodevops_min_v13_8.png)
|
||||
|
||||
We welcome everyone to [share your experience by tagging GitLab on Twitter](https://twitter.com/gitlab).
|
||||
|
||||
## Enabled by default
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3.
|
||||
|
|
|
@ -234,8 +234,8 @@ takes you to the pod's logs page.
|
|||
|
||||
NOTE:
|
||||
The example shows only one pod hosting the application at the moment, but you can add
|
||||
more pods by defining the [`REPLICAS` variable](customize.md#environment-variables)
|
||||
in **Settings > CI/CD > Environment variables**.
|
||||
more pods by defining the [`REPLICAS` CI/CD variable](customize.md#cicd-variables)
|
||||
in **Settings > CI / CD > Variables**.
|
||||
|
||||
### Work with branches
|
||||
|
||||
|
@ -307,7 +307,7 @@ and customized to fit your workflow. Here are some helpful resources for further
|
|||
1. [Auto DevOps](index.md)
|
||||
1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters)
|
||||
1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) **(PREMIUM)**
|
||||
1. [Disable jobs you don't need with environment variables](customize.md#environment-variables)
|
||||
1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables)
|
||||
1. [Use a static IP for your cluster](../../user/clusters/applications.md#using-a-static-ip)
|
||||
1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks)
|
||||
1. [Prometheus monitoring](../../user/project/integrations/prometheus.md)
|
||||
|
|
|
@ -109,8 +109,8 @@ After all requirements are met, you can [enable Auto DevOps](index.md#enablingdi
|
|||
|
||||
You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.
|
||||
|
||||
To get started on Auto DevOps to AWS ECS, you must add a specific Environment
|
||||
Variable. To do so, follow these steps:
|
||||
To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable.
|
||||
To do so, follow these steps:
|
||||
|
||||
1. In your project, go to **Settings > CI / CD** and expand the **Variables**
|
||||
section.
|
||||
|
@ -121,7 +121,7 @@ Variable. To do so, follow these steps:
|
|||
- `ECS` if you're not enforcing any launch type check when deploying to ECS.
|
||||
|
||||
When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
|
||||
[entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
|
||||
[entered AWS credentials as variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
|
||||
your application is deployed to AWS ECS.
|
||||
|
||||
[GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS.
|
||||
|
@ -145,7 +145,7 @@ own pipeline, as the override stops working when the name changes.
|
|||
|
||||
You can target [AWS EC2](../../ci/cloud_deployment/index.md)
|
||||
as a deployment platform instead of Kubernetes. To use Auto DevOps with AWS EC2, you must add a
|
||||
specific environment variable.
|
||||
specific CI/CD variable.
|
||||
|
||||
For more details, see [Custom build job for Auto DevOps](../../ci/cloud_deployment/index.md#custom-build-job-for-auto-devops)
|
||||
for deployments to AWS EC2.
|
||||
|
|
|
@ -53,7 +53,7 @@ For the requirements of other languages and frameworks, read the
|
|||
|
||||
NOTE:
|
||||
If Auto Build fails despite the project meeting the buildpack requirements, set
|
||||
a project variable `TRACE=true` to enable verbose logging, which may help you
|
||||
a project CI/CD variable `TRACE=true` to enable verbose logging, which may help you
|
||||
troubleshoot.
|
||||
|
||||
### Auto Build using Cloud Native Buildpacks (beta)
|
||||
|
@ -62,9 +62,9 @@ troubleshoot.
|
|||
|
||||
Auto Build supports building your application using [Cloud Native Buildpacks](https://buildpacks.io)
|
||||
through the [`pack` command](https://github.com/buildpacks/pack). To use Cloud Native Buildpacks,
|
||||
set the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
|
||||
set the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
|
||||
value. The default builder is `heroku/buildpacks:18` but a different builder
|
||||
can be selected using the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
|
||||
can be selected using the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
|
||||
|
||||
Cloud Native Buildpacks (CNBs) are an evolution of Heroku buildpacks, and
|
||||
GitLab expects them to eventually supersede Herokuish-based builds within Auto DevOps. For more
|
||||
|
@ -103,7 +103,9 @@ NOTE:
|
|||
Not all buildpacks supported by [Auto Build](#auto-build) are supported by Auto Test.
|
||||
Auto Test uses [Herokuish](https://gitlab.com/gitlab-org/gitlab/-/issues/212689), *not*
|
||||
Cloud Native Buildpacks, and only buildpacks that implement the
|
||||
<!-- vale gitlab.Spelling = NO -->
|
||||
[Testpack API](https://devcenter.heroku.com/articles/testpack-api) are supported.
|
||||
<!-- vale gitlab.Spelling = YES -->
|
||||
|
||||
### Currently supported languages
|
||||
|
||||
|
@ -284,7 +286,7 @@ see the documentation.
|
|||
### Overriding the DAST target
|
||||
|
||||
To use a custom target instead of the auto-deployed review apps,
|
||||
set a `DAST_WEBSITE` environment variable to the URL for DAST to scan.
|
||||
set a `DAST_WEBSITE` CI/CD variable to the URL for DAST to scan.
|
||||
|
||||
WARNING:
|
||||
If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is
|
||||
|
@ -297,10 +299,10 @@ data loss or corruption.
|
|||
|
||||
You can disable DAST:
|
||||
|
||||
- On all branches by setting the `DAST_DISABLED` environment variable to `"true"`.
|
||||
- On all branches by setting the `DAST_DISABLED` CI/CD variable to `"true"`.
|
||||
- Only on the default branch by setting the `DAST_DISABLED_FOR_DEFAULT_BRANCH`
|
||||
environment variable to `"true"`.
|
||||
- Only on feature branches by setting `REVIEW_DISABLED` environment variable to
|
||||
variable to `"true"`.
|
||||
- Only on feature branches by setting `REVIEW_DISABLED` variable to
|
||||
`"true"`. This also disables the Review App.
|
||||
|
||||
## Auto Browser Performance Testing **(PREMIUM)**
|
||||
|
@ -336,7 +338,7 @@ uploads the report as an artifact.
|
|||
|
||||
Some initial setup is required. A [k6](https://k6.io/) test needs to be
|
||||
written that's tailored to your specific application. The test also needs to be
|
||||
configured so it can pick up the environment's dynamic URL via an environment variable.
|
||||
configured so it can pick up the environment's dynamic URL via a CI/CD variable.
|
||||
|
||||
Any load performance test result differences between the source and target branches are also
|
||||
[shown in the merge request widget](../../user/project/merge_requests/load_performance_testing.md).
|
||||
|
@ -356,7 +358,7 @@ default, but the
|
|||
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
|
||||
contains job definitions for these tasks if you want to enable them.
|
||||
|
||||
You can use [environment variables](customize.md#environment-variables) to automatically
|
||||
You can use [CI/CD variables](customize.md#cicd-variables) to automatically
|
||||
scale your pod replicas, and to apply custom arguments to the Auto DevOps `helm upgrade`
|
||||
commands. This is an easy way to
|
||||
[customize the Auto Deploy Helm chart](customize.md#custom-helm-chart).
|
||||
|
@ -440,7 +442,7 @@ On GitLab 12.9 and 12.10, opting into
|
|||
`AUTO_DEVOPS_POSTGRES_CHANNEL` version `2` deletes the version `1` PostgreSQL
|
||||
database. Follow the [guide to upgrading PostgreSQL](upgrading_postgresql.md)
|
||||
to back up and restore your database before opting into version `2` (On
|
||||
GitLab 13.0, an additional variable is required to trigger the database
|
||||
GitLab 13.0, an additional CI/CD variable is required to trigger the database
|
||||
deletion).
|
||||
|
||||
### Migrations
|
||||
|
@ -448,7 +450,7 @@ deletion).
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21955) in GitLab 11.4
|
||||
|
||||
You can configure database initialization and migrations for PostgreSQL to run
|
||||
within the application pod by setting the project variables `DB_INITIALIZE` and
|
||||
within the application pod by setting the project CI/CD variables `DB_INITIALIZE` and
|
||||
`DB_MIGRATE` respectively.
|
||||
|
||||
If present, `DB_INITIALIZE` is run as a shell command within an application pod
|
||||
|
@ -500,7 +502,7 @@ access to a Redis instance. Auto DevOps doesn't deploy this instance for you, so
|
|||
you must:
|
||||
|
||||
- Maintain your own Redis instance.
|
||||
- Set a CI variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
|
||||
- Set a CI/CD variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
|
||||
to ensure it's passed into your deployments.
|
||||
|
||||
After configuring your worker to respond to health checks, run a Sidekiq
|
||||
|
@ -686,5 +688,5 @@ You can follow the [code intelligence epic](https://gitlab.com/groups/gitlab-org
|
|||
for updates.
|
||||
|
||||
This stage is enabled by default. You can disable it by adding the
|
||||
`CODE_INTELLIGENCE_DISABLED` environment variable. Read more about
|
||||
`CODE_INTELLIGENCE_DISABLED` CI/CD variable. Read more about
|
||||
[disabling Auto DevOps jobs](../../topics/autodevops/customize.md#disable-jobs).
|
||||
|
|
|
@ -114,7 +114,7 @@ If your Auto DevOps project has an active environment that was deployed with the
|
|||
job saves a backup for 1 week in a job artifact called `helm-2-release-backups`.
|
||||
The backup is in a Kubernetes manifest file that can be restored using
|
||||
`kubectl apply -f $backup`.
|
||||
1. Remove the `MIGRATE_HELM_2TO3` variable.
|
||||
1. Remove the `MIGRATE_HELM_2TO3` CI/CD variable.
|
||||
|
||||
#### In-Cluster PostgreSQL Channel 2
|
||||
|
||||
|
@ -145,11 +145,11 @@ steps to upgrade to v2:
|
|||
them to `production` first to delete the unstable tracks.
|
||||
1. Verify your project is [using the v2 `auto-deploy-image`](#verify-dependency-versions).
|
||||
If not, [specify the version](#use-a-specific-version-of-auto-deploy-dependencies).
|
||||
1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable with a value of `true`
|
||||
1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` CI/CD variable with a value of `true`
|
||||
in the GitLab CI/CD settings.
|
||||
1. Create a new pipeline and run the `production` job to renew the resource architecture
|
||||
with the v2 `auto-deploy-app chart`.
|
||||
1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable.
|
||||
1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` variable.
|
||||
|
||||
### Use a specific version of Auto Deploy dependencies
|
||||
|
||||
|
@ -167,7 +167,7 @@ include:
|
|||
### Ignore warnings and continue deploying
|
||||
|
||||
If you are certain that the new chart version is safe to be deployed, you can add
|
||||
the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [environment variable](customize.md#build-and-deployment)
|
||||
the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [CI/CD variable](customize.md#build-and-deployment)
|
||||
to force the deployment to continue.
|
||||
|
||||
For example, if you want to deploy the `v2.0.0` chart on a deployment that previously
|
||||
|
|
|
@ -203,7 +203,7 @@ sort order is by **Last created**.
|
|||
To search for groups by name, enter your criteria in the search field. The group search is case
|
||||
insensitive, and applies partial matching.
|
||||
|
||||
To [Create a new group](../group/index.md#create-a-new-group) click **New group**.
|
||||
To [Create a new group](../group/index.md#create-a-group) click **New group**.
|
||||
|
||||
### Administering Jobs
|
||||
|
||||
|
|
|
@ -175,7 +175,7 @@ lock files. Python projects can have lock files, but GitLab Secure tools don't s
|
|||
## Security scans using Auto DevOps
|
||||
|
||||
When using [Auto DevOps](../../../topics/autodevops/index.md), use
|
||||
[special environment variables](../../../topics/autodevops/customize.md#environment-variables)
|
||||
[special environment variables](../../../topics/autodevops/customize.md#cicd-variables)
|
||||
to configure daily security scans.
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
|
|
@ -372,7 +372,7 @@ For GitLab Runner to function, you _must_ specify the following:
|
|||
- `runnerRegistrationToken`: The registration token for adding new runners to GitLab.
|
||||
This must be [retrieved from your GitLab instance](../../ci/runners/README.md).
|
||||
|
||||
These values can be specified using [CI variables](../../ci/variables/README.md):
|
||||
These values can be specified using [CI/CD variables](../../ci/variables/README.md):
|
||||
|
||||
- `GITLAB_RUNNER_GITLAB_URL` is used for `gitlabUrl`.
|
||||
- `GITLAB_RUNNER_REGISTRATION_TOKEN` is used for `runnerRegistrationToken`
|
||||
|
@ -730,7 +730,7 @@ Set:
|
|||
- "Redirect URI" to `http://<JupyterHub Host>/hub/oauth_callback`.
|
||||
- "Scope" to `api read_repository write_repository`.
|
||||
|
||||
In addition, the following variables must be specified using [CI variables](../../ci/variables/README.md):
|
||||
In addition, the following variables must be specified using [CI/CD variables](../../ci/variables/README.md):
|
||||
|
||||
- `JUPYTERHUB_PROXY_SECRET_TOKEN` - Secure string used for signing communications
|
||||
from the hub. Read [`proxy.secretToken`](https://zero-to-jupyterhub.readthedocs.io/en/stable/reference/reference.html#proxy-secrettoken).
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 60 KiB |
|
@ -7,54 +7,34 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Groups
|
||||
|
||||
With GitLab Groups, you can:
|
||||
In GitLab, you can put related projects together in a group.
|
||||
|
||||
- Assemble related projects together.
|
||||
- Grant members access to several projects at once.
|
||||
For example, you might create a group for your company members and a subgroup for each individual team.
|
||||
You can name the group `company-team`, and the subgroups `backend-team`, `frontend-team`, and `production-team`.
|
||||
|
||||
For a video introduction to GitLab Groups, see [GitLab University: Repositories, Projects and Groups](https://www.youtube.com/watch?v=4TWfh1aKHHw).
|
||||
Then you can:
|
||||
|
||||
Groups can also be nested in [subgroups](subgroups/index.md).
|
||||
- Grant members access to multiple projects at once.
|
||||
- Add to-do items for all of the group members at once.
|
||||
- View the [issues](../project/issues/index.md#issues-list) and
|
||||
[merge requests](../project/merge_requests/reviewing_and_managing_merge_requests.md#view-merge-requests-for-all-projects-in-a-group)
|
||||
for all projects in the group, together in a single list view.
|
||||
- [Bulk edit](../group/bulk_editing/index.md) issues, epics, and merge requests.
|
||||
|
||||
Find your groups by clicking **Groups > Your Groups** in the top navigation.
|
||||
You can also create [subgroups](subgroups/index.md).
|
||||
|
||||
![GitLab Groups](img/groups.png)
|
||||
## View groups
|
||||
|
||||
> The **Groups** dropdown in the top navigation was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/36234) in [GitLab 11.1](https://about.gitlab.com/releases/2018/07/22/gitlab-11-1-released/#groups-dropdown-in-navigation).
|
||||
To view groups:
|
||||
|
||||
The **Groups** page displays:
|
||||
1. In the top menu, select **Groups > Your Groups**. All groups you are a member of are displayed.
|
||||
1. To view a list of public groups, select **Explore public groups**.
|
||||
|
||||
- All groups you are a member of, when **Your groups** is selected.
|
||||
- A list of public groups, when **Explore public groups** is selected.
|
||||
You can also view groups by namespace.
|
||||
|
||||
Each group on the **Groups** page is listed with:
|
||||
### Namespaces
|
||||
|
||||
- How many subgroups it has.
|
||||
- How many projects it contains.
|
||||
- How many members the group has, not including members inherited from parent group(s).
|
||||
- The group's visibility.
|
||||
- A link to the group's settings, if you have sufficient permissions.
|
||||
- A link to leave the group, if you are a member.
|
||||
|
||||
## Use cases
|
||||
|
||||
You can create groups for numerous reasons. To name a couple:
|
||||
|
||||
- Grant access to multiple projects and multiple team members in fewer steps by organizing related projects under the same [namespace](#namespaces) and adding members to the top-level group.
|
||||
- Make it easier to `@mention` all of your team at once in issues and merge requests by creating a group and including the appropriate members.
|
||||
|
||||
For example, you could create a group for your company members, and create a [subgroup](subgroups/index.md) for each individual team. Let's say you create a group called `company-team`, and you create subgroups in this group for the individual teams `backend-team`, `frontend-team`, and `production-team`.
|
||||
|
||||
- When you start a new implementation from an issue, you add a comment:
|
||||
_"`@company-team`, let's do it! `@company-team/backend-team` you're good to go!"_
|
||||
- When your backend team needs help from frontend, they add a comment:
|
||||
_"`@company-team/frontend-team` could you help us here please?"_
|
||||
- When the frontend team completes their implementation, they comment:
|
||||
_"`@company-team/backend-team`, it's done! Let's ship it `@company-team/production-team`!"_
|
||||
|
||||
## Namespaces
|
||||
|
||||
In GitLab, a namespace is a unique name to be used as a user name, a group name, or a subgroup name.
|
||||
In GitLab, a namespace is a unique name and URL for a user, a group, or subgroup.
|
||||
|
||||
- `http://gitlab.example.com/username`
|
||||
- `http://gitlab.example.com/groupname`
|
||||
|
@ -62,35 +42,19 @@ In GitLab, a namespace is a unique name to be used as a user name, a group name,
|
|||
|
||||
For example, consider a user named Alex:
|
||||
|
||||
1. Alex creates an account on GitLab.com with the username `alex`;
|
||||
their profile will be accessed under `https://gitlab.example.com/alex`
|
||||
1. Alex creates a group for their team with the group name `alex-team`;
|
||||
the group and its projects will be accessed under `https://gitlab.example.com/alex-team`
|
||||
1. Alex creates a subgroup of `alex-team` with the subgroup name `marketing`;
|
||||
this subgroup and its projects will be accessed under `https://gitlab.example.com/alex-team/marketing`
|
||||
1. Alex creates an account with the username `alex`: `https://gitlab.example.com/alex`
|
||||
1. Alex creates a group for their team with the group name `alex-team`.
|
||||
The group and its projects are available at: `https://gitlab.example.com/alex-team`
|
||||
1. Alex creates a subgroup of `alex-team` with the subgroup name `marketing`.
|
||||
The subgroup and its projects are available at: `https://gitlab.example.com/alex-team/marketing`
|
||||
|
||||
By doing so:
|
||||
## Create a group
|
||||
|
||||
- Any team member mentions Alex with `@alex`
|
||||
- Alex mentions everyone from their team with `@alex-team`
|
||||
- Alex mentions only the marketing team with `@alex-team/marketing`
|
||||
NOTE:
|
||||
For a list of words that can not be used as group names, see
|
||||
[reserved names](../reserved_names.md).
|
||||
|
||||
## Issues and merge requests within a group
|
||||
|
||||
Issues and merge requests are part of projects. For a given group, you can view all of the
|
||||
[issues](../project/issues/index.md#issues-list) and [merge requests](../project/merge_requests/reviewing_and_managing_merge_requests.md#view-merge-requests-for-all-projects-in-a-group) across all projects in that group,
|
||||
together in a single list view.
|
||||
|
||||
### Bulk editing issues and merge requests
|
||||
|
||||
For details, see [bulk editing issues and merge requests](../group/bulk_editing/index.md).
|
||||
|
||||
## Create a new group
|
||||
|
||||
> For a list of words that are not allowed to be used as group names see the
|
||||
> [reserved names](../reserved_names.md).
|
||||
|
||||
To create a new Group, either:
|
||||
To create a new group, either:
|
||||
|
||||
- In the top menu, click **Groups** and then **Your Groups**, and click the green button **New group**.
|
||||
|
||||
|
@ -166,7 +130,7 @@ If you change your mind before your request is approved, just click the
|
|||
|
||||
![Withdraw access request button](img/withdraw_access_request_button.png)
|
||||
|
||||
## Changing the owner of a group
|
||||
## Change the owner of a group
|
||||
|
||||
Ownership of a group means at least one of its members has
|
||||
[Owner permission](../permissions.md#group-members-permissions). Groups must have at
|
||||
|
@ -266,6 +230,18 @@ You can sort members by **Account**, **Access granted**, **Max role**, or **Last
|
|||
|
||||
![Group members sort](img/group_members_sort_13_7.png)
|
||||
|
||||
## Mention a group in an issue or merge request
|
||||
|
||||
When you mention a group in a comment, every member of the group gets a to-do item
|
||||
added to their To-do list.
|
||||
|
||||
1. Open the MR or issue.
|
||||
1. In a comment, type `@` followed by the user, group, or subgroup namespace.
|
||||
For example, `@alex`, `@alex-team`, or `@alex-team/marketing`.
|
||||
1. Select **Comment**.
|
||||
|
||||
A to-do item is created for all the group and subgroup members.
|
||||
|
||||
## Changing the default branch protection of a group
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7583) in GitLab 12.9.
|
||||
|
@ -520,7 +496,7 @@ the group's dashboard, and clicking **Settings**.
|
|||
### General settings
|
||||
|
||||
In addition to editing any settings you previously
|
||||
set when [creating the group](#create-a-new-group), you can also
|
||||
set when [creating the group](#create-a-group), you can also
|
||||
access further configurations for your group.
|
||||
|
||||
#### Changing a group's path
|
||||
|
|
|
@ -326,7 +326,7 @@ If a default Storage Class doesn't already exist and is desired, follow Amazon's
|
|||
to create one.
|
||||
|
||||
Alternatively, disable PostgreSQL by setting the project variable
|
||||
[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#environment-variables) to `false`.
|
||||
[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#cicd-variables) to `false`.
|
||||
|
||||
### Deploy the app to EKS
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ applications through GMAv2 exclusively when using Container Network Security.
|
|||
The following steps are recommended to install and use Container Host Security through GitLab:
|
||||
|
||||
1. [Install at least one runner and connect it to GitLab](https://docs.gitlab.com/runner/).
|
||||
1. [Create a group](../../../../group/#create-a-new-group).
|
||||
1. [Create a group](../../../../group/#create-a-group).
|
||||
1. [Connect a Kubernetes cluster to the group](../../add_remove_clusters.md).
|
||||
1. [Create a cluster management project and associate it with the Kubernetes cluster](../../../../clusters/management_project.md).
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ applications through GMAv2 exclusively when using Container Network Security.
|
|||
The following steps are recommended to install and use Container Network Security through GitLab:
|
||||
|
||||
1. [Install at least one runner and connect it to GitLab](https://docs.gitlab.com/runner/).
|
||||
1. [Create a group](../../../../group/#create-a-new-group).
|
||||
1. [Create a group](../../../../group/#create-a-group).
|
||||
1. [Connect a Kubernetes cluster to the group](../../add_remove_clusters.md).
|
||||
1. [Create a cluster management project and associate it with the Kubernetes cluster](../../../../clusters/management_project.md).
|
||||
|
||||
|
|
|
@ -122,13 +122,15 @@ Requesting a code review is an important part of contributing code. However, dec
|
|||
your code and asking for a review are no easy tasks. Using the "assignee" field for both authors and
|
||||
reviewers makes it hard for others to determine who's doing what on a merge request.
|
||||
|
||||
GitLab Merge Request Reviewers easily allow authors to request a review as well as see the status of the
|
||||
review. By selecting one or more users from the **Reviewers** field in the merge request's right-hand
|
||||
sidebar, the assigned reviewers will receive a notification of the request to review the merge request.
|
||||
GitLab Merge Request Reviewers enable you to request a review of your work, and
|
||||
see the status of the review. Reviewers help distinguish the roles of the users
|
||||
involved in the merge request. In comparison to an **Assignee**, who is directly
|
||||
responsible for creating or merging a merge request, a **Reviewer** is a team member
|
||||
who may only be involved in one aspect of the merge request, such as a peer review.
|
||||
|
||||
This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer.
|
||||
|
||||
To request it, open the **Reviewers** drop-down box to search for the user you wish to get a review from.
|
||||
To request a review of a merge request, expand the **Reviewers** select box in
|
||||
the right-hand sidebar. Search for the users you want to request a review from.
|
||||
When selected, GitLab creates a [to-do list item](../../todos.md) for each reviewer.
|
||||
|
||||
#### Approval Rule information for Reviewers **(PREMIUM)**
|
||||
|
||||
|
|
|
@ -138,14 +138,14 @@ to push or merge code to any branches.
|
|||
|
||||
To enable this access:
|
||||
|
||||
1. [Create a new group](../../group/index.md#create-a-new-group), and then
|
||||
1. [Create a new group](../../group/index.md#create-a-group), and then
|
||||
[add the user to the group](../../group/index.md#add-users-to-a-group),
|
||||
ensuring you select the Reporter role for the user.
|
||||
1. [Share the project with your group](../members/share_project_with_groups.md#sharing-a-project-with-a-group-of-users),
|
||||
based on the Reporter role.
|
||||
1. Navigate to your project's **Settings > General**, and in the
|
||||
**Merge request approvals** section, click **Expand**.
|
||||
1. [Add the group](../../group/index.md#create-a-new-group) to the permission list
|
||||
1. [Add the group](../../group/index.md#create-a-group) to the permission list
|
||||
for the protected branch.
|
||||
|
||||
![Update approval rule](img/update_approval_rule_v13_4.png)
|
||||
|
|
|
@ -20655,6 +20655,9 @@ msgstr ""
|
|||
msgid "OnCallSchedules|Create on-call schedules in GitLab"
|
||||
msgstr ""
|
||||
|
||||
msgid "OnCallSchedules|Currently no rotation."
|
||||
msgstr ""
|
||||
|
||||
msgid "OnCallSchedules|Delete rotation"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
@ -43,6 +43,10 @@ module QA
|
|||
element :focus_mode_button
|
||||
end
|
||||
|
||||
view 'app/assets/javascripts/boards/components/config_toggle.vue' do
|
||||
element :boards_config_button
|
||||
end
|
||||
|
||||
# The `focused_board` method does not use `find_element` with an element defined
|
||||
# with the attribute `data-qa-selector` since such element is not unique when the
|
||||
# `is-focused` class is not set, and it was not possible to find a better solution.
|
||||
|
@ -82,6 +86,10 @@ module QA
|
|||
end
|
||||
end
|
||||
|
||||
def click_boards_config_button
|
||||
click_element(:boards_config_button)
|
||||
end
|
||||
|
||||
def click_boards_dropdown_button
|
||||
# The dropdown button comes from the `GlDropdown` component of `@gitlab/ui`,
|
||||
# so it wasn't possible to add a `data-qa-selector` to it.
|
||||
|
|
|
@ -27,6 +27,7 @@ Migration/UpdateLargeTable:
|
|||
- :project_ci_cd_settings
|
||||
- :project_settings
|
||||
- :project_features
|
||||
- :protected_branches
|
||||
- :push_event_payloads
|
||||
- :resource_label_events
|
||||
- :routes
|
||||
|
|
|
@ -0,0 +1,57 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
RSpec.describe Mutations::Boards::Update do
|
||||
let_it_be(:project) { create(:project) }
|
||||
let_it_be(:user) { create(:user) }
|
||||
let_it_be(:board) { create(:board, project: project) }
|
||||
|
||||
let(:mutation) { described_class.new(object: nil, context: { current_user: user }, field: nil) }
|
||||
let(:mutated_board) { subject[:board] }
|
||||
|
||||
let(:mutation_params) do
|
||||
{
|
||||
id: board.to_global_id,
|
||||
hide_backlog_list: true,
|
||||
hide_closed_list: false
|
||||
}
|
||||
end
|
||||
|
||||
subject { mutation.resolve(**mutation_params) }
|
||||
|
||||
specify { expect(described_class).to require_graphql_authorizations(:admin_board) }
|
||||
|
||||
describe '#resolve' do
|
||||
context 'when the user cannot admin the board' do
|
||||
it 'raises an error' do
|
||||
expect { subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
|
||||
end
|
||||
end
|
||||
|
||||
context 'with invalid params' do
|
||||
it 'raises an error' do
|
||||
mutation_params[:id] = project.to_global_id
|
||||
|
||||
expect { subject }.to raise_error(::GraphQL::CoercionError)
|
||||
end
|
||||
end
|
||||
|
||||
context 'when user can update board' do
|
||||
before do
|
||||
board.resource_parent.add_reporter(user)
|
||||
end
|
||||
|
||||
it 'updates board with correct values' do
|
||||
expected_attributes = {
|
||||
hide_backlog_list: true,
|
||||
hide_closed_list: false
|
||||
}
|
||||
|
||||
subject
|
||||
|
||||
expect(board.reload).to have_attributes(expected_attributes)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
|
@ -17,6 +17,19 @@ RSpec.describe List do
|
|||
it { is_expected.to validate_presence_of(:list_type) }
|
||||
end
|
||||
|
||||
describe '.without_types' do
|
||||
it 'exclude lists of given types' do
|
||||
board = create(:list, list_type: :label).board
|
||||
# closed list is created by default
|
||||
backlog_list = create(:list, list_type: :backlog, board: board)
|
||||
|
||||
exclude_type = [described_class.list_types[:label], described_class.list_types[:closed]]
|
||||
|
||||
lists = described_class.without_types(exclude_type)
|
||||
expect(lists.where(board: board)).to match_array([backlog_list])
|
||||
end
|
||||
end
|
||||
|
||||
describe '#update_preferences_for' do
|
||||
let(:user) { create(:user) }
|
||||
let(:list) { create(:list) }
|
||||
|
|
|
@ -8,6 +8,26 @@ RSpec.describe Boards::Lists::ListService do
|
|||
describe '#execute' do
|
||||
let(:service) { described_class.new(parent, user) }
|
||||
|
||||
shared_examples 'hidden lists' do
|
||||
let!(:list) { create(:list, board: board, label: label) }
|
||||
|
||||
context 'when hide_backlog_list is true' do
|
||||
it 'hides backlog list' do
|
||||
board.update!(hide_backlog_list: true)
|
||||
|
||||
expect(service.execute(board)).to match_array([board.closed_list, list])
|
||||
end
|
||||
end
|
||||
|
||||
context 'when hide_closed_list is true' do
|
||||
it 'hides closed list' do
|
||||
board.update!(hide_closed_list: true)
|
||||
|
||||
expect(service.execute(board)).to match_array([board.backlog_list, list])
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when board parent is a project' do
|
||||
let(:project) { create(:project) }
|
||||
let(:board) { create(:board, project: project) }
|
||||
|
@ -16,6 +36,7 @@ RSpec.describe Boards::Lists::ListService do
|
|||
let(:parent) { project }
|
||||
|
||||
it_behaves_like 'lists list service'
|
||||
it_behaves_like 'hidden lists'
|
||||
end
|
||||
|
||||
context 'when board parent is a group' do
|
||||
|
@ -26,6 +47,7 @@ RSpec.describe Boards::Lists::ListService do
|
|||
let(:parent) { group }
|
||||
|
||||
it_behaves_like 'lists list service'
|
||||
it_behaves_like 'hidden lists'
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
Loading…
Reference in New Issue