Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
c47247f7cd
commit
2e3423047a
|
|
@ -5,7 +5,6 @@ module Types
|
|||
# rubocop: disable Graphql/AuthorizeTypes
|
||||
class JobType < BaseObject
|
||||
graphql_name 'CiJob'
|
||||
authorize :read_build
|
||||
|
||||
field :pipeline, Types::Ci::PipelineType, null: true,
|
||||
description: 'Pipeline the job belongs to'
|
||||
|
|
|
|||
|
|
@ -122,12 +122,15 @@ class JiraService < IssueTrackerService
|
|||
end
|
||||
|
||||
def fields
|
||||
transition_id_help_path = help_page_path('user/project/integrations/jira', anchor: 'obtaining-a-transition-id')
|
||||
transition_id_help_link_start = '<a href="%{transition_id_help_path}" target="_blank" rel="noopener noreferrer">'.html_safe % { transition_id_help_path: transition_id_help_path }
|
||||
|
||||
[
|
||||
{ type: 'text', name: 'url', title: s_('JiraService|Web URL'), placeholder: 'https://jira.example.com', required: true },
|
||||
{ type: 'text', name: 'api_url', title: s_('JiraService|Jira API URL'), placeholder: s_('JiraService|If different from Web URL') },
|
||||
{ type: 'text', name: 'username', title: s_('JiraService|Username or Email'), placeholder: s_('JiraService|Use a username for server version and an email for cloud version'), required: true },
|
||||
{ type: 'password', name: 'password', title: s_('JiraService|Password or API token'), placeholder: s_('JiraService|Use a password for server version and an API token for cloud version'), required: true },
|
||||
{ type: 'text', name: 'jira_issue_transition_id', title: s_('JiraService|Transition ID(s)'), placeholder: s_('JiraService|Use , or ; to separate multiple transition IDs') }
|
||||
{ type: 'text', name: 'jira_issue_transition_id', title: s_('JiraService|Jira workflow transition IDs'), placeholder: s_('JiraService|For example, 12, 24'), help: s_('JiraService|Set transition IDs for Jira workflow transitions. %{link_start}Learn more%{link_end}'.html_safe % { link_start: transition_id_help_link_start, link_end: '</a>'.html_safe }) }
|
||||
]
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Resolve Transition ID section should include help text
|
||||
merge_request: 49204
|
||||
author:
|
||||
type: added
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add feed_token specs to spec/features/profiles/personal_access_tokens_spec.rb
|
||||
merge_request: 50059
|
||||
author:
|
||||
type: other
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
name: count_uploads_size_in_storage_stats
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46941
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/281950
|
||||
milestone: '13.6'
|
||||
type: development
|
||||
group: group::project management
|
||||
default_enabled: false
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
# Error: gitlab.InternalLinkCase
|
||||
#
|
||||
# Checks that anchor fragments on internal links are in lower-case.
|
||||
#
|
||||
# For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
|
||||
extends: existence
|
||||
message: 'Links to subheadings in GitLab docs must be in lower-case: "%s"'
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links-to-internal-documentation
|
||||
level: error
|
||||
scope: raw
|
||||
raw:
|
||||
- '[^\`]\[[^\[\]]+\]\((https?:){0}[\w\/\.]*?#[^\s]*?[A-Z][^\) ]*\)[^\`]'
|
||||
|
|
@ -6,9 +6,9 @@
|
|||
# For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
|
||||
extends: existence
|
||||
message: 'Rewrite "%s" to not use "’s".'
|
||||
level: warning
|
||||
level: error
|
||||
ignorecase: true
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#contractions
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#trademark
|
||||
tokens:
|
||||
- GitLab's # Straight apostrophe.
|
||||
- GitLab’s # Curly closing apostrophe.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ No matter how you use GitLab, we have documentation for you.
|
|||
| [**Contributing to GitLab**](#contributing-to-gitlab)<br/>At GitLab, everyone can contribute! | [**New to Git and GitLab?**](#new-to-git-and-gitlab)<br/>We have the resources to get you started. |
|
||||
| [**Build an integration with GitLab**](#build-an-integration-with-gitlab)<br/>Consult our integration documentation. | [**Coming to GitLab from another platform?**](#coming-to-gitlab-from-another-platform)<br/>Consult our guides. |
|
||||
| [**Install GitLab**](https://about.gitlab.com/install/)<br/>Installation options for different platforms. | [**Customers**](subscriptions/index.md)<br/>Information for new and existing customers. |
|
||||
| [**Update GitLab**](update/README.md)<br/>Update your GitLab self-managed instance to the latest version. | [**Reference Architectures**](administration/reference_architectures/index.md)<br/>GitLab's reference architectures |
|
||||
| [**Update GitLab**](update/README.md)<br/>Update your GitLab self-managed instance to the latest version. | [**Reference Architectures**](administration/reference_architectures/index.md)<br/>GitLab reference architectures |
|
||||
| [**GitLab releases**](https://about.gitlab.com/releases/)<br/>What's new in GitLab. | |
|
||||
|
||||
## Popular topics
|
||||
|
|
@ -69,8 +69,8 @@ We have the following documentation to rapidly uplift your GitLab knowledge:
|
|||
| [GitLab basics guides](gitlab-basics/README.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. |
|
||||
| [Get started with GitLab CI/CD](ci/quick_start/README.md) | Quickly implement GitLab CI/CD. |
|
||||
| [Auto DevOps](topics/autodevops/index.md) | Learn more about GitLab's Auto DevOps. |
|
||||
| [GitLab Markdown](user/markdown.md) | GitLab's advanced formatting system (GitLab Flavored Markdown) |
|
||||
| [Auto DevOps](topics/autodevops/index.md) | Learn more about Auto DevOps in GitLab. |
|
||||
| [GitLab Markdown](user/markdown.md) | Advanced formatting system (GitLab Flavored Markdown) |
|
||||
|
||||
### User account
|
||||
|
||||
|
|
|
|||
|
|
@ -254,8 +254,23 @@ The database used by Praefect is now configured.
|
|||
|
||||
To reduce PostgreSQL resource consumption, we recommend setting up and configuring
|
||||
[PgBouncer](https://www.pgbouncer.org/) in front of the PostgreSQL instance. To do
|
||||
this, replace value of the `POSTGRESQL_SERVER_ADDRESS` with corresponding IP or host
|
||||
address of the PgBouncer instance.
|
||||
this, set the corresponding IP or host address of the PgBouncer instance in
|
||||
`/etc/gitlab/gitlab.rb` by changing the following settings:
|
||||
|
||||
- `praefect['database_host']`, for the address.
|
||||
- `praefect['database_port']`, for the port.
|
||||
|
||||
Because PgBouncer manages resources more efficiently, Praefect still requires a
|
||||
direct connection to the PostgreSQL database because it uses
|
||||
[LISTEN](https://www.postgresql.org/docs/11/sql-listen.html)
|
||||
functionality that is [not supported](https://www.pgbouncer.org/features.html) by
|
||||
PgBouncer with `pool_mode = transaction`.
|
||||
|
||||
Therefore, `praefect['database_host_no_proxy']` and `praefect['database_port_no_proxy']`
|
||||
should be set to a direct connection and not a PgBouncer connection.
|
||||
|
||||
Save the changes to `/etc/gitlab/gitlab.rb` and
|
||||
[reconfigure Praefect](../restart_gitlab.md#omnibus-gitlab-reconfigure).
|
||||
|
||||
This documentation doesn't provide PgBouncer installation instructions,
|
||||
but you can:
|
||||
|
|
@ -370,6 +385,8 @@ application server, or a Gitaly node.
|
|||
praefect['database_user'] = 'praefect'
|
||||
praefect['database_password'] = 'PRAEFECT_SQL_PASSWORD'
|
||||
praefect['database_dbname'] = 'praefect_production'
|
||||
praefect['database_host_no_proxy'] = 'POSTGRESQL_SERVER_ADDRESS'
|
||||
praefect['database_port_no_proxy'] = 5432
|
||||
```
|
||||
|
||||
If you want to use a TLS client certificate, the options below can be used:
|
||||
|
|
|
|||
|
|
@ -543,7 +543,7 @@ supported by consolidated configuration form, refer to the following guides:
|
|||
|
||||
|Object storage type|Supported by consolidated configuration?|
|
||||
|-------------------|----------------------------------------|
|
||||
| [Backups](../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
|
||||
| [Backups](../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage) | No |
|
||||
| [Job artifacts](job_artifacts.md#using-object-storage) including archived job logs | Yes |
|
||||
| [LFS objects](lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
|
||||
| [Uploads](uploads.md#using-object-storage) | Yes |
|
||||
|
|
|
|||
|
|
@ -2066,7 +2066,7 @@ on what features you intend to use:
|
|||
|
||||
|Object storage type|Supported by consolidated configuration?|
|
||||
|-------------------|----------------------------------------|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage) | No |
|
||||
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
|
||||
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
|
||||
| [Uploads](../uploads.md#using-object-storage) | Yes |
|
||||
|
|
|
|||
|
|
@ -2066,7 +2066,7 @@ on what features you intend to use:
|
|||
|
||||
|Object storage type|Supported by consolidated configuration?|
|
||||
|-------------------|----------------------------------------|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage) | No |
|
||||
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
|
||||
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
|
||||
| [Uploads](../uploads.md#using-object-storage) | Yes |
|
||||
|
|
|
|||
|
|
@ -898,7 +898,7 @@ on what features you intend to use:
|
|||
|
||||
|Object storage type|Supported by consolidated configuration?|
|
||||
|-------------------|----------------------------------------|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage) | No |
|
||||
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
|
||||
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
|
||||
| [Uploads](../uploads.md#using-object-storage) | Yes |
|
||||
|
|
|
|||
|
|
@ -1782,7 +1782,7 @@ on what features you intend to use:
|
|||
|
||||
|Object storage type|Supported by consolidated configuration?|
|
||||
|-------------------|----------------------------------------|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage) | No |
|
||||
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
|
||||
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
|
||||
| [Uploads](../uploads.md#using-object-storage) | Yes |
|
||||
|
|
|
|||
|
|
@ -2066,7 +2066,7 @@ on what features you intend to use:
|
|||
|
||||
|Object storage type|Supported by consolidated configuration?|
|
||||
|-------------------|----------------------------------------|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage) | No |
|
||||
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
|
||||
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
|
||||
| [Uploads](../uploads.md#using-object-storage) | Yes |
|
||||
|
|
|
|||
|
|
@ -1782,7 +1782,7 @@ on what features you intend to use:
|
|||
|
||||
|Object storage type|Supported by consolidated configuration?|
|
||||
|-------------------|----------------------------------------|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
|
||||
| [Backups](../../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage) | No |
|
||||
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
|
||||
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
|
||||
| [Uploads](../uploads.md#using-object-storage) | Yes |
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ It deprecates these endpoints, which will be removed for API version 5.
|
|||
In addition to templates common to the entire instance, project-specific
|
||||
templates are also available from this API endpoint.
|
||||
|
||||
Support for [Group-level file templates](../user/group/index.md#group-file-templates)
|
||||
**(PREMIUM)** was [added](https://gitlab.com/gitlab-org/gitlab/-/issues/5987)
|
||||
Support for [Group-level file templates](../user/group/index.md#group-file-templates) **(PREMIUM)**
|
||||
was [added](https://gitlab.com/gitlab-org/gitlab/-/issues/5987)
|
||||
in GitLab 11.5
|
||||
|
||||
## Get all templates of a particular type
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ of complexity, maintenance cost and enormous, negative impact on availability.
|
|||
|
||||
## New GitLab Pages Architecture
|
||||
|
||||
- GitLab Pages sources domains' configuration from GitLab's internal
|
||||
- GitLab Pages sources domains' configuration from the GitLab internal
|
||||
API, instead of reading `config.json` files from a local shared storage.
|
||||
- GitLab Pages serves static content from Object Storage.
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ too.
|
|||
|
||||
## Iterations
|
||||
|
||||
1. ✓ Redesign GitLab Pages configuration source to use GitLab's API
|
||||
1. ✓ Redesign GitLab Pages configuration source to use the GitLab API
|
||||
1. ✓ Evaluate performance and build reliable caching mechanisms
|
||||
1. ✓ Incrementally rollout the new source on GitLab.com
|
||||
1. ✓ Make GitLab Pages API domains configuration source enabled by default
|
||||
|
|
|
|||
|
|
@ -66,13 +66,13 @@ Complementary reads:
|
|||
- [Guidelines for implementing Enterprise Edition features](ee_features.md)
|
||||
- [Danger bot](dangerbot.md)
|
||||
- [Generate a changelog entry with `bin/changelog`](changelog.md)
|
||||
- [Requesting access to Chatops on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLab team members)
|
||||
- [Requesting access to ChatOps on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLab team members)
|
||||
- [Patch release process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md#process-for-developers)
|
||||
- [Adding a new service component to GitLab](adding_service_component.md)
|
||||
|
||||
### Development guidelines review
|
||||
|
||||
When you submit a change to GitLab's development guidelines, who
|
||||
When you submit a change to the GitLab development guidelines, who
|
||||
you ask for reviews depends on the level of change.
|
||||
|
||||
#### Wording, style, or link changes
|
||||
|
|
@ -132,7 +132,7 @@ In these cases, use the following workflow:
|
|||
|
||||
1. After completing the reviews, consult with the EM/Staff Engineer
|
||||
author / approver of the MR.
|
||||
|
||||
|
||||
If this is a significant change across multiple areas, request final review
|
||||
and approval from the VP of Development, the DRI for Development Guidelines,
|
||||
@clefelhocz1.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# GraphQL API style guide
|
||||
|
||||
This document outlines the style guide for GitLab's [GraphQL API](../api/graphql/index.md).
|
||||
This document outlines the style guide for the GitLab [GraphQL API](../api/graphql/index.md).
|
||||
|
||||
## How GitLab implements GraphQL
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ which is exposed as an API endpoint at `/api/graphql`.
|
|||
## Deep Dive
|
||||
|
||||
In March 2019, Nick Thomas hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
|
||||
on GitLab's [GraphQL API](../api/graphql/index.md) to share his domain specific knowledge
|
||||
on the GitLab [GraphQL API](../api/graphql/index.md) to share his domain specific knowledge
|
||||
with anyone who may work in this part of the codebase in the future. You can find the
|
||||
[recording on YouTube](https://www.youtube.com/watch?v=-9L_1MWrjkg), and the slides on
|
||||
[Google Slides](https://docs.google.com/presentation/d/1qOTxpkTdHIp1CRjuTvO-aXg0_rUtzE3ETfLUdnBB5uQ/edit)
|
||||
|
|
@ -44,7 +44,7 @@ add a `HTTP_PRIVATE_TOKEN` header.
|
|||
|
||||
## Global IDs
|
||||
|
||||
GitLab's GraphQL API uses Global IDs (i.e: `"gid://gitlab/MyObject/123"`)
|
||||
The GitLab GraphQL API uses Global IDs (i.e: `"gid://gitlab/MyObject/123"`)
|
||||
and never database primary key IDs.
|
||||
|
||||
Global ID is [a convention](https://graphql.org/learn/global-object-identification/)
|
||||
|
|
@ -154,7 +154,7 @@ Further reading:
|
|||
|
||||
### Exposing Global IDs
|
||||
|
||||
In keeping with GitLab's use of [Global IDs](#global-ids), always convert
|
||||
In keeping with the GitLab use of [Global IDs](#global-ids), always convert
|
||||
database primary key IDs into Global IDs when you expose them.
|
||||
|
||||
All fields named `id` are
|
||||
|
|
@ -403,11 +403,11 @@ end
|
|||
|
||||
## Deprecating fields and enum values
|
||||
|
||||
GitLab's GraphQL API is versionless, which means we maintain backwards
|
||||
The GitLab GraphQL API is versionless, which means we maintain backwards
|
||||
compatibility with older versions of the API with every change. Rather
|
||||
than removing a field or [enum value](#enums), we need to _deprecate_ it instead.
|
||||
The deprecated parts of the schema can then be removed in a future release
|
||||
in accordance with [GitLab's deprecation process](../api/graphql/index.md#deprecation-process).
|
||||
in accordance with the [GitLab deprecation process](../api/graphql/index.md#deprecation-process).
|
||||
|
||||
Fields and enum values are deprecated using the `deprecated` property.
|
||||
The value of the property is a `Hash` of:
|
||||
|
|
@ -1106,7 +1106,7 @@ are returned as the result of the mutation.
|
|||
|
||||
#### Update mutation granularity
|
||||
|
||||
GitLab's service-oriented architecture means that most mutations call a Create, Delete, or Update
|
||||
The service-oriented architecture in GitLab means that most mutations call a Create, Delete, or Update
|
||||
service, for example `UpdateMergeRequestService`.
|
||||
For Update mutations, a you might want to only update one aspect of an object, and thus only need a
|
||||
_fine-grained_ mutation, for example `MergeRequest::SetWip`.
|
||||
|
|
@ -1233,7 +1233,7 @@ These arguments automatically generate an input type called
|
|||
|
||||
### Object identifier arguments
|
||||
|
||||
In keeping with GitLab's use of [Global IDs](#global-ids), mutation
|
||||
In keeping with the GitLab use of [Global IDs](#global-ids), mutation
|
||||
arguments should use Global IDs to identify an object and never database
|
||||
primary key IDs.
|
||||
|
||||
|
|
@ -1530,7 +1530,7 @@ In the future this may be able to be done using `InputUnions` if
|
|||
[this RFC](https://github.com/graphql/graphql-spec/blob/master/rfcs/InputUnion.md)
|
||||
is merged.
|
||||
|
||||
## GitLab's custom scalars
|
||||
## GitLab custom scalars
|
||||
|
||||
### `Types::TimeType`
|
||||
|
||||
|
|
@ -1695,7 +1695,7 @@ end
|
|||
|
||||
## Notes about Query flow and GraphQL infrastructure
|
||||
|
||||
GitLab's GraphQL infrastructure can be found in `lib/gitlab/graphql`.
|
||||
The GitLab GraphQL infrastructure can be found in `lib/gitlab/graphql`.
|
||||
|
||||
[Instrumentation](https://graphql-ruby.org/queries/instrumentation.html) is functionality
|
||||
that wraps around a query being executed. It is implemented as a module that uses the `Instrumentation` class.
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ The simplest way to ensure this, is to add support for your feature or service t
|
|||
### Simplified component overview
|
||||
|
||||
This is a simplified architecture diagram that can be used to
|
||||
understand GitLab's architecture.
|
||||
understand the GitLab architecture.
|
||||
|
||||
A complete architecture diagram is available in our
|
||||
[component diagram](#component-diagram) below.
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ Keep the following in mind when submitting merge requests:
|
|||
|
||||
- When reviewers are reading through a merge request they may request guidance from other
|
||||
reviewers.
|
||||
- If the code quality is found to not meet GitLab’s standards, the merge request reviewer will
|
||||
- If the code quality is found to not meet GitLab standards, the merge request reviewer will
|
||||
provide guidance and refer the author to our:
|
||||
- [Documentation](../documentation/styleguide/index.md) style guide.
|
||||
- [Code style guides](style_guides.md).
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ bin/rake danger_local
|
|||
## Operation
|
||||
|
||||
On startup, Danger reads a [`Dangerfile`](https://gitlab.com/gitlab-org/gitlab/blob/master/Dangerfile)
|
||||
from the project root. GitLab's Danger code is decomposed into a set of helpers
|
||||
from the project root. Danger code in GitLab is decomposed into a set of helpers
|
||||
and plugins, all within the [`danger/`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/danger/)
|
||||
subdirectory, so ours just tells Danger to load it all. Danger then runs
|
||||
each plugin against the merge request, collecting the output from each. A plugin
|
||||
|
|
@ -66,7 +66,7 @@ continue to apply. However, there are a few things that deserve special emphasis
|
|||
Danger is a powerful tool and flexible tool, but not always the most appropriate
|
||||
way to solve a given problem or workflow.
|
||||
|
||||
First, be aware of GitLab's [commitment to dogfooding](https://about.gitlab.com/handbook/engineering/#dogfooding).
|
||||
First, be aware of the GitLab [commitment to dogfooding](https://about.gitlab.com/handbook/engineering/#dogfooding).
|
||||
The code we write for Danger is GitLab-specific, and it **may not** be most
|
||||
appropriate place to implement functionality that addresses a need we encounter.
|
||||
Our users, customers, and even our own satellite projects, such as [Gitaly](https://gitlab.com/gitlab-org/gitaly),
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ We rely on different sources to present diffs. These include:
|
|||
## Deep Dive
|
||||
|
||||
In January 2019, Oswaldo Ferreira hosted a Deep Dive (GitLab team members only:
|
||||
`https://gitlab.com/gitlab-org/create-stage/issues/1`) on GitLab's Diffs and Commenting on Diffs
|
||||
`https://gitlab.com/gitlab-org/create-stage/issues/1`) on GitLab Diffs and Commenting on Diffs
|
||||
functionality to share his domain specific knowledge with anyone who may work in this part of the
|
||||
codebase in the future. You can find the [recording on YouTube](https://www.youtube.com/watch?v=K6G3gMcFyek),
|
||||
and the slides on [Google Slides](https://docs.google.com/presentation/d/1bGutFH2AT3bxOPZuLMGl1ANWHqFnrxwQwjiwAZkF-TU/edit)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ updated using renovate are:
|
|||
|
||||
We discourage installing some dependencies in [GitLab repository](https://gitlab.com/gitlab-org/gitlab)
|
||||
because they can create conflicts in the dependency tree. Blocked dependencies are declared in the
|
||||
`blockDependencies` property of GitLab’s [`package.json` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/package.json).
|
||||
`blockDependencies` property of the GitLab [`package.json` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/package.json).
|
||||
|
||||
## Dependency notes
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
|
|||
### Share your work early
|
||||
|
||||
1. Before writing code, ensure your vision of the architecture is aligned with
|
||||
GitLab's architecture.
|
||||
GitLab architecture.
|
||||
1. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it.
|
||||
|
||||

|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ we're using that our target browsers don't support. You don't need to add `core-
|
|||
polyfills manually.
|
||||
|
||||
GitLab adds non-`core-js` polyfills for extending browser features (such as
|
||||
GitLab's SVG polyfill), which allow us to reference SVGs by using `<use xlink:href>`.
|
||||
the GitLab SVG polyfill), which allow us to reference SVGs by using `<use xlink:href>`.
|
||||
Be sure to add these polyfills to `app/assets/javascripts/commons/polyfills.js`.
|
||||
|
||||
To see what polyfills are being used:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
# Frontend Development Guidelines
|
||||
|
||||
This document describes various guidelines to ensure consistency and quality
|
||||
across GitLab's frontend team.
|
||||
across the GitLab frontend team.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Working with our frontend assets requires Node (v10.13.0 or greater) and Yarn
|
|||
For our currently-supported browsers, see our [requirements](../../install/requirements.md#supported-web-browsers).
|
||||
|
||||
Use [BrowserStack](https://www.browserstack.com/) to test with our supported browsers.
|
||||
Sign in to BrowserStack with the credentials saved in the **Engineering** vault of GitLab's
|
||||
Sign in to BrowserStack with the credentials saved in the **Engineering** vault of the GitLab
|
||||
[shared 1Password account](https://about.gitlab.com/handbook/security/#1password-guide).
|
||||
|
||||
## Initiatives
|
||||
|
|
@ -41,7 +41,7 @@ How we [plan and execute](development_process.md) the work on the frontend.
|
|||
|
||||
## Architecture
|
||||
|
||||
How we go about [making fundamental design decisions](architecture.md) in GitLab's frontend team
|
||||
How we go about [making fundamental design decisions](architecture.md) in the GitLab frontend team
|
||||
or make changes to our frontend development guidelines.
|
||||
|
||||
## Testing
|
||||
|
|
@ -56,7 +56,7 @@ Reusable components with technical and usage guidelines can be found in our
|
|||
|
||||
## Design Patterns
|
||||
|
||||
Common JavaScript [design patterns](design_patterns.md) in GitLab's codebase.
|
||||
Common JavaScript [design patterns](design_patterns.md) in the GitLab codebase.
|
||||
|
||||
## Vue.js Best Practices
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# GraphQL development guidelines
|
||||
|
||||
This guide contains all the information to successfully contribute to GitLab's
|
||||
This guide contains all the information to successfully contribute to the GitLab
|
||||
GraphQL API. This is a living document, and we welcome contributions,
|
||||
feedback, and suggestions.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ The first option is to simply [import the Project tarball file via the GitLab UI
|
|||
|
||||
It should take up to 15 minutes for the project to fully import. You can head to the project's main page for the current status.
|
||||
|
||||
This method ignores all the errors silently (including the ones related to `GITALY_DISABLE_REQUEST_LIMITS`) and is used by GitLab's users. For development and testing, check the other methods below.
|
||||
This method ignores all the errors silently (including the ones related to `GITALY_DISABLE_REQUEST_LIMITS`) and is used by GitLab users. For development and testing, check the other methods below.
|
||||
|
||||
### Importing via the `import-project` script
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Frontend Development Guidelines
|
||||
|
||||
This guide contains all the information to successfully contribute to GitLab's frontend.
|
||||
This guide contains all the information to successfully contribute to the GitLab frontend.
|
||||
This is a living document, and we welcome contributions, feedback, and suggestions.
|
||||
|
||||
## [Development](development/index.md)
|
||||
|
|
|
|||
|
|
@ -305,7 +305,7 @@ bundle exec stackprof --stackcollapse /tmp/stackprof.55769.c6c3906452.profile |
|
|||
|
||||
## RSpec profiling
|
||||
|
||||
GitLab's development environment also includes the
|
||||
The GitLab development environment also includes the
|
||||
[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
|
||||
|
|
@ -358,7 +358,7 @@ We can use two approaches, often in combination, to track down memory issues:
|
|||
|
||||
We can use `memory_profiler` for profiling.
|
||||
|
||||
The [`memory_profiler`](https://github.com/SamSaffron/memory_profiler) gem is already present in GitLab's `Gemfile`,
|
||||
The [`memory_profiler`](https://github.com/SamSaffron/memory_profiler) gem is already present in the GitLab `Gemfile`,
|
||||
you just need to require it:
|
||||
|
||||
```ruby
|
||||
|
|
|
|||
|
|
@ -457,7 +457,7 @@ Consult the [Review Apps](testing_guide/review_apps.md) dedicated page for more
|
|||
|
||||
### As-if-FOSS jobs
|
||||
|
||||
The `* as-if-foss` jobs allows to run GitLab's test suite "as-if-FOSS", meaning as if the jobs would run in the context
|
||||
The `* as-if-foss` jobs allows the GitLab test suite "as-if-FOSS", meaning as if the jobs would run in the context
|
||||
of the `gitlab-org/gitlab-foss` project. These jobs are only created in the following cases:
|
||||
|
||||
- `gitlab-org/security/gitlab` merge requests.
|
||||
|
|
|
|||
|
|
@ -475,3 +475,142 @@ Snowplow Micro is a Docker-based solution for testing frontend and backend event
|
|||
Snowplow Mini can be used for testing frontend and backend events on a production, staging and local development environment.
|
||||
|
||||
For GitLab.com, we're setting up a [QA and Testing environment](https://gitlab.com/gitlab-org/telemetry/-/issues/266) using Snowplow Mini.
|
||||
|
||||
## Snowplow Schemas
|
||||
|
||||
### Default Schema
|
||||
|
||||
| Field Name | Required | Type | Description |
|
||||
|--------------------------|---------------------|-----------|----------------------------------------------------------------------------------------------------------------------------------|
|
||||
| app_id | **{check-circle}** | string | Unique identifier for website / application |
|
||||
| base_currency | **{dotted-circle}** | string | Reporting currency |
|
||||
| br_colordepth | **{dotted-circle}** | integer | Browser color depth |
|
||||
| br_cookies | **{dotted-circle}** | boolean | Does the browser permit cookies? |
|
||||
| br_family | **{dotted-circle}** | string | Browser family |
|
||||
| br_features_director | **{dotted-circle}** | boolean | Director plugin installed? |
|
||||
| br_features_flash | **{dotted-circle}** | boolean | Flash plugin installed? |
|
||||
| br_features_gears | **{dotted-circle}** | boolean | Google gears installed? |
|
||||
| br_features_java | **{dotted-circle}** | boolean | Java plugin installed? |
|
||||
| br_features_pdf | **{dotted-circle}** | boolean | Adobe PDF plugin installed? |
|
||||
| br_features_quicktime | **{dotted-circle}** | boolean | Quicktime plugin installed? |
|
||||
| br_features_realplayer | **{dotted-circle}** | boolean | Realplayer plugin installed? |
|
||||
| br_features_silverlight | **{dotted-circle}** | boolean | Silverlight plugin installed? |
|
||||
| br_features_windowsmedia | **{dotted-circle}** | boolean | Windows media plugin installed? |
|
||||
| br_lang | **{dotted-circle}** | string | Language the browser is set to |
|
||||
| br_name | **{dotted-circle}** | string | Browser name |
|
||||
| br_renderengine | **{dotted-circle}** | string | Browser rendering engine |
|
||||
| br_type | **{dotted-circle}** | string | Browser type |
|
||||
| br_version | **{dotted-circle}** | string | Browser version |
|
||||
| br_viewheight | **{dotted-circle}** | string | Browser viewport height |
|
||||
| br_viewwidth | **{dotted-circle}** | string | Browser viewport width |
|
||||
| collector_tstamp | **{dotted-circle}** | timestamp | Time stamp for the event recorded by the collector |
|
||||
| contexts | **{dotted-circle}** | | |
|
||||
| derived_contexts | **{dotted-circle}** | | Contexts derived in the Enrich process |
|
||||
| derived_tstamp | **{dotted-circle}** | timestamp | Timestamp making allowance for innaccurate device clock |
|
||||
| doc_charset | **{dotted-circle}** | string | Web page’s character encoding |
|
||||
| doc_height | **{dotted-circle}** | string | Web page height |
|
||||
| doc_width | **{dotted-circle}** | string | Web page width |
|
||||
| domain_sessionid | **{dotted-circle}** | string | Unique identifier (UUID) for this visit of this user_id to this domain |
|
||||
| domain_sessionidx | **{dotted-circle}** | integer | Index of number of visits that this user_id has made to this domain (The first visit is `1`) |
|
||||
| domain_userid | **{dotted-circle}** | string | Unique identifier for a user, based on a first party cookie (so domain specific) |
|
||||
| dvce_created_tstamp | **{dotted-circle}** | timestamp | Timestamp when event occurred, as recorded by client device |
|
||||
| dvce_ismobile | **{dotted-circle}** | boolean | Indicates whether device is mobile |
|
||||
| dvce_screenheight | **{dotted-circle}** | string | Screen / monitor resolution |
|
||||
| dvce_screenwidth | **{dotted-circle}** | string | Screen / monitor resolution |
|
||||
| dvce_sent_tstamp | **{dotted-circle}** | timestamp | Timestamp when event was sent by client device to collector |
|
||||
| dvce_type | **{dotted-circle}** | string | Type of device |
|
||||
| etl_tags | **{dotted-circle}** | string | JSON of tags for this ETL run |
|
||||
| etl_tstamp | **{dotted-circle}** | timestamp | Timestamp event began ETL |
|
||||
| event | **{dotted-circle}** | string | Event type |
|
||||
| event_fingerprint | **{dotted-circle}** | string | Hash client-set event fields |
|
||||
| event_format | **{dotted-circle}** | string | Format for event |
|
||||
| event_id | **{dotted-circle}** | string | Event UUID |
|
||||
| event_name | **{dotted-circle}** | string | Event name |
|
||||
| event_vendor | **{dotted-circle}** | string | The company who developed the event model |
|
||||
| event_version | **{dotted-circle}** | string | Version of event schema |
|
||||
| geo_city | **{dotted-circle}** | string | City of IP origin |
|
||||
| geo_country | **{dotted-circle}** | string | Country of IP origin |
|
||||
| geo_latitude | **{dotted-circle}** | string | An approximate latitude |
|
||||
| geo_longitude | **{dotted-circle}** | string | An approximate longitude |
|
||||
| geo_region | **{dotted-circle}** | string | Region of IP origin |
|
||||
| geo_region_name | **{dotted-circle}** | string | Region of IP origin |
|
||||
| geo_timezone | **{dotted-circle}** | string | Timezone of IP origin |
|
||||
| geo_zipcode | **{dotted-circle}** | string | Zip (postal) code of IP origin |
|
||||
| ip_domain | **{dotted-circle}** | string | Second level domain name associated with the visitor’s IP address |
|
||||
| ip_isp | **{dotted-circle}** | string | Visitor’s ISP |
|
||||
| ip_netspeed | **{dotted-circle}** | string | Visitor’s connection type |
|
||||
| ip_organization | **{dotted-circle}** | string | Organization associated with the visitor’s IP address – defaults to ISP name if none is found |
|
||||
| mkt_campaign | **{dotted-circle}** | string | The campaign ID |
|
||||
| mkt_clickid | **{dotted-circle}** | string | The click ID |
|
||||
| mkt_content | **{dotted-circle}** | string | The content or ID of the ad. |
|
||||
| mkt_medium | **{dotted-circle}** | string | Type of traffic source |
|
||||
| mkt_network | **{dotted-circle}** | string | The ad network to which the click ID belongs |
|
||||
| mkt_source | **{dotted-circle}** | string | The company / website where the traffic came from |
|
||||
| mkt_term | **{dotted-circle}** | string | Keywords associated with the referrer |
|
||||
| name_tracker | **{dotted-circle}** | string | The tracker namespace |
|
||||
| network_userid | **{dotted-circle}** | string | Unique identifier for a user, based on a cookie from the collector (so set at a network level and shouldn’t be set by a tracker) |
|
||||
| os_family | **{dotted-circle}** | string | Operating system family |
|
||||
| os_manufacturer | **{dotted-circle}** | string | Manufacturers of operating system |
|
||||
| os_name | **{dotted-circle}** | string | Name of operating system |
|
||||
| os_timezone | **{dotted-circle}** | string | Client operating system timezone |
|
||||
| page_referrer | **{dotted-circle}** | string | Referrer URL |
|
||||
| page_title | **{dotted-circle}** | string | Page title |
|
||||
| page_url | **{dotted-circle}** | string | Page URL |
|
||||
| page_urlfragment | **{dotted-circle}** | string | Fragment aka anchor |
|
||||
| page_urlhost | **{dotted-circle}** | string | Host aka domain |
|
||||
| page_urlpath | **{dotted-circle}** | string | Path to page |
|
||||
| page_urlport | **{dotted-circle}** | integer | Port if specified, 80 if not |
|
||||
| page_urlquery | **{dotted-circle}** | string | Query string |
|
||||
| page_urlscheme | **{dotted-circle}** | string | Scheme (protocol name) |
|
||||
| platform | **{dotted-circle}** | string | The platform the app runs on |
|
||||
| pp_xoffset_max | **{dotted-circle}** | integer | Maximum page x offset seen in the last ping period |
|
||||
| pp_xoffset_min | **{dotted-circle}** | integer | Minimum page x offset seen in the last ping period |
|
||||
| pp_yoffset_max | **{dotted-circle}** | integer | Maximum page y offset seen in the last ping period |
|
||||
| pp_yoffset_min | **{dotted-circle}** | integer | Minimum page y offset seen in the last ping period |
|
||||
| refr_domain_userid | **{dotted-circle}** | string | The Snowplow domain_userid of the referring website |
|
||||
| refr_dvce_tstamp | **{dotted-circle}** | timestamp | The time of attaching the domain_userid to the inbound link |
|
||||
| refr_medium | **{dotted-circle}** | string | Type of referer |
|
||||
| refr_source | **{dotted-circle}** | string | Name of referer if recognised |
|
||||
| refr_term | **{dotted-circle}** | string | Keywords if source is a search engine |
|
||||
| refr_urlfragment | **{dotted-circle}** | string | Referer URL fragment |
|
||||
| refr_urlhost | **{dotted-circle}** | string | Referer host |
|
||||
| refr_urlpath | **{dotted-circle}** | string | Referer page path |
|
||||
| refr_urlport | **{dotted-circle}** | integer | Referer port |
|
||||
| refr_urlquery | **{dotted-circle}** | string | Referer URL querystring |
|
||||
| refr_urlscheme | **{dotted-circle}** | string | Referer scheme |
|
||||
| se_action | **{dotted-circle}** | string | The action / event itself |
|
||||
| se_category | **{dotted-circle}** | string | The category of event |
|
||||
| se_label | **{dotted-circle}** | string | A label often used to refer to the ‘object’ the action is performed on |
|
||||
| se_property | **{dotted-circle}** | string | A property associated with either the action or the object |
|
||||
| se_value | **{dotted-circle}** | decimal | A value associated with the user action |
|
||||
| ti_category | **{dotted-circle}** | string | Item category |
|
||||
| ti_currency | **{dotted-circle}** | string | Currency |
|
||||
| ti_name | **{dotted-circle}** | string | Item name |
|
||||
| ti_orderid | **{dotted-circle}** | string | Order ID |
|
||||
| ti_price | **{dotted-circle}** | decimal | Item price |
|
||||
| ti_price_base | **{dotted-circle}** | decimal | Item price in base currency |
|
||||
| ti_quantity | **{dotted-circle}** | integer | Item quantity |
|
||||
| ti_sku | **{dotted-circle}** | string | Item SKU |
|
||||
| tr_affiliation | **{dotted-circle}** | string | Transaction affiliation (such as channel) |
|
||||
| tr_city | **{dotted-circle}** | string | Delivery address: city |
|
||||
| tr_country | **{dotted-circle}** | string | Delivery address: country |
|
||||
| tr_currency | **{dotted-circle}** | string | Transaction Currency |
|
||||
| tr_orderid | **{dotted-circle}** | string | Order ID |
|
||||
| tr_shipping | **{dotted-circle}** | decimal | Delivery cost charged |
|
||||
| tr_shipping_base | **{dotted-circle}** | decimal | Shipping cost in base currency |
|
||||
| tr_state | **{dotted-circle}** | string | Delivery address: state |
|
||||
| tr_tax | **{dotted-circle}** | decimal | Transaction tax value (such as amount of VAT included) |
|
||||
| tr_tax_base | **{dotted-circle}** | decimal | Tax applied in base currency |
|
||||
| tr_total | **{dotted-circle}** | decimal | Transaction total value |
|
||||
| tr_total_base | **{dotted-circle}** | decimal | Total amount of transaction in base currency |
|
||||
| true_tstamp | **{dotted-circle}** | timestamp | User-set exact timestamp |
|
||||
| txn_id | **{dotted-circle}** | string | Transaction ID |
|
||||
| unstruct_event | **{dotted-circle}** | JSON | The properties of the event |
|
||||
| uploaded_at | **{dotted-circle}** | | |
|
||||
| user_fingerprint | **{dotted-circle}** | integer | User identifier based on (hopefully unique) browser features |
|
||||
| user_id | **{dotted-circle}** | string | Unique identifier for user, set by the business using setUserId |
|
||||
| user_ipaddress | **{dotted-circle}** | string | IP address |
|
||||
| useragent | **{dotted-circle}** | string | User agent (expressed as a browser string) |
|
||||
| v_collector | **{dotted-circle}** | string | Collector version |
|
||||
| v_etl | **{dotted-circle}** | string | ETL version |
|
||||
| v_tracker | **{dotted-circle}** | string | Identifier for Snowplow tracker |
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
## Deep Dive
|
||||
|
||||
In December 2018, Tiago Botelho hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
|
||||
on GitLab's [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
|
||||
on the GitLab [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
|
||||
to share his domain specific knowledge with anyone who may work in this part of the
|
||||
codebase in the future. You can find the [recording on YouTube](https://www.youtube.com/watch?v=sSZq0fpdY-Y),
|
||||
and the slides in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/8693404888a941fd851f8a8ecdec9675/Gitlab_Create_-_Pull_Mirroring_Deep_Dive.pdf).
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ fields.
|
|||
## Why do we need that?
|
||||
|
||||
We need page objects because we need to reduce duplication and avoid problems
|
||||
whenever someone changes some selectors in GitLab's source code.
|
||||
whenever someone changes some selectors in the GitLab source code.
|
||||
|
||||
Imagine that we have a hundred specs in GitLab QA, and we need to sign into
|
||||
GitLab each time, before we make assertions. Without a page object, one would
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
|
|||
| `:jira` | The test requires a Jira Server. [GitLab-QA](https://gitlab.com/gitlab-org/gitlab-qa) provisions the Jira Server in a Docker container when the `Test::Integration::Jira` test scenario is run.
|
||||
| `:kubernetes` | The test includes a GitLab instance that is configured to be run behind an SSH tunnel, allowing a TLS-accessible GitLab. This test also includes provisioning of at least one Kubernetes cluster to test against. _This tag is often be paired with `:orchestrated`._ |
|
||||
| `:only` | The test is only to be run against specific environments or pipelines. See [Environment selection](environment_selection.md) for more information. |
|
||||
| `:orchestrated` | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify GitLab's configuration (for example, Staging). |
|
||||
| `:orchestrated` | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify the GitLab configuration (for example, Staging). |
|
||||
| `:quarantine` | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), runs in a separate job that only includes quarantined tests, and is allowed to fail. The test is skipped in its regular job so that if it fails it doesn't hold up the pipeline. Note that you can also [quarantine a test only when it runs against specific environment](environment_selection.md#quarantining-a-test-for-a-specific-environment). |
|
||||
| `:reliable` | The test has been [promoted to a reliable test](https://about.gitlab.com/handbook/engineering/quality/guidelines/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |
|
||||
| `:requires_admin` | The test requires an admin account. Tests with the tag are excluded when run against Canary and Production environments. |
|
||||
|
|
|
|||
|
|
@ -1088,7 +1088,7 @@ Some regressions only affect a specific browser version. We can install and test
|
|||
|
||||
[BrowserStack](https://www.browserstack.com/) allows you to test more than 1200 mobile devices and browsers.
|
||||
You can use it directly through the [live app](https://www.browserstack.com/live) or you can install the [chrome extension](https://chrome.google.com/webstore/detail/browserstack/nkihdmlheodkdfojglpcjjmioefjahjb) for easy access.
|
||||
Sign in to BrowserStack with the credentials saved in the **Engineering** vault of GitLab's
|
||||
Sign in to BrowserStack with the credentials saved in the **Engineering** vault of the GitLab
|
||||
[shared 1Password account](https://about.gitlab.com/handbook/security/#1password-guide).
|
||||
|
||||
### Firefox
|
||||
|
|
|
|||
|
|
@ -102,8 +102,8 @@ subgraph "CNG-mirror pipeline"
|
|||
- The manual `review-stop` can be used to
|
||||
stop a Review App manually, and is also started by GitLab once a merge
|
||||
request's branch is deleted after being merged.
|
||||
- The Kubernetes cluster is connected to the `gitlab` projects using
|
||||
[GitLab's Kubernetes integration](../../user/project/clusters/index.md). This basically
|
||||
- The Kubernetes cluster is connected to the `gitlab` projects using the
|
||||
[GitLab Kubernetes integration](../../user/project/clusters/index.md). This basically
|
||||
allows to have a link to the Review App directly from the merge request widget.
|
||||
|
||||
### Auto-stopping of Review Apps
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ This is a guide for how to get a Windows development virtual machine on Google C
|
|||
|
||||
## Why Windows in Google Cloud?
|
||||
|
||||
Use of Microsoft Windows operating systems on company laptops is banned under GitLab's [Approved Operating Systems policy](https://about.gitlab.com/handbook/security/approved_os.html#windows).
|
||||
Use of Microsoft Windows operating systems on company laptops is banned under the GitLab [Approved Operating Systems policy](https://about.gitlab.com/handbook/security/approved_os.html#windows).
|
||||
|
||||
This can make it difficult to develop features for the Windows platforms. Using GCP allows us to have a temporary Windows machine that can be removed once we're done with it.
|
||||
|
||||
|
|
|
|||
|
|
@ -627,7 +627,7 @@ backups are copied to, and is created if it does not exist. If the
|
|||
directory that you want to copy the tarballs to is the root of your mounted
|
||||
directory, use `.` instead.
|
||||
|
||||
Because file system performance may affect GitLab's overall performance,
|
||||
Because file system performance may affect overall GitLab performance,
|
||||
[GitLab doesn't recommend using EFS for storage](../administration/nfs.md#avoid-using-awss-elastic-file-system-efs).
|
||||
|
||||
For Omnibus GitLab packages:
|
||||
|
|
@ -671,7 +671,7 @@ For installations from source:
|
|||
|
||||
The backup archives created by GitLab (`1393513186_2014_02_27_gitlab_backup.tar`)
|
||||
have the owner/group `git`/`git` and 0600 permissions by default. This is
|
||||
meant to avoid other system users reading GitLab's data. If you need the backup
|
||||
meant to avoid other system users reading GitLab data. If you need the backup
|
||||
archives to have different permissions, you can use the `archive_permissions`
|
||||
setting.
|
||||
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ block_auto_created_users: false
|
|||
## Disable two-factor authentication for all users
|
||||
|
||||
This task disables two-factor authentication (2FA) for all users that have it enabled. This can be
|
||||
useful if GitLab's `config/secrets.yml` file has been lost and users are unable
|
||||
useful if the GitLab `config/secrets.yml` file has been lost and users are unable
|
||||
to log in, for example.
|
||||
|
||||
To disable two-factor authentication for all users, run:
|
||||
|
|
|
|||
|
|
@ -234,7 +234,7 @@ If you renew or upgrade, your data is accessible again.
|
|||
## CI pipeline minutes
|
||||
|
||||
CI pipeline minutes are the execution time for your
|
||||
[pipelines](../../ci/pipelines/index.md) on GitLab's shared runners. Each
|
||||
[pipelines](../../ci/pipelines/index.md) on GitLab shared runners. Each
|
||||
[GitLab.com tier](https://about.gitlab.com/pricing/) includes a monthly quota
|
||||
of CI pipeline minutes:
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ When choosing a subscription, there are two factors to consider:
|
|||
There are some differences in how a subscription applies, depending if you use
|
||||
GitLab.com or a self-managed instance:
|
||||
|
||||
- [GitLab.com](gitlab_com/index.md): GitLab's software-as-a-service offering.
|
||||
- [GitLab.com](gitlab_com/index.md): The GitLab software-as-a-service offering.
|
||||
You don't need to install anything to use GitLab.com, you only need to
|
||||
[sign up](https://gitlab.com/users/sign_up) and start using GitLab straight away.
|
||||
- [GitLab self-managed](self_managed/index.md): Install, administer, and maintain
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ with various cloud providers.
|
|||
|
||||
In order to provide modern DevOps workflows, our Application Development Platform relies on
|
||||
[Auto DevOps](../autodevops/index.md) to provide those workflows. Auto DevOps works with
|
||||
any Kubernetes cluster; you're not limited to running on GitLab's infrastructure. Additionally, Auto DevOps offers
|
||||
any Kubernetes cluster; you're not limited to running on GitLab infrastructure. Additionally, Auto DevOps offers
|
||||
an incremental consumption path. Because it is [composable](../autodevops/customize.md#using-components-of-auto-devops),
|
||||
you can use as much or as little of the default pipeline as you'd like, and deeply customize without having to integrate a completely different platform.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Read them carefully to understand how each one works.
|
|||
## Auto Build
|
||||
|
||||
NOTE:
|
||||
Auto Build is not supported if Docker in Docker is not available for your GitLab Runners, like in OpenShift clusters. GitLab's OpenShift support is tracked [in a dedicated epic](https://gitlab.com/groups/gitlab-org/-/epics/2068).
|
||||
Auto Build is not supported if Docker in Docker is not available for your GitLab Runners, like in OpenShift clusters. The OpenShift support in GitLab is tracked [in a dedicated epic](https://gitlab.com/groups/gitlab-org/-/epics/2068).
|
||||
|
||||
Auto Build creates a build of the application using an existing `Dockerfile` or
|
||||
Heroku buildpacks. The resulting Docker image is pushed to the
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Once work on the development branch is complete, then the feature branch can be
|
|||
|
||||
GitLab frequently implements this process whenever there is an MVC that requires multiple MRs.
|
||||
|
||||
## Use case: GitLab's release posts
|
||||
## Use case: GitLab release posts
|
||||
|
||||
This section describes the use case with GitLab [release posts](https://about.gitlab.com/handbook/marketing/blog/release-posts/).
|
||||
Dozens of GitLab team members contribute to each monthly release post.
|
||||
|
|
|
|||
|
|
@ -176,8 +176,8 @@ but commented out to help encourage others to add to it in the future. -->
|
|||
|
||||
- [Getting Started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
|
||||
- [Migrate from Git Annex to Git LFS](migrate_from_git_annex_to_git_lfs.md)
|
||||
- [GitLab's Git LFS user documentation](index.md)
|
||||
- [GitLab's Git LFS administrator documentation](../../../administration/lfs/index.md)
|
||||
- [GitLab Git LFS user documentation](index.md)
|
||||
- [GitLab Git LFS administrator documentation](../../../administration/lfs/index.md)
|
||||
- Alternative method to [migrate an existing repository to Git LFS](https://github.com/git-lfs/git-lfs/wiki/Tutorial#migrating-existing-repository-data-to-lfs)
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
Welcome to Topics! We have organized our content resources into topics
|
||||
to get you started on areas of your interest. Each topic page
|
||||
consists of an index listing all related content. It guides
|
||||
you through better understanding GitLab's concepts
|
||||
you through better understanding GitLab concepts
|
||||
through our regular docs, and, when available, through articles (guides,
|
||||
tutorials, technical overviews, blog posts) and videos.
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
|
|||
1. [Creating a Project in GitLab - Video](https://www.youtube.com/watch?v=7p0hrpNaJ14)
|
||||
1. [How to Create Files and Directories](https://about.gitlab.com/blog/2016/02/10/feature-highlight-create-files-and-directories-from-files-page/)
|
||||
1. [GitLab To-Do List](https://about.gitlab.com/blog/2016/03/02/gitlab-todos-feature-highlight/)
|
||||
1. [GitLab's Work in Progress (WIP) Flag](https://about.gitlab.com/blog/2016/01/08/feature-highlight-wip/)
|
||||
1. [GitLab Work in Progress (WIP) Flag](https://about.gitlab.com/blog/2016/01/08/feature-highlight-wip/)
|
||||
|
||||
### 1.5. Migrating from other Source Control
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ command on your active database server:
|
|||
sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql -p 5432 -U gitlab-psql -s -f /tmp/structure.sql gitlabhq_production
|
||||
```
|
||||
|
||||
If you're not using GitLab's Omnibus package you may have to adjust the paths to
|
||||
If you're not using the Omnibus GitLab package you may have to adjust the paths to
|
||||
`pg_dump` and the PostgreSQL installation directory to match the paths of your
|
||||
configuration.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,9 +20,9 @@ To see DevOps Report, go to **Admin Area > Analytics > DevOps Report**.
|
|||
NOTE:
|
||||
Your GitLab instance's [usage ping](../settings/usage_statistics.md#usage-ping) must be activated in order to use this feature.
|
||||
|
||||
The DevOps Score tab displays the usage of GitLab's major features on your instance over
|
||||
The DevOps Score tab displays the usage of major GitLab features on your instance over
|
||||
the last 30 days, averaged over the number of billable users in that time period. It also
|
||||
provides a Lead score per feature, which is calculated based on GitLab's analysis
|
||||
provides a Lead score per feature, which is calculated based on GitLab analysis
|
||||
of top-performing instances based on [usage ping data](../settings/usage_statistics.md#usage-ping) that GitLab has
|
||||
collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature.
|
||||
Your overall **DevOps Score** is an average of your feature scores. You can use this score to compare your DevOps status to other organizations.
|
||||
|
|
@ -32,7 +32,7 @@ Your overall **DevOps Score** is an average of your feature scores. You can use
|
|||
The page also provides helpful links to articles and GitLab docs, to help you
|
||||
improve your scores.
|
||||
|
||||
Usage ping data is aggregated on GitLab's servers for analysis. Your usage
|
||||
Usage ping data is aggregated on GitLab servers for analysis. Your usage
|
||||
information is **not sent** to any other GitLab instances. If you have just started using GitLab, it may take a few weeks for data to be
|
||||
collected before this feature is available.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ collected before this feature is available.
|
|||
|
||||
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7.
|
||||
|
||||
The DevOps Adoption tab shows you which segments of your organization are using GitLab's most essential features:
|
||||
The DevOps Adoption tab shows you which segments of your organization are using the most essential features of GitLab:
|
||||
|
||||
- Issues
|
||||
- Merge Requests
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ The Admin Area is made up of the following sections:
|
|||
| **{lock}** Credentials **(ULTIMATE ONLY)** | View [credentials](credentials_inventory.md) that can be used to access your instance. |
|
||||
| **{template}** Service Templates | Create [service templates](../project/integrations/services_templates.md) for projects. |
|
||||
| **{labels}** Labels | Create and maintain [labels](labels.md) for your GitLab instance. |
|
||||
| **{appearance}** Appearance | Customize [GitLab's appearance](appearance.md). |
|
||||
| **{appearance}** Appearance | Customize [GitLab appearance](appearance.md). |
|
||||
| **{settings}** Settings | Modify the [settings](settings/index.md) for your GitLab instance. |
|
||||
|
||||
## Admin Dashboard
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/logs
|
|||
|
||||
## Configuration
|
||||
|
||||
The external authorization service can be enabled by an admin on the GitLab's
|
||||
The external authorization service can be enabled by an administrator on the GitLab
|
||||
**Admin Area > Settings > General** page:
|
||||
|
||||

|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
|
|||
| ------ | ----------- |
|
||||
| [Continuous Integration and Deployment](continuous_integration.md) | Auto DevOps, runners and job artifacts. |
|
||||
| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM ONLY)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration is run after the project's own configuration. |
|
||||
| [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using GitLab's Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
|
||||
| [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using the GitLab Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
|
||||
|
||||
## Reporting
|
||||
|
||||
|
|
|
|||
|
|
@ -488,24 +488,24 @@ increases as the numbers go up. To use a configuration file, add it to your repo
|
|||
|
||||
| Environment variable | Description |
|
||||
|-----------------------------|--------------------|
|
||||
| `FUZZAPI_VERSION` |Specify API Fuzzing container version. Defaults to `latest`. |
|
||||
| `FUZZAPI_TARGET_URL` |Base URL of API testing target. |
|
||||
|[`FUZZAPI_CONFIG`](#configuration-files)|API Fuzzing configuration file. Defaults to `.gitlab-apifuzzer.yml`. |
|
||||
|[`FUZZAPI_PROFILE`](#configuration-files)|Configuration profile to use during testing. Defaults to `Quick`. |
|
||||
| `FUZZAPI_REPORT` |Scan report filename. Defaults to `gl-api_fuzzing-report.xml`. |
|
||||
|[`FUZZAPI_OPENAPI`](#openapi-specification)|OpenAPI specification file or URL. |
|
||||
|[`FUZZAPI_HAR`](#http-archive-har)|HTTP Archive (HAR) file. |
|
||||
|[`FUZZAPI_POSTMAN_COLLECTION`](#postman-collection)|Postman Collection file. |
|
||||
|[`FUZZAPI_OVERRIDES_FILE`](#overrides) |Path to a JSON file containing overrides. |
|
||||
|[`FUZZAPI_OVERRIDES_ENV`](#overrides) |JSON string containing headers to override. |
|
||||
|[`FUZZAPI_OVERRIDES_CMD`](#overrides) |Overrides command. |
|
||||
|[`FUZZAPI_OVERRIDES_INTERVAL`](#overrides) |How often to run overrides command in seconds. Defaults to `0` (once). |
|
||||
|[`FUZZAPI_HTTP_USERNAME`](#http-basic-authentication) |Username for HTTP authentication. |
|
||||
|[`FUZZAPI_HTTP_PASSWORD`](#http-basic-authentication) |Password for HTTP authentication. |
|
||||
| `FUZZAPI_VERSION` | Specify API Fuzzing container version. Defaults to `latest`. |
|
||||
| `FUZZAPI_TARGET_URL` | Base URL of API testing target. |
|
||||
|[`FUZZAPI_CONFIG`](#configuration-files) | API Fuzzing configuration file. Defaults to `.gitlab-apifuzzer.yml`. |
|
||||
|[`FUZZAPI_PROFILE`](#configuration-files) | Configuration profile to use during testing. Defaults to `Quick`. |
|
||||
| `FUZZAPI_REPORT` | Scan report filename. Defaults to `gl-api_fuzzing-report.xml`. |
|
||||
|[`FUZZAPI_OPENAPI`](#openapi-specification) | OpenAPI specification file or URL. |
|
||||
|[`FUZZAPI_HAR`](#http-archive-har) | HTTP Archive (HAR) file. |
|
||||
|[`FUZZAPI_POSTMAN_COLLECTION`](#postman-collection) | Postman Collection file. |
|
||||
|[`FUZZAPI_OVERRIDES_FILE`](#overrides) | Path to a JSON file containing overrides. |
|
||||
|[`FUZZAPI_OVERRIDES_ENV`](#overrides) | JSON string containing headers to override. |
|
||||
|[`FUZZAPI_OVERRIDES_CMD`](#overrides) | Overrides command. |
|
||||
|[`FUZZAPI_OVERRIDES_INTERVAL`](#overrides) | How often to run overrides command in seconds. Defaults to `0` (once). |
|
||||
|[`FUZZAPI_HTTP_USERNAME`](#http-basic-authentication) | Username for HTTP authentication. |
|
||||
|[`FUZZAPI_HTTP_PASSWORD`](#http-basic-authentication) | Password for HTTP authentication. |
|
||||
|
||||
<!--|[`FUZZAPI_D_TARGET_IMAGE`](#target-container) |API target docker image |
|
||||
|[`FUZZAPI_D_TARGET_ENV`](#target-container) |Docker environment options |
|
||||
|[`FUZZAPI_D_TARGET_VOLUME`](#target-container)|Docker volume options |
|
||||
|[`FUZZAPI_D_TARGET_VOLUME`](#target-container) | Docker volume options |
|
||||
|[`FUZZAPI_D_TARGET_PORTS`](#target-container) |Docker port options |
|
||||
| `FUZZAPI_D_WORKER_IMAGE` |Custom worker docker image |
|
||||
| `FUZZAPI_D_WORKER_ENV` |Custom worker docker environment options |
|
||||
|
|
@ -734,7 +734,7 @@ faults it reports.
|
|||
## Viewing fuzzing faults
|
||||
|
||||
The API Fuzzing analyzer produces a JSON report that is collected and used
|
||||
[to populate the faults into GitLab's vulnerability screens](../index.md#view-details-of-an-api-fuzzing-vulnerability).
|
||||
[to populate the faults into GitLab vulnerability screens](../index.md#view-details-of-an-api-fuzzing-vulnerability).
|
||||
Fuzzing faults show up as vulnerabilities with a severity of Unknown.
|
||||
|
||||
The faults that API fuzzing finds require manual investigation and aren't associated with a specific
|
||||
|
|
@ -754,7 +754,7 @@ pipelines. For more information, see the [Security Dashboard documentation](../s
|
|||
|
||||
### Interacting with the vulnerabilities
|
||||
|
||||
Fuzzing faults show up as vulnerabilities with a severity of Unknown.
|
||||
Fuzzing faults show up as vulnerabilities with a severity of Unknown.
|
||||
Once a fault is found, you can interact with it. Read more on how to
|
||||
[interact with the vulnerabilities](../index.md#interacting-with-the-vulnerabilities).
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ The scanning tools and vulnerabilities database are updated regularly.
|
|||
| Secure scanning tool | Vulnerabilities database updates |
|
||||
|:-------------------------------------------------------------|-------------------------------------------|
|
||||
| [Container Scanning](container_scanning/index.md) | Uses `clair`. The latest `clair-db` version is used for each job by running the [`latest` Docker image tag](https://gitlab.com/gitlab-org/gitlab/blob/438a0a56dc0882f22bdd82e700554525f552d91b/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L37). The `clair-db` database [is updated daily according to the author](https://github.com/arminc/clair-local-scan#clair-server-or-local). |
|
||||
| [Dependency Scanning](dependency_scanning/index.md) | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for NPM packages), and `gemnasium` (GitLab's own tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
|
||||
| [Dependency Scanning](dependency_scanning/index.md) | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for NPM packages), and `gemnasium` (the GitLab tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
|
||||
| [Dynamic Application Security Testing (DAST)](dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/master/Dockerfile#L1). The scanning rules are downloaded at scan runtime. |
|
||||
| [Static Application Security Testing (SAST)](sast/index.md) | Relies exclusively on [the tools GitLab wraps](sast/index.md#supported-languages-and-frameworks). The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. |
|
||||
|
||||
|
|
|
|||
|
|
@ -431,7 +431,7 @@ GFM recognizes the following:
|
|||
| merge request | `!123` | `namespace/project!123` | `project!123` |
|
||||
| snippet | `$123` | `namespace/project$123` | `project$123` |
|
||||
| epic **(ULTIMATE)** | `&123` | `group1/subgroup&123` | |
|
||||
| vulnerability **(ULTIMATE)** | `[vulnerability:123]` | `[vulnerability:namespace/project/123]` | `[vulnerability:project/123]` |
|
||||
| vulnerability **(ULTIMATE)** (1)| `[vulnerability:123]` | `[vulnerability:namespace/project/123]` | `[vulnerability:project/123]` |
|
||||
| label by ID | `~123` | `namespace/project~123` | `project~123` |
|
||||
| one-word label by name | `~bug` | `namespace/project~bug` | `project~bug` |
|
||||
| multi-word label by name | `~"feature request"` | `namespace/project~"feature request"` | `project~"feature request"` |
|
||||
|
|
@ -441,10 +441,12 @@ GFM recognizes the following:
|
|||
| multi-word milestone by name | `%"release candidate"` | `namespace/project%"release candidate"` | `project%"release candidate"` |
|
||||
| specific commit | `9ba12248` | `namespace/project@9ba12248` | `project@9ba12248` |
|
||||
| commit range comparison | `9ba12248...b19a04f5` | `namespace/project@9ba12248...b19a04f5` | `project@9ba12248...b19a04f5` |
|
||||
| repository file references | `[README](doc/README)` | | |
|
||||
| repository file line references | `[README](doc/README#L13)` | | |
|
||||
| repository file references | `[README](doc/README.md)` | | |
|
||||
| repository file line references | `[README](doc/README.md#L13)` | | |
|
||||
| [alert](../operations/incident_management/alerts.md) | `^alert#123` | `namespace/project^alert#123` | `project^alert#123` |
|
||||
|
||||
1. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222483) in GitLab 13.7.
|
||||
|
||||
For example, referencing an issue by using `#123` will format the output as a link
|
||||
to issue number 123 with text `#123`. Likewise, a link to issue number 123 will be
|
||||
recognized and formatted with text `#123`.
|
||||
|
|
|
|||
|
|
@ -4,95 +4,81 @@ group: Package
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Project as a package registry
|
||||
# Store all of your packages in one GitLab project
|
||||
|
||||
Using the features of the package registry, it is possible to use one project to store all of your packages.
|
||||
You can store all of your packages in one project's Package Registry. Rather than using
|
||||
a GitLab repository to store code, you can use the repository to store all your packages.
|
||||
Then you can configure your remote repositories to point to the project in GitLab.
|
||||
|
||||
This guide mirrors the creation of [this package registry](https://gitlab.com/sabrams/my-package-registry).
|
||||
You might want to do this because:
|
||||
|
||||
For the video version, see [Single Project Package Registry Demo](https://youtu.be/ui2nNBwN35c).
|
||||
|
||||
## How does this work?
|
||||
|
||||
You might be wondering "how is it possible to upload two packages from different codebases to the same project on GitLab?".
|
||||
|
||||
It is easy to forget that a package on GitLab belongs to a project, but a project does not have to be a code repository.
|
||||
The code used to build your packages can be stored anywhere - maybe it is another project on GitLab, or maybe a completely
|
||||
different system altogether. All that matters is that when you configure your remote repositories for those packages, you
|
||||
point them at the same project on GitLab.
|
||||
|
||||
## Why would I do this?
|
||||
|
||||
There are a few reasons you might want to publish all your packages to one project on GitLab:
|
||||
|
||||
1. You want to publish your packages on GitLab, but to a project that is different from where your code is stored.
|
||||
1. You would like to group packages together in ways that make sense for your usage (such as all NPM packages in one project,
|
||||
all packages being used by a specific department in one project, or all private packages in one project)
|
||||
1. You want to use one remote for all of your packages when installing them into other projects.
|
||||
1. You would like to migrate your packages to a single place on GitLab from a third-party package registry and do not
|
||||
want to worry about setting up separate projects for each package.
|
||||
1. You want to have your CI pipelines build all of your packages to one project so the individual responsible for
|
||||
validating packages can manage them all in one place.
|
||||
- You want to publish your packages in GitLab, but to a different project from where your code is stored.
|
||||
- You want to group packages together in one project. For example, you might want to put all NPM packages,
|
||||
or all packages for a specific department, or all private packages in the same project.
|
||||
- When you install packages for other projects, you want to use one remote.
|
||||
- You want to migrate your packages from a third-party package registry to a single place in GitLab and do not
|
||||
want to worry about setting up separate projects for each package.
|
||||
- You want to have your CI/CD pipelines build all of your packages to one project, so the person responsible for
|
||||
validating packages can manage them all in one place.
|
||||
|
||||
## Example walkthrough
|
||||
|
||||
There is no functionality specific to this feature. All we are doing is taking advantage of functionality available in each
|
||||
of the package management systems to publish packages of different types to the same place.
|
||||
No functionality is specific to this feature. Instead, we're taking advantage of the functionality
|
||||
of each package management system to publish different package types to the same place.
|
||||
|
||||
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
Watch a video of how to add Maven, NPM, and Conan packages to [the same project](https://youtu.be/ui2nNBwN35c).
|
||||
- [View an example project](https://gitlab.com/sabrams/my-package-registry/-/packages).
|
||||
|
||||
## Store different package types in one GitLab project
|
||||
|
||||
Let's take a look at how you might create a public place to hold all of your public packages.
|
||||
|
||||
### Create a project
|
||||
1. Create a new project in GitLab. The project doesn't require any code or content. Note the project ID
|
||||
that's displayed on the project overview page.
|
||||
1. Create an access token. All package types in the Package Registry are accessible by using
|
||||
[GitLab personal access tokens](../../profile/personal_access_tokens.md).
|
||||
If you're using CI/CD, you can use CI job tokens (`CI_JOB_TOKEN`) to authenticate.
|
||||
1. Configure your local project and publish the package.
|
||||
|
||||
First, create a new project on GitLab. It does not have to have any code or content. Make note of the project ID
|
||||
displayed on the project overview page for use later in this process.
|
||||
You can upload all types of packages to the same project, or
|
||||
split things up based on package type or package visibility level.
|
||||
|
||||
### Create an access token
|
||||
### NPM
|
||||
|
||||
All of the package repositories available on the GitLab package registry are accessible using [GitLab personal access
|
||||
tokens](../../profile/personal_access_tokens.md).
|
||||
If you're using NPM, create an `.npmrc` file. Add the appropriate URL for publishing
|
||||
packages to your project. Finally, add a section to your `package.json` file.
|
||||
|
||||
While using CI, you can alternatively use CI job tokens (`CI_JOB_TOKEN`) to authenticate.
|
||||
Follow the instructions in the
|
||||
[GitLab NPM Registry documentation](../npm_registry/index.md#authenticate-to-the-package-registry). After
|
||||
you do this, you can publish your NPM package to your project using `npm publish`, as described in the
|
||||
[publishing packages](../npm_registry/index.md#publish-an-npm-package) section.
|
||||
|
||||
### Configure your local project for the GitLab registry and upload
|
||||
### Maven
|
||||
|
||||
There are many ways to use this feature. You can upload all types of packages to the same project,
|
||||
split things up based on package type, or package visibility level.
|
||||
|
||||
The purpose of this tutorial is to demonstrate the root idea that one project can hold many unrelated
|
||||
packages, and to allow you to discover the best way to use this functionality yourself.
|
||||
|
||||
#### NPM
|
||||
|
||||
If you are using NPM, this involves creating an `.npmrc` file and adding the appropriate URL for uploading packages
|
||||
to your project using your project ID, then adding a section to your `package.json` file with a similar URL.
|
||||
|
||||
Follow
|
||||
the instructions in the [GitLab NPM Registry documentation](../npm_registry/index.md#authenticate-to-the-package-registry). After
|
||||
you do this, you can push your NPM package to your project using `npm publish`, as described in the
|
||||
[publishing packages](../npm_registry/index.md#publish-an-npm-package) section of the docs.
|
||||
|
||||
#### Maven
|
||||
|
||||
If you are using Maven, this involves updating your `pom.xml` file with distribution sections, including the
|
||||
If you are using Maven, you update your `pom.xml` file with distribution sections. These updates include the
|
||||
appropriate URL for your project, as described in the [GitLab Maven Repository documentation](../maven_repository/index.md#project-level-maven-endpoint).
|
||||
Then, you need to add a `settings.xml` file and [include your access token](../maven_repository/index.md#authenticate-with-a-personal-access-token-in-maven).
|
||||
Now you can [deploy Maven packages](../maven_repository/index.md#publish-a-package) to your project.
|
||||
Now you can [publish Maven packages](../maven_repository/index.md#publish-a-package) to your project.
|
||||
|
||||
#### Conan
|
||||
### Conan
|
||||
|
||||
For Conan, first you need to add GitLab as a Conan registry remote. Follow the instructions in the [GitLab Conan Repository docs](../conan_repository/index.md#add-the-package-registry-as-a-conan-remote)
|
||||
to do so. Then, create your package using the plus-separated (`+`) project path as your Conan user. For example,
|
||||
if your project is located at `https://gitlab.com/foo/bar/my-proj`, then you can [create your Conan package](../conan_repository/index.md)
|
||||
using `conan create . foo+bar+my-proj/channel`, where `channel` is your package channel (such as `stable` or `beta`). After your package
|
||||
is created, you are ready to [upload your package](../conan_repository/index.md#publish-a-conan-package) depending on your final package recipe. For example:
|
||||
For Conan, you need to add GitLab as a Conan registry remote. Follow the instructions in the
|
||||
[GitLab Conan Repository docs](../conan_repository/index.md#add-the-package-registry-as-a-conan-remote).
|
||||
Then, create your package using the plus-separated (`+`) project path as your Conan user. For example,
|
||||
if your project is located at `https://gitlab.com/foo/bar/my-proj`,
|
||||
[create your Conan package](../conan_repository/index.md) using `conan create . foo+bar+my-proj/channel`.
|
||||
`channel` is your package channel (such as `stable` or `beta`).
|
||||
|
||||
After you create your package, you're ready to [publish your package](../conan_repository/index.md#publish-a-conan-package),
|
||||
depending on your final package recipe. For example:
|
||||
|
||||
```shell
|
||||
CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan upload MyPackage/1.0.0@foo+bar+my-proj/channel --all --remote=gitlab
|
||||
```
|
||||
|
||||
#### Composer
|
||||
### All other package types
|
||||
|
||||
It is currently not possible to publish a Composer package to a project that is different from where its code resides.
|
||||
|
||||
If you attempt to publish a Composer package to a different project, you get a `404 Branch Not Found`
|
||||
or `404 Tag Not Found` error.
|
||||
[All package types supported by GitLab](../index.md) can be published in
|
||||
the same GitLab project. In previous releases, not all package types could
|
||||
be published in the same project.
|
||||
|
|
|
|||
|
|
@ -92,7 +92,9 @@ The following table depicts the various user permission levels in a project.
|
|||
| View Error Tracking list | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create new merge request | | ✓ | ✓ | ✓ | ✓ |
|
||||
| View metrics dashboard annotations | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Archive/reopen requirements **(ULTIMATE)** | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create/edit requirements **(ULTIMATE)** | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Import requirements **(ULTIMATE)** | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create new [test case](../ci/test_cases/index.md) | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Archive [test case](../ci/test_cases/index.md) | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Move [test case](../ci/test_cases/index.md) | | ✓ | ✓ | ✓ | ✓ |
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ which apply to the entire Web IDE screen.
|
|||
|
||||
## Behavior
|
||||
|
||||
The following settings allow you to customize the behavior of GitLab's layout
|
||||
The following settings allow you to customize the behavior of the GitLab layout
|
||||
and default views of your dashboard and the projects' landing pages.
|
||||
|
||||
### Layout width
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ Enter the further details on the page as described in the following table.
|
|||
| `Jira API URL` | The base URL to the Jira instance API. Web URL value is used if not set. For example, `https://jira-api.example.com`. Leave this field blank (or use the same value of `Web URL`) if using **Jira Cloud**. |
|
||||
| `Username or Email` | Created in [configuring Jira](#configuring-jira) step. Use `username` for **Jira Server** or `email` for **Jira Cloud**. |
|
||||
| `Password/API token` |Created in [configuring Jira](#configuring-jira) step. Use `password` for **Jira Server** or `API token` for **Jira Cloud**. |
|
||||
| `Transition ID` | Required for closing Jira issues via commits or merge requests. This is the ID of a transition in Jira that moves issues to a desired state. (See [Obtaining a transition ID](#obtaining-a-transition-id).) If you insert multiple transition IDs separated by `,` or `;`, the issue is moved to each state, one after another, using the given order. |
|
||||
| `Jira workflow transition IDs` | Required for closing Jira issues via commits or merge requests. These are the IDs of transitions in Jira that move issues to a particular state. (See [Obtaining a transition ID](#obtaining-a-transition-id).) If you insert multiple transition IDs separated by `,` or `;`, the issue is moved to each state, one after another, using the given order. In GitLab 13.6 and earlier, field was called `Transition ID`. |
|
||||
|
||||
To enable users to view Jira issues inside the GitLab project, select **Enable Jira issues** and enter a Jira project key. **(PREMIUM)**
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ must be set.
|
|||
|
||||
While you can view and manage the full details of an issue on the [issue page](#issue-page),
|
||||
you can also work with multiple issues at a time using the [Issues List](#issues-list),
|
||||
[Issue Boards](#issue-boards), Issue references, and [Epics](#epics)**(PREMIUM)**.
|
||||
[Issue Boards](#issue-boards), Issue references, and [Epics](#epics). **(PREMIUM)**
|
||||
|
||||
Key actions for issues include:
|
||||
|
||||
|
|
|
|||
|
|
@ -186,7 +186,7 @@ The plain text title and description of the issue fill the top center of the iss
|
|||
The description fully supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm),
|
||||
allowing many formatting options.
|
||||
|
||||
> [In GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/10103) and later, changes to an issue's description are listed in the [issue history](#issue-history).**(STARTER)**
|
||||
> [In GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/10103) and later, changes to an issue's description are listed in the [issue history](#issue-history). **(STARTER)**
|
||||
|
||||
### Mentions
|
||||
|
||||
|
|
|
|||
|
|
@ -15684,6 +15684,9 @@ msgstr ""
|
|||
msgid "JiraService|Events for %{noteable_model_name} are disabled."
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|For example, 12, 24"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|If different from Web URL"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -15708,21 +15711,21 @@ msgstr ""
|
|||
msgid "JiraService|Jira project key"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|Jira workflow transition IDs"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|Open Jira"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|Password or API token"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|Set transition IDs for Jira workflow transitions. %{link_start}Learn more%{link_end}"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|This feature requires a Premium plan."
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|Transition ID(s)"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|Use , or ; to separate multiple transition IDs"
|
||||
msgstr ""
|
||||
|
||||
msgid "JiraService|Use a password for server version and an API token for cloud version"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -18,6 +18,10 @@ RSpec.describe 'Profile > Personal Access Tokens', :js do
|
|||
find("#created-personal-access-token").value
|
||||
end
|
||||
|
||||
def feed_token
|
||||
find("#feed_token").value
|
||||
end
|
||||
|
||||
def disallow_personal_access_token_saves!
|
||||
allow(PersonalAccessTokens::CreateService).to receive(:new).and_return(pat_create_service)
|
||||
|
||||
|
|
@ -112,4 +116,26 @@ RSpec.describe 'Profile > Personal Access Tokens', :js do
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe "feed token" do
|
||||
context "when enabled" do
|
||||
it "displays feed token" do
|
||||
allow(Gitlab::CurrentSettings).to receive(:disable_feed_token).and_return(false)
|
||||
visit profile_personal_access_tokens_path
|
||||
|
||||
expect(page).to have_content("Your feed token is used to authenticate you when your RSS reader loads a personalized RSS feed or when your calendar application loads a personalized calendar, and is included in those feed URLs.")
|
||||
expect(feed_token).to eq(user.feed_token)
|
||||
end
|
||||
end
|
||||
|
||||
context "when disabled" do
|
||||
it "does not display feed token" do
|
||||
allow(Gitlab::CurrentSettings).to receive(:disable_feed_token).and_return(true)
|
||||
visit profile_personal_access_tokens_path
|
||||
|
||||
expect(page).not_to have_content("Your feed token is used to authenticate you when your RSS reader loads a personalized RSS feed or when your calendar application loads a personalized calendar, and is included in those feed URLs.")
|
||||
expect(page).not_to have_css("#feed_token")
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -66,6 +66,19 @@ RSpec.describe JiraService do
|
|||
end
|
||||
end
|
||||
|
||||
describe '#fields' do
|
||||
let(:service) { create(:jira_service) }
|
||||
|
||||
subject(:fields) { service.fields }
|
||||
|
||||
it 'includes transition help link' do
|
||||
transition_id_field = fields.find { |field| field[:name] == 'jira_issue_transition_id' }
|
||||
|
||||
expect(transition_id_field[:title]).to eq('Jira workflow transition IDs')
|
||||
expect(transition_id_field[:help]).to include('/help/user/project/integrations/jira')
|
||||
end
|
||||
end
|
||||
|
||||
describe 'Associations' do
|
||||
it { is_expected.to belong_to :project }
|
||||
it { is_expected.to have_one :service_hook }
|
||||
|
|
|
|||
Loading…
Reference in New Issue