Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
282be3e7a2
commit
d2d9cb1027
|
|
@ -22,26 +22,26 @@ Set the title to: `Description of the original issue`
|
|||
- [ ] Create a new branch prefixing it with `security-`.
|
||||
- [ ] Create a merge request targeting `master` on `gitlab.com/gitlab-org/security` and use the [Security Release merge request template].
|
||||
- [ ] If this includes a breaking change, make sure to include a mention of it for the relevant versions in [`doc/update/index.md`](https://gitlab.com/gitlab-org/security/gitlab/-/blob/master/doc/update/index.md#version-specific-upgrading-instructions)
|
||||
* See if the [breaking changes workflow] applies
|
||||
- See if the [breaking changes workflow] applies
|
||||
|
||||
After your merge request has been approved according to our [approval guidelines] and by a team member of the AppSec team, you're ready to prepare the backports
|
||||
|
||||
## Backports
|
||||
|
||||
- [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches.
|
||||
* The 3 stable branches correspond to the versions in the title of the [Security Release Tracking Issue].
|
||||
* At this point, it might be easy to squash the commits from the MR into one
|
||||
* You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
|
||||
- The 3 stable branches correspond to the versions in the title of the [Security Release Tracking Issue].
|
||||
- At this point, it might be easy to squash the commits from the MR into one
|
||||
- You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
|
||||
- [ ] Create each MR targeting the stable branch `X-Y-stable`, using the [Security Release merge request template].
|
||||
* Every merge request will have its own set of to-dos, so make sure to complete those.
|
||||
- Every merge request will have its own set of to-dos, so make sure to complete those.
|
||||
- [ ] On the "Related merge requests" section, ensure that `4` merge requests are associated: The one targeting `master` and the `3` backports.
|
||||
- [ ] If this issue requires less than `4` merge requests, add the ~"reduced backports" label.
|
||||
|
||||
## Assigning to a release
|
||||
|
||||
- [ ] **IMPORTANT**: When this issue is ready for release (Default branch MR and backports are approved and ready to be merged), apply the ~"security-target" label.
|
||||
* The `gitlab-release-tools-bot` evaluates and links issues with the label to the next planned security release tracking issue. If the bot finds the issue is not ready to be included in the security release, it will leave a comment on the issue explaining what needs to be done.
|
||||
* This issue will only be included in a security release if it is successfully linked to the security release tracking issue.
|
||||
- The `gitlab-release-tools-bot` evaluates and links issues with the label to the next planned security release tracking issue. If the bot finds the issue is not ready to be included in the security release, it will leave a comment on the issue explaining what needs to be done.
|
||||
- This issue will only be included in a security release if it is successfully linked to the security release tracking issue.
|
||||
|
||||
## Documentation and final details
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ After your merge request has been approved according to our [approval guidelines
|
|||
- [ ] Ensure `~severity::x` label is on this issue, all associated issues, and merge requests
|
||||
- [ ] Ensure the [Links section](#links) is completed.
|
||||
- [ ] Add the GitLab [versions](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md#versions-affected) and editions affected to the [details section](#details)
|
||||
* The Git history of the files affected may help you associate the issue with a [release](https://about.gitlab.com/releases/)
|
||||
- The Git history of the files affected may help you associate the issue with a [release](https://about.gitlab.com/releases/)
|
||||
- [ ] Fill in any upgrade notes that users may need to take into account in the [details section](#details)
|
||||
- [ ] Add Yes/No and further details if needed to the migration and settings columns in the [details section](#details)
|
||||
- [ ] Add the nickname of the external user who found the issue (and/or HackerOne profile) to the Thanks row in the [details section](#details)
|
||||
|
|
@ -58,22 +58,22 @@ After your merge request has been approved according to our [approval guidelines
|
|||
|
||||
### Links
|
||||
|
||||
| Description | Link |
|
||||
| -------- | -------- |
|
||||
| Description | Link |
|
||||
| -------------------------------------------------------------- | ------ |
|
||||
| Issue on [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) | #TODO |
|
||||
| CVE ID request on [`gitlab-org/cves`](https://gitlab.com/gitlab-org/cves/-/issues?sort=created_date&state=opened) | #TODO for AppSec |
|
||||
|
||||
### Details
|
||||
|
||||
| Description | Details | Further details|
|
||||
| -------- | -------- | -------- |
|
||||
| Versions affected | X.Y | |
|
||||
| GitLab EE only | Yes/No | |
|
||||
| Upgrade notes | | |
|
||||
| GitLab Settings updated | Yes/No| |
|
||||
| Migration required | Yes/No | |
|
||||
| Breaking change to UI or public API | Yes/No | <!-- How should the breaking change be communicated? --> |
|
||||
| Thanks | | |
|
||||
| Description | Details | Further details |
|
||||
|-------------------------------------|---------|----------------------------------------------------------|
|
||||
| Versions affected | X.Y | |
|
||||
| GitLab EE only | Yes/No | |
|
||||
| Upgrade notes | | |
|
||||
| GitLab Settings updated | Yes/No | |
|
||||
| Migration required | Yes/No | |
|
||||
| Breaking change to UI or public API | Yes/No | <!-- How should the breaking change be communicated? --> |
|
||||
| Thanks | | |
|
||||
|
||||
[security process for developers]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
|
||||
[secpick documentation]: https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/utilities/secpick_script.md
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ export const containsSensitiveToken = (message) => {
|
|||
{
|
||||
// eslint-disable-next-line @gitlab/require-i18n-strings
|
||||
name: 'Feed Token',
|
||||
regex: 'feed_token=((glft-)?[0-9a-zA-Z_-]{20}|glft-[a-h0-9]+-[0-9]+_)',
|
||||
regex: 'feed_token=[0-9a-zA-Z_-]{20}|glft-[0-9a-zA-Z_-]{20}|glft-[a-h0-9]+-[0-9]+_',
|
||||
},
|
||||
{
|
||||
name: 'GitLab OAuth Application Secret',
|
||||
|
|
@ -45,9 +45,21 @@ export const containsSensitiveToken = (message) => {
|
|||
regex: `glffct-[0-9a-zA-Z_-]{20}`,
|
||||
},
|
||||
{
|
||||
name: 'GitLab runner token',
|
||||
name: 'GitLab Runner Token',
|
||||
regex: 'glrt-[0-9a-zA-Z_-]{20}',
|
||||
},
|
||||
{
|
||||
name: 'GitLab Incoming Mail Token',
|
||||
regex: 'glimt-[0-9a-zA-Z_-]{25}',
|
||||
},
|
||||
{
|
||||
name: 'GitLab Agent for Kubernetes Token',
|
||||
regex: 'glagent-[0-9a-zA-Z_-]{50}',
|
||||
},
|
||||
{
|
||||
name: 'GitLab Pipeline Trigger Token',
|
||||
regex: 'glptt-[0-9a-zA-Z_-]{40}',
|
||||
},
|
||||
];
|
||||
|
||||
for (const rule of sensitiveDataPatterns) {
|
||||
|
|
@ -60,12 +72,8 @@ export const containsSensitiveToken = (message) => {
|
|||
};
|
||||
|
||||
export async function confirmSensitiveAction(prompt = i18n.defaultPrompt) {
|
||||
const confirmed = await confirmAction(prompt, {
|
||||
return confirmAction(prompt, {
|
||||
primaryBtnVariant: 'danger',
|
||||
primaryBtnText: i18n.primaryBtnText,
|
||||
});
|
||||
if (!confirmed) {
|
||||
return false;
|
||||
}
|
||||
return true;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,38 @@
|
|||
<script>
|
||||
import { GlBadge } from '@gitlab/ui';
|
||||
import { __ } from '~/locale';
|
||||
|
||||
export default {
|
||||
name: 'ProjectListItemInactiveBadge',
|
||||
i18n: {
|
||||
archived: __('Archived'),
|
||||
},
|
||||
components: {
|
||||
GlBadge,
|
||||
},
|
||||
props: {
|
||||
project: {
|
||||
type: Object,
|
||||
required: true,
|
||||
},
|
||||
},
|
||||
computed: {
|
||||
inactiveBadge() {
|
||||
if (this.project.archived) {
|
||||
return {
|
||||
variant: 'info',
|
||||
text: this.$options.i18n.archived,
|
||||
};
|
||||
}
|
||||
|
||||
return null;
|
||||
},
|
||||
},
|
||||
};
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<gl-badge v-if="inactiveBadge" :variant="inactiveBadge.variant" size="sm">{{
|
||||
inactiveBadge.text
|
||||
}}</gl-badge>
|
||||
</template>
|
||||
|
|
@ -11,6 +11,7 @@ import {
|
|||
} from '@gitlab/ui';
|
||||
import uniqueId from 'lodash/uniqueId';
|
||||
|
||||
import ProjectListItemInactiveBadge from 'ee_else_ce/vue_shared/components/projects_list/project_list_item_inactive_badge.vue';
|
||||
import { VISIBILITY_TYPE_ICON, PROJECT_VISIBILITY_TYPE } from '~/visibility_level/constants';
|
||||
import { ACCESS_LEVEL_LABELS, ACCESS_LEVEL_NO_ACCESS_INTEGER } from '~/access_level/constants';
|
||||
import { FEATURABLE_ENABLED } from '~/featurable/constants';
|
||||
|
|
@ -32,8 +33,6 @@ export default {
|
|||
forks: __('Forks'),
|
||||
issues: __('Issues'),
|
||||
mergeRequests: __('Merge requests'),
|
||||
pendingDeletion: __('Pending deletion'),
|
||||
archived: __('Archived'),
|
||||
topics: __('Topics'),
|
||||
topicsPopoverTargetText: __('+ %{count} more'),
|
||||
moreTopics: __('More topics'),
|
||||
|
|
@ -54,6 +53,7 @@ export default {
|
|||
TimeAgoTooltip,
|
||||
DeleteModal,
|
||||
ListActions,
|
||||
ProjectListItemInactiveBadge,
|
||||
},
|
||||
directives: {
|
||||
GlTooltip: GlTooltipDirective,
|
||||
|
|
@ -202,26 +202,6 @@ export default {
|
|||
isActionDeleteLoading() {
|
||||
return this.project.actionLoadingStates[ACTION_DELETE];
|
||||
},
|
||||
isPendingDeletion() {
|
||||
return Boolean(this.project.markedForDeletionOn);
|
||||
},
|
||||
inactiveBadge() {
|
||||
if (this.isPendingDeletion) {
|
||||
return {
|
||||
variant: 'warning',
|
||||
text: this.$options.i18n.pendingDeletion,
|
||||
};
|
||||
}
|
||||
|
||||
if (this.project.archived) {
|
||||
return {
|
||||
variant: 'info',
|
||||
text: this.$options.i18n.archived,
|
||||
};
|
||||
}
|
||||
|
||||
return null;
|
||||
},
|
||||
},
|
||||
methods: {
|
||||
topicPath(topic) {
|
||||
|
|
@ -353,13 +333,7 @@ export default {
|
|||
:class="showProjectIcon ? 'gl-pl-12' : 'gl-pl-10'"
|
||||
>
|
||||
<div class="gl-display-flex gl-align-items-center gl-gap-x-3 gl-md-h-9">
|
||||
<gl-badge
|
||||
v-if="inactiveBadge"
|
||||
:variant="inactiveBadge.variant"
|
||||
size="sm"
|
||||
data-testid="inactive-badge"
|
||||
>{{ inactiveBadge.text }}</gl-badge
|
||||
>
|
||||
<project-list-item-inactive-badge :project="project" />
|
||||
<gl-link
|
||||
v-gl-tooltip="$options.i18n.stars"
|
||||
:href="starsHref"
|
||||
|
|
|
|||
|
|
@ -75,6 +75,7 @@ module Integrations
|
|||
:password,
|
||||
:priority,
|
||||
:project_key,
|
||||
:project_keys,
|
||||
:project_name,
|
||||
:project_url,
|
||||
:recipients,
|
||||
|
|
|
|||
|
|
@ -10,6 +10,8 @@
|
|||
module TimeTrackable
|
||||
extend ActiveSupport::Concern
|
||||
|
||||
include Gitlab::Utils::StrongMemoize
|
||||
|
||||
included do
|
||||
attr_reader :time_spent, :time_spent_user, :spent_at, :summary
|
||||
|
||||
|
|
@ -22,6 +24,23 @@ module TimeTrackable
|
|||
|
||||
has_many :timelogs, dependent: :destroy, autosave: true # rubocop:disable Cop/ActiveRecordDependent
|
||||
after_initialize :set_time_estimate_default_value
|
||||
after_save :clear_memoized_total_time_spent
|
||||
end
|
||||
|
||||
def clear_memoized_total_time_spent
|
||||
clear_memoization(:total_time_spent)
|
||||
end
|
||||
|
||||
def reset
|
||||
clear_memoized_total_time_spent
|
||||
|
||||
super
|
||||
end
|
||||
|
||||
def reload(*args)
|
||||
clear_memoized_total_time_spent
|
||||
|
||||
super(*args)
|
||||
end
|
||||
|
||||
# rubocop:disable Gitlab/ModuleWithInstanceVariables
|
||||
|
|
@ -54,6 +73,7 @@ module TimeTrackable
|
|||
# (some issuable might have total time spent that's negative because a validation was missing.)
|
||||
sum.clamp(-Timelog::MAX_TOTAL_TIME_SPENT, Timelog::MAX_TOTAL_TIME_SPENT)
|
||||
end
|
||||
strong_memoize_attr :total_time_spent
|
||||
|
||||
def human_total_time_spent
|
||||
Gitlab::TimeTrackingFormatter.output(total_time_spent)
|
||||
|
|
|
|||
|
|
@ -59,6 +59,10 @@ module Integrations
|
|||
# We should use username/password for Jira Server and email/api_token for Jira Cloud,
|
||||
# for more information check: https://gitlab.com/gitlab-org/gitlab-foss/issues/49936.
|
||||
|
||||
before_save :copy_project_key_to_project_keys,
|
||||
if: -> {
|
||||
Feature.disabled?(:jira_multiple_project_keys, project&.group)
|
||||
}
|
||||
after_commit :update_deployment_type, on: [:create, :update], if: :update_deployment_type?
|
||||
|
||||
enum comment_detail: {
|
||||
|
|
@ -131,6 +135,10 @@ module Integrations
|
|||
|
||||
field :jira_issue_transition_id, api_only: true
|
||||
|
||||
field :project_keys,
|
||||
required: false,
|
||||
api_only: true
|
||||
|
||||
# TODO: we can probably just delegate as part of
|
||||
# https://gitlab.com/gitlab-org/gitlab/issues/29404
|
||||
# These fields are API only, so no field definition is required.
|
||||
|
|
@ -691,6 +699,10 @@ module Integrations
|
|||
end
|
||||
end
|
||||
|
||||
def copy_project_key_to_project_keys
|
||||
data_fields.project_keys = [project_key]
|
||||
end
|
||||
|
||||
def jira_cloud?
|
||||
server_info['deploymentType'] == 'Cloud' || self.class.valid_jira_cloud_url?(client_url)
|
||||
end
|
||||
|
|
|
|||
|
|
@ -78,6 +78,10 @@ class ServiceResponse
|
|||
Array.wrap(message)
|
||||
end
|
||||
|
||||
def cause
|
||||
ActiveSupport::StringInquirer.new(reason.to_s)
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
attr_writer :status, :message, :http_status, :payload, :reason
|
||||
|
|
|
|||
|
|
@ -42,6 +42,8 @@ module Timelogs
|
|||
if !timelog.save
|
||||
error_in_save(timelog)
|
||||
else
|
||||
issuable.reset
|
||||
|
||||
SystemNoteService.created_timelog(issuable, issuable.project, current_user, timelog)
|
||||
|
||||
issuable_base_service.execute_hooks(issuable, 'update', old_associations: old_associations)
|
||||
|
|
|
|||
|
|
@ -186,10 +186,12 @@ exceptions:
|
|||
- RHEL
|
||||
- RPC
|
||||
- RPM
|
||||
- RPO
|
||||
- RPS
|
||||
- RSA
|
||||
- RSS
|
||||
- RTC
|
||||
- RTO
|
||||
- RVM
|
||||
- SAAS
|
||||
- SAML
|
||||
|
|
@ -254,6 +256,7 @@ exceptions:
|
|||
- VCS
|
||||
- VPC
|
||||
- VPN
|
||||
- WAF
|
||||
- WEBP
|
||||
- WIP
|
||||
- WSL
|
||||
|
|
|
|||
|
|
@ -471,6 +471,7 @@ injective
|
|||
innersource
|
||||
innersourcing
|
||||
inodes
|
||||
Instrumentor
|
||||
interdependencies
|
||||
interdependency
|
||||
interruptible
|
||||
|
|
@ -656,6 +657,7 @@ Opsgenie
|
|||
Opstrace
|
||||
ORMs
|
||||
OS
|
||||
osquery
|
||||
OSs
|
||||
OTel
|
||||
outdent
|
||||
|
|
@ -680,6 +682,7 @@ PgBouncer
|
|||
pgFormatter
|
||||
pgLoader
|
||||
pgMustard
|
||||
pgvector
|
||||
Phabricator
|
||||
phaser
|
||||
phasers
|
||||
|
|
@ -997,6 +1000,7 @@ syslog
|
|||
systemd
|
||||
tablespace
|
||||
tablespaces
|
||||
Tamland
|
||||
tanuki
|
||||
taskscaler
|
||||
tcpdump
|
||||
|
|
|
|||
|
|
@ -0,0 +1,117 @@
|
|||
---
|
||||
stage: Govern
|
||||
group: Authentication
|
||||
info: >-
|
||||
To determine the technical writer assigned to the Stage/Group associated with
|
||||
this page, see
|
||||
https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
# Google Cloud Integration API
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab.com
|
||||
**Status:** Experiment
|
||||
|
||||
## Project-level Google Cloud integration scripts
|
||||
|
||||
DETAILS:
|
||||
**Status:** Experiment
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141870) in GitLab 16.10. This feature is an [Experiment](../policy/experiment-beta-support.md).
|
||||
|
||||
### Workload identity federation creation script
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141870) in GitLab 16.10.
|
||||
|
||||
Users with at least the Maintainer role for the project can use the following endpoint to
|
||||
query a shell script that creates and configures the workload identity
|
||||
federation in Google Cloud:
|
||||
|
||||
```plaintext
|
||||
GET /projects/:id/google_cloud/setup/wlif.sh
|
||||
```
|
||||
|
||||
Supported attributes:
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
|---------------------------------------------------|------------------|----------|------------------------------------------------------------------------------------------------------------------|
|
||||
| `id` | integer | Yes | The ID a project. |
|
||||
| `google_cloud_project_id` | string | Yes | Google Cloud Project ID for the workload identity federation. |
|
||||
| `google_cloud_workload_identity_pool_id` | string | No | ID of the Google Cloud workload identity pool to create. Defaults to `gitlab-wlif`. |
|
||||
| `google_cloud_workload_identity_pool_display_name`| string | No | Display name of the Google Cloud workload identity pool to create. Defaults to `WLIF for GitLab integration`. |
|
||||
| `google_cloud_workload_identity_pool_provider_id` | string | No | ID of the Google Cloud workload identity pool provider to create. Defaults to `gitlab-wlif-oidc-provider`. |
|
||||
| `google_cloud_workload_identity_pool_provider_display_name`| string | No | Display name of the Google Cloud workload identity pool provider to created. Defaults to `GitLab OIDC provider`. |
|
||||
|
||||
Example request:
|
||||
|
||||
```shell
|
||||
curl --request GET \
|
||||
--header "PRIVATE-TOKEN: <your_access_token>" \
|
||||
--url "https://gitlab.com/api/v4/projects/<your_project_id>/google_cloud/setup/wlif.sh"
|
||||
```
|
||||
|
||||
### Script to setup a Google Cloud integration
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144787) in GitLab 16.10.
|
||||
|
||||
Users with at least the Maintainer role for the project can use the following endpoint to
|
||||
query a shell script to set up a Google Cloud integration:
|
||||
|
||||
```plaintext
|
||||
GET /projects/:id/google_cloud/setup/integrations.sh
|
||||
```
|
||||
|
||||
Only the [Google Artifact Registry](../user/project/integrations/google_artifact_registry.md)
|
||||
integration is supported.
|
||||
The script creates IAM policies to access Google Artifact Registry:
|
||||
|
||||
- [Artifact Registry Reader](https://cloud.google.com/artifact-registry/docs/access-control#roles)
|
||||
role is granted to members with at least Reporter role
|
||||
- [Artifact Registry Writer](https://cloud.google.com/artifact-registry/docs/access-control#roles)
|
||||
role is granted to members with at least Developer role
|
||||
|
||||
Supported attributes:
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
|---------------------------------------------|---------|----------|-----------------------------------------------------------------------------|
|
||||
| `id` | integer | Yes | The ID of a GitLab project. |
|
||||
| `enable_google_cloud_artifact_registry` | boolean | Yes | Flag to indicate if Google Artifact Registry integration should be enabled. |
|
||||
| `google_cloud_artifact_registry_project_id` | string | Yes | Google Cloud Project ID for the Artifact Registry. |
|
||||
|
||||
Example request:
|
||||
|
||||
```shell
|
||||
curl --request GET \
|
||||
--header "PRIVATE-TOKEN: <your_access_token>" \
|
||||
--url "https://gitlab.com/api/v4/projects/<your_project_id>/google_cloud/setup/integrations.sh"
|
||||
```
|
||||
|
||||
### Script to configure a Google Cloud project for runner provisioning
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145525) in GitLab 16.10.
|
||||
|
||||
Users with at least the Maintainer role for the project can use the following endpoint to
|
||||
query a shell script to configure a Google Cloud project for runner provisioning and execution:
|
||||
|
||||
```plaintext
|
||||
GET /projects/:id/google_cloud/setup/runner_deployment_project.sh
|
||||
```
|
||||
|
||||
The script performs preparatory configuration steps in the specified Google Cloud project,
|
||||
namely enabling required services and creating a `GRITProvisioner` role and a `grit-provisioner` service account.
|
||||
|
||||
Supported attributes:
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
|---------------------------|---------|----------|----------------------------------------|
|
||||
| `id` | integer | Yes | The ID of a GitLab project. |
|
||||
| `google_cloud_project_id` | string | Yes | The ID of the Google Cloud project. |
|
||||
|
||||
Example request:
|
||||
|
||||
```shell
|
||||
curl --request GET \
|
||||
--header "PRIVATE-TOKEN: <your_access_token>" \
|
||||
--url "https://gitlab.com/api/v4/projects/<your_project_id>/google_cloud/setup/runner_deployment_project.sh?google_cloud_project_id=<your_google_cloud_project_id>"
|
||||
```
|
||||
|
|
@ -348,6 +348,8 @@ The following list of impacted features only represents placeholders that still
|
|||
|
||||
### What's the difference between Cells architecture and GitLab Dedicated?
|
||||
|
||||
We've captured individual thoughts and differences between Cells and Dedicated over [here](infrastructure/diff-between-dedicated.md)
|
||||
|
||||
The new Cells architecture is meant to scale GitLab.com.
|
||||
The way to achieve this is by moving Organizations into Cells, but different Organizations can still share server resources, even if the application provides isolation from other Organizations.
|
||||
But all of them still operate under the existing GitLab SaaS domain name `gitlab.com`.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,495 @@
|
|||
---
|
||||
stage: core platform
|
||||
group: Tenant Scale
|
||||
description: 'Cells: Infrastructure'
|
||||
authors: [ "@skarbek" ]
|
||||
coach: "@andrewn"
|
||||
status:
|
||||
---
|
||||
|
||||
<!-- vale gitlab.FutureTense = NO -->
|
||||
|
||||
# Cells Difference with Dedicated
|
||||
|
||||
## Existing Reads
|
||||
|
||||
1. [Cell Iteration](../index.md#cells-iterations), specifically Cell 1.0
|
||||
1. [GitLab Dedicated](https://about.gitlab.com/dedicated/)
|
||||
1. [GitLab Dedicated technical documentation](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/)
|
||||
|
||||
## GitLab Dedicated Diff
|
||||
|
||||
GitLab Dedicated had a chance to start from a blank slate and only run stable services.
|
||||
GitLab.com is running beta features or auxiliary that GitLab Dedicated doesn't have too.
|
||||
|
||||
### Advanced Search
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Dedicated relies on the GET tooling to provision AWS OpenSearch for tenants.
|
||||
The application is automatically configured by GET to configure the application to leverage this feature.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
GitLab.com leverages two items, one is under heavy development by `group::Global Search`.
|
||||
We have an Elasticsearch cluster which provides application level search capabilities for the vast majority of our customer base.
|
||||
This is currently used for code search as well as searching anything else capable of being searched inside of the GitLab application.
|
||||
The Global Search team are testing the use of Zoekt as an addition to eventually replace code search capabilities.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Accompanying issue in Dedicated](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/4111)
|
||||
|
||||
### Capacity Planning
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
[Tamland](https://gitlab-com.gitlab.io/gl-infra/tamland/) is used.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
[Tamland](https://gitlab-com.gitlab.io/gl-infra/tamland/) is used.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Tamland](https://gitlab-com.gitlab.io/gl-infra/tamland/) will be leveraged the same.
|
||||
The [work for Dedicated](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1118) is complete.
|
||||
Minor work may need to be accomplished to enable for Cells
|
||||
|
||||
### Redis
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Dedicated leverages [GCP Memorystore](https://cloud.google.com/memorystore) product for Redis.
|
||||
_This work is a work in progress, but is supported by the GitLab Environment Toolkit._
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
At the .com scale, we have approximately 13 deployments of Redis all with targeted configurations pending their responsibility and role.
|
||||
These Redis deployments also differ between standard Redis deployments with replicas and Redis Clusters.
|
||||
We have a mix and match based on prioritized work that resolved various pain points as we scaled this service to suite our needs.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
As Cells are a far smaller installation of GitLab, there should be no need to expand our Redis infrastructure as vast as we have for .com.
|
||||
The chosen reference architecture should deploy a sufficiently sized Redis deployment to suit our needs.
|
||||
Observability into the behavior of Redis when our first set of Cells receive customer traffic will need to be monitored closely to determine what areas of improvement we need to bring in.
|
||||
|
||||
### Secret Management
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Dedicated leverages Google Secret Manager for Secret Management.
|
||||
Two types of secrets are leveraged in Dedicated, secrets which are unique per tenant and secrets which are shared per environment.
|
||||
The latter being used strictly for management of tenants, such as with Amp.
|
||||
Thus each GitLab installation has their own set of secrets and some configuration items are stored using that cloud providers secrets service.
|
||||
Instrumentor, the Dedicated tenant provisioning tool is aware of and shares only the necessary secrets between various stages.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
.com leverages KMS already for simplistic items for as well as a wrapper for secrets management for Chef runs on Virtual Machines.
|
||||
Most secrets are pushed into HashiCorp Vault and various chunks of our infrastructure use this service for items that are shared between Virtual Machines and our Kubernetes installations.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Being discussed](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25076).
|
||||
|
||||
### HAProxy
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
HAProxy is not used.
|
||||
Instead we rely on the ingresses that are deployed as part of the GitLab Helm Chart which leverages the cloud load balancer to direct traffic to the appropriate underlying resources.
|
||||
Each tenant has their own installation, thus a segregated endpoint for which customer traffic is routed too.
|
||||
|
||||
The deployments to handle frontend workloads are handled by a single service, known as `webservice` which is managed and deployed with our Helm Chart.
|
||||
|
||||
Further below, we mention the introduction of CloudFlare in the future, where this will eventually provide various WAF capabilities without the need for HAProxy.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
HAProxy sits behind CloudFlare and behind a set of Google Load Balancers.
|
||||
The primary purpose is to provide traffic routing to target clusters for frontend traffic, and provides a large swath of rules for traffic management.
|
||||
Some of this management are throttling or request blocking based on various criterion.
|
||||
We have a few sets of HAProxy fleets that handle dedicated endpoints, such as `registry.gitlab.com`, the Pages endpoint, and CI traffic.
|
||||
|
||||
We leverage an advanced feature of our Helm Chart to deploy a multitude of frontend `webservice`s, these are split into groups that serve target traffic.
|
||||
HAProxy is configured to divide these groupings of traffic with a myriad of rules.
|
||||
These groups are known today as `api`, `git`, `internal-api`, `web` and `websockets`.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
GitLab Cells introduces a new layer where requests need to be routed.
|
||||
It is slated that the [routing-service](../routing-service.md) will intercept all requests to direct clients to the appropriate cluster.
|
||||
This layer is above that of our current HAProxy setup.
|
||||
Behind the [routing-service](../routing-service.md) we plan to leverage existing Ingress methods deployed as part of the GitLab Helm Chart.
|
||||
Requests will then go directly to the Ingress configurations of our frontend.
|
||||
We'll need to evaluate the various traffic rules which are configured in HAProxy to determine if they can be set inside of CloudFlare as firewall rules where necessary and able.
|
||||
Ideally, HAProxy goes away in Cells Architecture.
|
||||
|
||||
The Helm Chart is used to deploy the frontend Pods, only a single one will be deployed, mimicking what Dedicated does today.
|
||||
|
||||
### Assets Routing
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Assets are served by the frontend service, known as the `webservice`.
|
||||
`webservice` Pods deployed by the GitLab Helm Chart.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
Assets are deployed into a Google Cloud Storage bucket as part of the deployment procedure owned by Team Delivery. Assets are then served by a specific routing configuration that is managed by CloudFlare.
|
||||
This removes our `webservice` deployment from needing to service static assets and allow those services to focus their load on processing requests.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
The deployment of assets shall not change. This process will remain the same with CloudFlare.
|
||||
|
||||
### Cloudflare
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
CloudFlare is not involved yet.
|
||||
Work is in progress to bring a WAF solution to Dedicated.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
CloudFlare is our first line of defense to provide us native and custom Firewall, DNS, and traffic routing management.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
Our use of CloudFlare will technically expand with the use of the [routing-service](../routing-service.md).
|
||||
The .com entrypoint does not change, there should be no change to this service outside of the addition of the [routing-service](../routing-service.md).
|
||||
|
||||
### Container Registry
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Dedicated leverages our Helm Chart to deploy and configure the GitLab Registry Service.
|
||||
The Registry Service is backed by a storage bucket managed by the GitLab Environment Toolkit.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
.com Leverages the same GitLab Helm chart to deploy and configure the Container Registry service.
|
||||
The backing storage is configured by our own terraform mechanism in the [`config-mgmt`](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt) repository.
|
||||
|
||||
Container Registry uses PostgesSQL Database for [online garbage collection](../../../../administration/packages/container_registry_metadata_database.md) where the database migrations are managed by a [Kubernetes Job](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/8a6a34b8db7a41eaff463d0353a2e876ebc41458/charts/registry/templates/migrations-job.yaml) with possibility to manually rollback.
|
||||
|
||||
The Container Registry also uses Redis as a caching layer.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Being Discussed](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/4130)
|
||||
|
||||
### Mail Delivery
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
_work in progress._ [See Issue 2481](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/2481)
|
||||
|
||||
- Outgoing: It is slated that we leverage the [AWS `SES` product](https://aws.amazon.com/ses/) and geared towards outgoing email.
|
||||
- Incoming: [Incoming email](../../../../administration/incoming_email.md) is unsupported.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
- Outgoing: Mail is handled by a third party, [Mailgun](https://www.mailgun.com/).
|
||||
- Incoming: Email is handled by the GitLab application with [webhook delivery method](../../email_ingestion/index.md#webhook-delivery-method-recommended) which watches for email sitting on a configured inbox and directing this appropriately to Sidekiq workers.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
Outgoing: Continue use Mailgun because we have a strong relationship with the provider, and no desire to change.
|
||||
The Dedicated Provisioner can support Mailgun/Third-party outgoing mail gateways with minimal configuration change.
|
||||
Incoming: [Being discussed](https://gitlab.com/gitlab-org/gitlab/-/issues/442161)
|
||||
|
||||
### PostgreSQL
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
A single RDS instance is deployed.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
To handle the scale of some functions of our GitLab Rails codebase, the database was split into three PostgreSQL Clusters.
|
||||
The `main` cluster which handles most of the data storage, the `ci` which handles all the CI related data, and finally, the `embedding` database.
|
||||
We are also evaluating to [further decompose](https://gitlab.com/gitlab-org/gitlab/-/issues/427973) to another PostgreSQL cluster.
|
||||
|
||||
In front of each database we have a set of PgBouncer as a connection pooler.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
What we'll do is being worked on in a separate [blueprint](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144238)
|
||||
|
||||
### Embedding Database
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
GitLab Dedicated is not using the embedding database, it's still in the experimental phase.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
A PostgreSQL cluster deployed running [pgvector](https://github.com/pgvector/pgvector).
|
||||
The embedding data is to vectorize GitLab content (issues, epics, merge requests) and store that data in a place where it can be used for search, recommendations, anomaly detection, classification, backlog cleanup, deduplication, and other AI adjacent things.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
Embedding Database is still considered experimental we will not support this in Cells to reduce scope for Cells 1.0.
|
||||
|
||||
### GitLab Pages
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Just recently released!
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
GitLab Pages is an active feature of .com.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
We will not enable GitLab Pages for [Cells 1.0](https://gitlab.com/gitlab-org/gitlab/-/blob/cfc0b476301097580d348e054b0ba4f721d4a9df/doc/architecture/blueprints/cells/iterations/cells-1.0.md#L476-479) so it's out of scope at the moment.
|
||||
|
||||
### VM Configuration Management
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Management of the VMs is all handled by GitLab Environment Toolkit.
|
||||
It uses Terraform for provisioning the machines and Ansible to configure the VM.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
.com leverages Chef for configuration management with integrations into Vault for secrets management and a complex role structure built into Chef for managing configurations.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
Reuse the GitLab Dedicated tooling, meaning that chef will be removed.
|
||||
|
||||
### Disaster Recovery
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Reference existing documentation:
|
||||
|
||||
- [RTO/RPO from backups](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/engineering/restore-from-backups-rto-rpo.html)
|
||||
- [Recovery Guides](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/regional-failure-recovery.html)
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
Reference existing documentation:
|
||||
|
||||
- [Runbooks](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/disaster-recovery)
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
A blueprint will be created at a [later point in time](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25118).
|
||||
|
||||
### Feature Flags
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Feature Flags are not heavily leveraged and actively discouraged.
|
||||
An override mechanism exists for special use-cases.
|
||||
Note that this is a business decision and not a technical limitation.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
We have a fairly complex [process](https://gitlab.com/gitlab-org/gitlab/-/blob/b6336d771249dbee6da5cf65fa49b85834d493e3/doc/development/feature_flags/index.md) to allow engineers to rollout out changes safely.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
ChatOps will eventually be expanded upon to support Cells.
|
||||
[Epic 12797](https://gitlab.com/groups/gitlab-org/-/epics/12797) has been created to provide any added functionality.
|
||||
No work will occur for Iteration Cells 1.0.
|
||||
|
||||
### Deployment
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
All components which feed into a tenant install are versioned.
|
||||
Per contract, a maintenance window is defined and agreed upon with a customer that provides an opportunity for any maintenance, whether it be a version upgrade, change to infrastructure, or configuration change to the application is performed.
|
||||
The tooling leveraged by this runs through extensive testing beforehand on non-production tenants.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
A dedicated team, [Delivery](https://handbook.gitlab.com/handbook/engineering/infrastructure/team/delivery/) is responsible for a set of tooling which manages and deploys new versions of GitLab a multiple times per day.
|
||||
Multiple stages, Canary and Main, are leveraged to help with risk management of deployments.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Delivery](https://handbook.gitlab.com/handbook/engineering/infrastructure/team/delivery/) remains responsible for initial development of this.
|
||||
[The current blueprint](../application-deployment.md) that surrounds this work introduces a concept of Ring deployments to manage risk.
|
||||
|
||||
### Subnets
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Dedicated uses a static list of IP CIDRs that intentionally overlap for all tenants.
|
||||
Subnets are configurable in the case of a need from a customer.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
A very tightly and carefully managed dance is performed to ensure documentation, terraform code, and VPC peering all work in a cohesive manner across various GCP projects, and environments.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Being discussed](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25069)
|
||||
|
||||
### Kubernetes
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Managed by the GitLab Environment Toolkit, a single Kubernetes Cluster is spun up.
|
||||
Managed by the GitLab Helm Chart, an entire GitLab installation is deployed.
|
||||
Instrumentor contains the tooling for the observability stack that is installed into the same cluster.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
Clusters are manually configured with Terraform through the `config-mgmt` repository.
|
||||
Deployments of anything to these clusters are managed through at least three repositories that deploy various tools required to manage, maintain, and observe the GitLab application workloads that are deployed.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Being discussed](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25068)
|
||||
|
||||
### SRE root access to machines
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
VMs:
|
||||
|
||||
Managed by Ansible: A mixture of [SSH](<https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/tenant-ssh.html>] (internal link) with the use of [Identify-Aware Proxy](https://cloud.google.com/compute/docs/connect/ssh-using-iap).
|
||||
This must be used with the [Break glass procedure](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/engineering/breaking_glass.html) (internal link).
|
||||
|
||||
Kubernetes:
|
||||
|
||||
`kubectl`: [Break glass procedure](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/engineering/breaking_glass.html) (internal link).
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
VMs:
|
||||
|
||||
- VMs manged by Chef: Users and SSH keys are managed by Chef and require a bastion to be able to SSH inside of machines with root access.
|
||||
- Rails Console: We use [Teleport](https://gitlab.com/gitlab-com/runbooks/-/blob/8197f6cdb6aa8e7230600a9e59ee4f447a8543f5/docs/teleport/Connect_to_Rails_Console_via_Teleport.md) to spin up a rails console for read-only access.
|
||||
- `psql`: We use [Teleport](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/teleport/Connect_to_Database_Console_via_Teleport.md?ref_type=heads)
|
||||
|
||||
Kubernetes:
|
||||
|
||||
- `kubectl`: A bastion server where the keys are managed by Chef and then setting up [`gcloud`](https://gitlab.com/gitlab-com/runbooks/-/blob/8197f6cdb6aa8e7230600a9e59ee4f447a8543f5/docs/kube/k8s-oncall-setup.md#kubernetes-api-access)
|
||||
- GKE VMs: We use [Google's OS Login](https://cloud.google.com/compute/docs/oslogin) to access the nodes.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
VMs:
|
||||
|
||||
- Managed by Ansible: Same as GitLab Dedicated
|
||||
- Rails Console: [Being discussed](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25124)
|
||||
- `psql`: [Being discussed](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25124)
|
||||
|
||||
Kubernetes:
|
||||
|
||||
- `kubectl`: Same as GitLab Dedicated
|
||||
- GKE VMs: Same as GitLab Dedicated
|
||||
|
||||
### Observability
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
An observability stack which consumes the same set of metrics we leverage for .com are bundled into Instrumentor and deployed to the observability stack installed into a tenant's Kubernetes Cluster.
|
||||
This includes all the appropriate rules for alerting, paging, provides dashboards, and forecasting.
|
||||
Some metrics are lacking, but are being worked on to bring full coverage where lacking.
|
||||
|
||||
There does not exist a global view of metrics for all tenants.
|
||||
|
||||
Logging is managed by way of using AWS OpenSearch for AWS tenants, and Google Cloud Logging for GCP tenants.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
A large installation of the Prometheus and Thanos across a multitude of GCP projects are managed through various means.
|
||||
We leverage the Runbooks repository to configure all of our Dashboards, Alerts, and Pages.
|
||||
|
||||
We inherently are provided a global view as our Grafana installation talks to a large Thanos configuration which is able to distribute queries across all necessary environments.
|
||||
|
||||
Logs are managed by way of `fluentd` on both our Virtual Machines and Kubernetes clusters sending data to PubSub which are then brought into Elasticsearch where Kibana is used for viewing.
|
||||
Some services dump too much data, such as CloudFlare, GKE, and HAProxy, where we rely on Google's Logging solution, either Stackdriver, or BigQuery.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Being discussed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143672)
|
||||
|
||||
### Camoproxy
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Unused.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
[go-camo](https://github.com/cactus/go-camo?tab=readme-ov-file#how-it-works) is deployed by a custom [Helm chart](https://gitlab.com/gitlab-com/gl-infra/charts/-/tree/main/gitlab/camoproxy?ref_type=heads). `go-camo` used to serve images from HTTP based resources to HTTPS.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
[Being discussed](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25125)
|
||||
|
||||
### Certificates
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
GitLab Dedicated uses [`cert-manager`](https://cert-manager.io/), Let's Encrypt and NGINX to issue and [manage certificates](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/certmanager.html).
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
GitLab.com uses Cloudflare for [certificates](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/certificates/cloudflare.md) and mixture of `cert-manager` and GCP certificates for auxiliary services such as Grafana.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
For the GitLab.com we will still use Cloudflare so we can continue using the certificates from Cloudflare.
|
||||
|
||||
### osquery
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
It doesn't install osquery.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
We have a [chef cookbook](https://gitlab.com/gitlab-cookbooks/gitlab-osquery) to manage our osquery installation.
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
Tooling will need to be developed that is compatible with deployment methods being leveraged to deploy to the Cell architecture.
|
||||
|
||||
**What will be covered by osquery:**
|
||||
|
||||
osquery would cover all the Virtual Machines; some of the examples today covered are bastion nodes, HA Proxy nodes, etc.
|
||||
|
||||
**Why we require osquery:**
|
||||
|
||||
1. **Visibility:** Notably, we still have very little visibility over what is happening inside our VMs and Kubernetes Clusters.
|
||||
1. **Compliance Requirements:** Compliance requires us to have clear insights into actions in environments like Kubernetes or the Legacy VMs.
|
||||
1. **Incidents Investigation:** Incidents reported in the past are left with few missing investigations due to a lack of detection and investigation of the commands executed before and after the malicious commands.
|
||||
|
||||
### Wiz Runtime Sensor
|
||||
|
||||
**What is GitLab Dedicated Doing:**
|
||||
|
||||
Wiz is not used.
|
||||
|
||||
**What is GitLab.com doing right now:**
|
||||
|
||||
Wiz Runtime Sensor is a new tool being introduced into .com. Wiz Runtime Sensor is a lightweight eBPF-based agent which is listens to syscalls and generates the findings on the suspicious actions executed by the applications/workloads. Follow Wiz Runtime [Internal Handbook Page](https://internal.gitlab.com/handbook/security/infrastructure_security/tooling/wiz-sensor/) for more details.
|
||||
|
||||
As of this writing, it has not been deployed into the production environment and is still being tested in our staging environment. Currently, it is deployed using the [Helm chart](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-helmfiles/-/tree/master/releases/wiz-sensor?ref_type=heads)
|
||||
|
||||
**What will GitLab.com Cells do:**
|
||||
|
||||
If this tool is to be leveraged, we will need to recreate a method of deployment suitable for Cells.
|
||||
The current deployment method being leveraged will not suffice for Cellular architecture.
|
||||
|
||||
**What will be covered by Wiz Runtime Sensor:**
|
||||
|
||||
Wiz Runtime Sensor would be deployed in the Kubernetes clusters as a `DaemonSet`. `DaemonSet` would add the sensor to all the nodes; Wiz Runtime Sensor would observe the syscalls for any malicious actions like malicious script executed, sensitive files accessed/modified, and container escape attempts.
|
||||
|
||||
**Why we require Wiz Runtime Sensor:**
|
||||
|
||||
1. **Visibility:** Notably, we still have very little visibility over what is happening inside our VMs and Kubernetes Clusters.
|
||||
1. **Compliance Requirements:** Compliance requires us to have clear insights into actions in environments like Kubernetes or the Legacy VMs.
|
||||
1. **Incidents Investigation:** Incidents reported in the past are left with few missing investigations due to a lack of detection and investigation of the commands executed before and after the malicious commands.
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
owning-stage: "~devops::secure"
|
||||
description: "GitLab Secret Detection ADR 002: Store the Secret Detection Gem in the same repository"
|
||||
---
|
||||
|
||||
# GitLab Secret Detection ADR 002: Store the Secret Detection Gem in the same repository
|
||||
|
||||
## Context
|
||||
|
||||
During [Phase 1](../index.md#phase-1---ruby-pushcheck-pre-receive-integration), we opted for using the [Ruby-based push check approach](../decisions/001_use_ruby_push_check_approach_within_monolith.md) to block secrets from being committed to a repository, and as such the scanning of secrets was performed by a library (or a Ruby gem) developed internally within GitLab for this specific purpose.
|
||||
|
||||
Part of the process to create this library and make it available for use within the Rails monolith, we had to make a decision on the best way to distribute the library.
|
||||
|
||||
## Approach
|
||||
|
||||
We evaluated two possible approaches:
|
||||
|
||||
1. Store the library [in the same repository](../../../../development/gems.md#in-the-same-repo) as the monolith.
|
||||
1. Store the library [in an external repository](../../../../development/gems.md#in-the-external-repo).
|
||||
|
||||
Each approach came with some advantages and disadvantages, mostly around distribution, consistency, maintainability, and the overhead of having to setup review and release workflows and similar processes. See below for more information.
|
||||
|
||||
### Within the same repository as the monolith
|
||||
|
||||
Having the gem developed and stored in the same repository meant having it packaged within GitLab monolith itself, and with that ensuring it does not have to be installed as a dependency. This would also reduce maintainability overhead in terms of defining workflows and processes from scratch. On the other hand, the library would have less visibility as it is not exposed or published to the wider community.
|
||||
|
||||
### In an external repository
|
||||
|
||||
Storing the library in an external repository meant having more visibility especially as the gem would be published on RubyGems.org, which would have garnered more interest and possibly contributions from the community into the feature. Additionally, the gem would be available to be used in other projects and applications. However, in doing so, the maintainability overhead would have increased signficantly for various reasons such as:
|
||||
|
||||
- Changes would need to be coordinated between multiple repositories when a new version is released.
|
||||
- Review and release workflows, and similar processes would need to be defined separately.
|
||||
|
||||
## Decision
|
||||
|
||||
The decision was made to store the library in the same repository during the first phase to ensure easier distribution since it's packaged within GitLab and will be available immediately without having to install external dependencies.
|
||||
|
||||
With that said, we still followed [the process](../../../../development/gems.md#reserve-a-gem-name) to reserve the gem on [RubyGems.org](https://rubygems.org/gems/gitlab-secret_detection) to avoid name-squatters from taking over the name and providing malicious code to 3rd-parties.
|
||||
|
||||
We have no plans to publish the gem externally at least until [Phase 2](../index.md#phase-2---standalone-pre-receive-service) as we begin to consider building a standalone service to perform secret detection.
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
owning-stage: "~devops::secure"
|
||||
description: "GitLab Secret Detection ADR 002: Run scan within subprocess"
|
||||
description: "GitLab Secret Detection ADR 003: Run scan within subprocess"
|
||||
---
|
||||
|
||||
# GitLab Secret Detection ADR 002: Run scan within subprocesses
|
||||
# GitLab Secret Detection ADR 003: Run scan within subprocesses
|
||||
|
||||
## Context
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ It is crucial to determine which operation runs within the subprocess because sp
|
|||
|
||||
*Bucket Approach*: A compromise between the two extremes would be when we group all the blobs whose cumulative size is at least a fixed chunk size ([`2MiB` in our case](https://gitlab.com/gitlab-org/gitlab/-/blob/5dfcf7431bfff25519c05a7e66c0cbb8d7b362be/gems/gitlab-secret_detection/lib/gitlab/secret_detection/scan.rb#L32)) and then run each group within a separate sub-process as illustrated below.
|
||||
|
||||
|
||||
|
||||
|
||||
### Addendum
|
||||
|
||||
|
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 61 KiB |
|
|
@ -151,7 +151,8 @@ as self-managed instances.
|
|||
### Decisions
|
||||
|
||||
- [001: Use Ruby Push Check approach within monolith](decisions/001_use_ruby_push_check_approach_within_monolith.md)
|
||||
- [002: Run scan within subprocess](decisions/002_run_scan_within_subprocess.md)
|
||||
- [002: Store the Secret Detection Gem in the same repository](decisions/002_store_the_secret_detection_gem_in_the_same_repository.md)
|
||||
- [003: Run scan within subprocess](decisions/003_run_scan_within_subprocess.md)
|
||||
|
||||
## Challenges
|
||||
|
||||
|
|
@ -303,7 +304,7 @@ The private SD gem offers the following support in addition to running scan on m
|
|||
The Ruleset file referred during the Pre-receive Secret Detection scan is
|
||||
located [here](https://gitlab.com/gitlab-org/gitlab/-/blob/2da1c72dbc9df4d9130262c6b79ea785b6bb14ac/gems/gitlab-secret_detection/lib/gitleaks.toml).
|
||||
|
||||
More details about the Gem can be found in the [README](https://gitlab.com/gitlab-org/gitlab/-/blob/master/gems/gitlab-secret_detection/README.md) file.
|
||||
More details about the Gem can be found in the [README](https://gitlab.com/gitlab-org/gitlab/-/blob/master/gems/gitlab-secret_detection/README.md) file. Also see [ADR 002](decisions/002_store_the_secret_detection_gem_in_the_same_repository.md) for more on how the Gem code is stored and distributed.
|
||||
|
||||
### Phase 2 - Standalone pre-receive service
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ info: >-
|
|||
this page, see
|
||||
https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# CI/CD YAML syntax reference
|
||||
|
||||
DETAILS:
|
||||
|
|
@ -2496,19 +2495,25 @@ job1:
|
|||
### `identity`
|
||||
|
||||
DETAILS:
|
||||
**Status:** Experiment
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab.com
|
||||
**Status:** Beta
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142054) in GitLab 16.9. This feature is an [Experiment](../../policy/experiment-beta-support.md).
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142054) in GitLab 16.9 [with a flag](../../administration/feature_flags.md) named `google_cloud_support_feature_flag`. This feature is in [Beta](../../policy/experiment-beta-support.md).
|
||||
|
||||
FLAG:
|
||||
On GitLab.com and GitLab Dedicated, this feature is not available.
|
||||
The feature is not ready for production use.
|
||||
On GitLab.com, this feature is available for a subset of users. On GitLab Dedicated, this feature is not available.
|
||||
|
||||
This feature is in [Beta](../../policy/experiment-beta-support.md).
|
||||
To join the list of users testing this feature, join the [waitlist](https://forms.gle/XdxdTxC7DXj4NSaz9).
|
||||
|
||||
Use `identity` to authenticate with third party services using identity federation.
|
||||
|
||||
**Keyword type**: Job keyword. You can use it only as part of a job or in the [`default:` section](#default).
|
||||
|
||||
**Possible inputs**: An identifier. Supported providers: `google_cloud` (Google Cloud).
|
||||
**Possible inputs**: An identifier. Supported providers:
|
||||
|
||||
- `google_cloud`: Google Cloud. Must be configured with the [Google Cloud IAM integration](../../integration/google_cloud_iam.md).
|
||||
|
||||
**Example of `identity`**:
|
||||
|
||||
|
|
@ -2522,6 +2527,7 @@ job_with_workload_identity:
|
|||
**Related topics**:
|
||||
|
||||
- [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation).
|
||||
- [Google Cloud IAM integration](../../integration/google_cloud_iam.md).
|
||||
|
||||
### `id_tokens`
|
||||
|
||||
|
|
|
|||
|
|
@ -35,6 +35,8 @@ To connect a feature in an existing backend service to Cloud Connector:
|
|||
|
||||
1. Call `CloudConnector::AccessService.new.access_token(scopes: [...])` with the list of scopes your feature requires and include
|
||||
this token in the `Authorization` HTTP header field.
|
||||
Note that this can return `nil` if there is no valid token available. If there is no token, the call to Cloud Connector will
|
||||
not pass authorization, so it is recommended to return early.
|
||||
The backend service must validate this token and any scopes it carries when receiving the request.
|
||||
If you need to embed additional claims in the token specific to your use case, you can pass these
|
||||
in the `extra_claims` argument. **Scopes and other claims passed here will only be included in self-issued tokens on GitLab.com.**
|
||||
|
|
@ -60,6 +62,7 @@ This allows clients to access the feature at `https://cloud.gitlab.com/foo/new_f
|
|||
include API::Helpers::CloudConnector
|
||||
|
||||
token = ::CloudConnector::AccessService.new.access_token(scopes: [:new_feature_scope])
|
||||
return unauthorized! if token.nil?
|
||||
|
||||
Gitlab::HTTP.post(
|
||||
"https://cloud.gitlab.com/foo/new_feature_endpoint",
|
||||
|
|
|
|||
|
|
@ -0,0 +1,181 @@
|
|||
---
|
||||
stage: Govern
|
||||
group: Authentication
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Google Cloud workload identity federation and IAM policies
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab.com
|
||||
**Status:** Beta
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141127) in GitLab 16.10 [with a flag](../administration/feature_flags.md) named `google_cloud_support_feature_flag`. This feature is in [Beta](../policy/experiment-beta-support.md).
|
||||
|
||||
FLAG:
|
||||
On GitLab.com, this feature is available for a subset of users. On GitLab Dedicated, this feature is not available.
|
||||
|
||||
This feature is in [Beta](../policy/experiment-beta-support.md). To join the
|
||||
list of users testing this feature, join the
|
||||
[waitlist](https://forms.gle/XdxdTxC7DXj4NSaz9).
|
||||
|
||||
To use Google Cloud integrations like the
|
||||
[Google Artifact Registry](../user/project/integrations/google_artifact_registry.md),
|
||||
you must create and configure a
|
||||
[workload identity pool and provider](https://cloud.google.com/iam/docs/workload-identity-federation).
|
||||
The Google Cloud integration uses the workload identity federation to
|
||||
grant GitLab workloads access to Google Cloud resources through OpenID Connect
|
||||
(OIDC) by using JSON Web Token (JWT) tokens.
|
||||
|
||||
## Create and configure a workload identity federation
|
||||
|
||||
To setup the workload identity federation you can either:
|
||||
|
||||
- Use the GitLab UI for a guided setup.
|
||||
- Use the Google Cloud CLI to setup the workload identity federation manually.
|
||||
|
||||
### With the GitLab UI
|
||||
|
||||
To use the GitLab UI to set up the workload identity federation:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > Integrations**.
|
||||
1. Locate the Google Cloud IAM integration and select **Configure**.
|
||||
1. Select **Guided setup** and follow the instructions.
|
||||
|
||||
### With the Google Cloud CLI
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Google Cloud CLI must be [installed and authenticated](https://cloud.google.com/sdk/docs/install)
|
||||
with Google Cloud.
|
||||
- You must have the [permissions](https://cloud.google.com/iam/docs/manage-workload-identity-pools-providers#required-roles)
|
||||
to manage workload identity federation in Google Cloud.
|
||||
|
||||
1. Create a workload identity pool with the following command. Replace these
|
||||
values:
|
||||
|
||||
- `<your_google_cloud_project_id>` with your
|
||||
[Google Cloud project ID](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects).
|
||||
To improve security, use a dedicated project for identity management,
|
||||
separate from resources and CI/CD projects.
|
||||
- `<your_identity_pool_id>` with the ID to use for the pool, which must
|
||||
be 4 to 32 lowercase letters, digits, or hyphens. To avoid collisions, use a
|
||||
unique ID. It is recommended to include the GitLab project ID or project path
|
||||
as it facilitates IAM policy management. For example,
|
||||
`gitlab-my-project-name`.
|
||||
|
||||
```shell
|
||||
gcloud iam workload-identity-pools create <your_identity_pool_id> \
|
||||
--project="<your_google_cloud_project_id>" \
|
||||
--location="global" \
|
||||
--display-name="Workload identity pool for GitLab project ID"
|
||||
```
|
||||
|
||||
1. Add an OIDC provider to the workload identity pool with the following
|
||||
command. Replace these values:
|
||||
|
||||
- `<your_identity_provider_id>` with the ID to use for the provider, which
|
||||
must be 4 to 32 lowercase letters, digits, or hyphens. To avoid
|
||||
collisions, use a unique ID within the identity pool. For example,
|
||||
`gitlab`.
|
||||
- `<your_google_cloud_project_id>` with your
|
||||
[Google Cloud project ID](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects).
|
||||
- `<your_identity_pool_id>` with the ID of the workload identity pool you
|
||||
created in the previous step.
|
||||
- `<your_issuer_uri>` with your identity provider issuer URI, which can be
|
||||
can be copied from the IAM integration page when choosing
|
||||
manual setup and must exactly match the value. The parameter must include
|
||||
the path of the root group. For example, if the project is under
|
||||
`my-root-group/my-sub-group/project-a`, the `issuer-uri` must be set to
|
||||
`https://auth.gcp.gitlab.com/oidc/my-root-group`.
|
||||
|
||||
```shell
|
||||
gcloud iam workload-identity-pools providers create-oidc "<your_identity_provider_id>" \
|
||||
--location="global" \
|
||||
--project="<your_google_cloud_project_id>" \
|
||||
--workload-identity-pool="<your_identity_pool_id>" \
|
||||
--issuer-uri="<your_issuer_uri>" \
|
||||
--display-name="GitLab OIDC provider" \
|
||||
--attribute-mapping="attribute.guest_access=assertion.guest_access,\
|
||||
attribute.reporter_access=assertion.reporter_access,\
|
||||
attribute.developer_access=assertion.developer_access,\
|
||||
attribute.maintainer_access=assertion.maintainer_access,\
|
||||
attribute.owner_access=assertion.owner_access,\
|
||||
attribute.namespace_id=assertion.namespace_id,\
|
||||
attribute.namespace_path=assertion.namespace_path,\
|
||||
attribute.project_id=assertion.project_id,\
|
||||
attribute.project_path=assertion.project_path,\
|
||||
attribute.user_id=assertion.user_id,\
|
||||
attribute.user_login=assertion.user_login,\
|
||||
attribute.user_email=assertion.user_email,\
|
||||
attribute.user_access_level=assertion.user_access_level,\
|
||||
google.subject=assertion.sub"
|
||||
```
|
||||
|
||||
- The `attribute-mapping` parameter must include the mapping between OIDC custom
|
||||
claims included in the JWT ID token to the corresponding identity attributes
|
||||
that are used in Identity and Access Management (IAM) policies to grant access.
|
||||
Refer to the list of [supported OIDC custom claims](google_cloud_iam.md#oidc-custom-claims)
|
||||
for configuring the attribute mapping. For more information on mapping claims
|
||||
to IAM policies, see [Control access to Google Cloud](https://cloud.google.com/developer-ecosystem/docs/gitlab/access-control#control-access-google).
|
||||
|
||||
After you create the workload identity pool and provider, to complete the setup in GitLab:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > Integrations**.
|
||||
1. Locate the Google Cloud IAM integration and select **Configure**.
|
||||
1. Select **Manual setup**
|
||||
1. Complete the fields.
|
||||
- **[Project ID](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects)**
|
||||
for the Google Cloud project in which you created the workload identity.
|
||||
pool and provider. Example: `my-sample-project-191923`.
|
||||
- **[Project number](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects)**
|
||||
for the same Google Cloud project. Example: `314053285323`.
|
||||
- **Pool ID** of the workload identity pool you created for this integration.
|
||||
- **Provider ID** of the workload identity provider you created for this integration.
|
||||
|
||||
### OIDC custom claims
|
||||
|
||||
The ID token includes the following custom claims:
|
||||
|
||||
| Claim name | When | Description |
|
||||
| ----------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| `namespace_id` | On project events | ID of the group or user level namespace. |
|
||||
| `namespace_path` | On project events | Path of the group or user level namespace. |
|
||||
| `project_id` | On project events | ID of the project. |
|
||||
| `project_path` | On project events | Path of the project. |
|
||||
| `root_namespace_id` | On group events | ID of the root group or user level namespace. |
|
||||
| `root_namespace_path` | On group events | Path of the root group or user level namespace. |
|
||||
| `user_id` | On user-trigged events | ID of the user. |
|
||||
| `user_login` | On user-trigged events | Username of the user. |
|
||||
| `user_email` | On user-trigged events | Email of the user. |
|
||||
| `ci_config_ref_uri` | During CI/CD pipeline run | The ref path to the top-level CI pipeline definition. |
|
||||
| `ci_config_sha` | During CI/CD pipeline run | Git commit SHA for the `ci_config_ref_uri`. |
|
||||
| `job_id` | During CI/CD pipeline run | ID of the CI job. |
|
||||
| `pipeline_id` | During CI/CD pipeline run | ID of the CI pipeline. |
|
||||
| `pipeline_source` | During CI/CD pipeline run | CI pipeline source. |
|
||||
| `project_visibility` | During CI/CD pipeline run | The visibility of the project where the pipeline is running. |
|
||||
| `ref` | During CI/CD pipeline run | Git ref for the CI job. |
|
||||
| `ref_path` | During CI/CD pipeline run | Fully qualified ref for the CI job. |
|
||||
| `ref_protected` | During CI/CD pipeline run | If the Git ref is protected. |
|
||||
| `ref_type` | During CI/CD pipeline run | Git ref type. |
|
||||
| `runner_environment` | During CI/CD pipeline run | The type of runner used by the CI job. |
|
||||
| `runner_id` | During CI/CD pipeline run | ID of the runner executing the CI job. |
|
||||
| `sha` | During CI/CD pipeline run | The commit SHA for the CI job. |
|
||||
| `environment` | During CI/CD pipeline run | Environment the CI job deploys to. |
|
||||
| `environment_protected` | During CI/CD pipeline run | If deployed environment is protected. |
|
||||
| `environment_action` | During CI/CD pipeline run | Environment action specified in the CI job. |
|
||||
| `deployment_tier` | During CI/CD pipeline run | Deployment tier of the environment the CI job specifies. |
|
||||
| `user_access_level` | On user-trigged events | Role of the user with values of `guest`, `reporter`, `developer`, `maintainer`, `owner`. |
|
||||
| `guest_access` | On user-trigged events | Indicates whether the user has at least `guest` role, with values of "true" or "false" as a string. |
|
||||
| `reporter_access` | On user-trigged events | Indicates whether the user has at least `reporter` role, with values of "true" or "false" as a string. |
|
||||
| `developer_access` | On user-trigged events | Indicates whether the user has at least `developer` role, with values of "true" or "false" as a string. |
|
||||
| `maintainer_access` | On user-trigged events | Indicates whether the user has at least `maintainer` role, with values of "true" or "false" as a string. |
|
||||
| `owner_access` | On user-trigged events | Indicates whether the user has at least `owner` role, with values of "true" or "false" as a string. |
|
||||
|
||||
These claims are a superset of the
|
||||
[ID token claims](../ci/secrets/id_token_authentication.md#token-payload).
|
||||
All values are of type string. See the ID token claims documentation for more
|
||||
details and example values.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
|
|
@ -511,10 +511,14 @@ If an OKR is closed with a locked discussion, then you cannot reopen it until th
|
|||
|
||||
## Two-column layout
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/415077) in GitLab 16.2 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default.
|
||||
DETAILS:
|
||||
**Status:** Beta
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/415077) in GitLab 16.2 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default. This feature is in [Beta](../policy/experiment-beta-support.md).
|
||||
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/446064) to feature flag named `work_items_beta` in GitLab 16.10. Disabled by default.
|
||||
|
||||
FLAG:
|
||||
On self-managed GitLab, by default this feature is not available. To make it available, an administrator can [enable the feature flag](../administration/feature_flags.md) named `work_items_mvc_2`.
|
||||
On self-managed GitLab, by default this feature is not available. To make it available per group, an administrator can [enable the feature flag](../administration/feature_flags.md) named `work_items_beta`.
|
||||
On GitLab.com and GitLab Dedicated, this feature is not available.
|
||||
This feature is not ready for production use.
|
||||
|
||||
|
|
@ -522,7 +526,10 @@ When enabled, OKRs use a two-column layout, similar to issues.
|
|||
The description and threads are on the left, and attributes, such as labels
|
||||
or assignees, on the right.
|
||||
|
||||
|
||||
This feature is in [Beta](../policy/experiment-beta-support.md).
|
||||
If you find a bug, [comment on the feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/442090).
|
||||
|
||||
|
||||
|
||||
## Linked items in OKRs
|
||||
|
||||
|
|
|
|||
|
|
@ -23,42 +23,52 @@ Using the GitLab UI, the GitHub importer always imports from the
|
|||
`github.com` domain. If you are importing from a self-hosted GitHub Enterprise Server domain, use the
|
||||
[GitLab Import API](#use-the-api) GitHub endpoint.
|
||||
|
||||
When importing projects:
|
||||
|
||||
- If a user referenced in the project is not found in the GitLab database, the project creator is set as the author and
|
||||
assignee. The project creator is usually the user that initiated the import process. A note on the issue mentioning the
|
||||
original GitHub author is added.
|
||||
- Reviewers assigned to GitHub pull requests that do not exist in GitLab are not imported. In this case, the import
|
||||
creates comments describing that non-existent users were added as reviewers and approvers. However, the actual
|
||||
reviewer status and approval are not applied to the merge request in GitLab.
|
||||
- You can change the target namespace and target repository name before you import.
|
||||
- The organization the repository belongs to must not impose restrictions of a [third-party application access policy](https://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions) on the GitLab instance you import to.
|
||||
You can change the target namespace and target repository name before you import.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview of the import process, see [How to migrate from GitHub to GitLab including Actions](https://www.youtube.com/watch?v=0Id5oMl1Kqs).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To import projects from GitHub, you must enable the
|
||||
[GitHub import source](../../../administration/settings/import_and_export_settings.md#configure-allowed-import-sources).
|
||||
If that import source is not enabled, ask your GitLab administrator to enable it. The GitHub import source is enabled
|
||||
by default on GitLab.com.
|
||||
|
||||
### Permissions and roles
|
||||
|
||||
> - Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5.
|
||||
|
||||
To import projects from GitHub:
|
||||
To use the GitHub importer, you must have:
|
||||
|
||||
- Access to the GitHub project to import.
|
||||
- At least the Maintainer role on the destination GitLab group to import to.
|
||||
|
||||
Also, the organization the GitHub repository belongs to must not impose restrictions of a
|
||||
[third-party application access policy](https://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions)
|
||||
on the GitLab instance you import to.
|
||||
|
||||
### Accounts for user contribution mapping
|
||||
|
||||
For user contribution mapping between GitHub and GitLab to work:
|
||||
|
||||
- [GitHub import source](../../../administration/settings/import_and_export_settings.md#configure-allowed-import-sources)
|
||||
must be enabled. If not enabled, ask your GitLab administrator to enable it. The GitHub import source is enabled
|
||||
by default on GitLab.com.
|
||||
- You must have at least the Maintainer role on the destination group to import to.
|
||||
- Each GitHub author and assignee in the repository must have a
|
||||
[public-facing email address](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address)
|
||||
on GitHub that matches their GitLab email address (regardless of how the account was created). If their email address
|
||||
from GitHub is set as their secondary email address in GitLab, they must confirm it.
|
||||
[public-facing email address](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address).
|
||||
- The GitHub user's email address must match their GitLab email address.
|
||||
- If a user's email address in GitHub is set as their secondary email address in GitLab, they must confirm it.
|
||||
|
||||
When issues and pull requests are being imported, the importer attempts to find their GitHub authors and assignees in
|
||||
the database of the GitLab instance. Pull requests are called _merge requests_ in GitLab. For the importer to succeed,
|
||||
matching email addresses are required.
|
||||
- GitHub accounts must have a GitHub public-facing email address so that all comments and contributions can be properly mapped to
|
||||
the same user in GitLab. GitHub Enterprise does not require this field to be populated so you might have to add it on existing accounts.
|
||||
GitHub Enterprise does not require a public email address, so you might have to add it to existing accounts.
|
||||
|
||||
### Known issues
|
||||
If the above requirements are not met, the importer can't map the particular user's contributions. In that case:
|
||||
|
||||
- The project creator is set as the author and assignee of issues and merge requests. The project creator is usually the
|
||||
user that initiated the import process. For some contributions that have a description or note such as pull requests,
|
||||
issue, notes, the importer amends the text with details of who originally created the contribution.
|
||||
- Reviewers and approvals added on pull requests in GitHub cannot be imported. In this case, the importer creates comments
|
||||
describing that non-existent users were added as reviewers and approvers. However, the actual reviewer status and
|
||||
approval are not applied to the merge request in GitLab.
|
||||
|
||||
## Known issues
|
||||
|
||||
- GitHub pull request comments (known as diff notes in GitLab) created before 2017 are imported in separate threads.
|
||||
This occurs because of a limitation of the GitHub API that doesn't include `in_reply_to_id` for comments before 2017.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ DETAILS:
|
|||
**Offering:** GitLab.com
|
||||
**Status:** Beta
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141127) in GitLab 16.10 [with a flag](../../feature_flags.md) named
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141127) in GitLab 16.10 [with a flag](../../../administration/feature_flags.md) named
|
||||
`google_cloud_support_feature_flag`. This feature is in [Beta](../../../policy/experiment-beta-support.md).
|
||||
|
||||
FLAG:
|
||||
|
|
@ -31,7 +31,7 @@ Prerequisites:
|
|||
|
||||
- You must have at least the Maintainer role for the GitLab project.
|
||||
- You must have the [permissions needed](https://cloud.google.com/iam/docs/granting-changing-revoking-access#required-permissions) to manage access to the Google Cloud project with the Artifact Registry repository.
|
||||
- A workload identity federation (WLIF) pool and provider must be configured to authenticate to Google Cloud.
|
||||
- A [workload identity federation](../../../integration/google_cloud_iam.md) (WLIF) pool and provider must be configured to authenticate to Google Cloud.
|
||||
- A [Google Artifact Registry repository](https://cloud.google.com/artifact-registry/docs/repositories) with the following configuration:
|
||||
- [Docker](https://cloud.google.com/artifact-registry/docs/supported-formats) format.
|
||||
- [Standard](https://cloud.google.com/artifact-registry/docs/repositories/create-repos) mode. Other repository formats and modes are not supported.
|
||||
|
|
@ -79,7 +79,7 @@ You can use these environment variables to interact with the Artifact Registry,
|
|||
### Authenticate with the Google Artifact Registry
|
||||
|
||||
You can configure a pipeline to authenticate with the Google Artifact Registry during pipeline
|
||||
execution. GitLab uses the configured workload identity pool IAM policies
|
||||
execution. GitLab uses the configured [workload identity pool](../../../integration/google_cloud_iam.md) IAM policies
|
||||
and populates the `GOOGLE_APPLICATION_CREDENTIALS` and `CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE`
|
||||
environment credentials. These environment credentials are automatically detected by client tools,
|
||||
like [gcloud CLI](https://cloud.google.com/sdk/gcloud) and [crane](https://github.com/google/go-containerregistry/blob/main/cmd/crane/README.md).
|
||||
|
|
@ -98,8 +98,8 @@ provide the steps to create the following IAM policies in your Google Cloud proj
|
|||
To create these IAM policies manually, use the following `gcloud` commands. Replace these values:
|
||||
|
||||
- `<your_google_cloud_project_id>` with the [ID](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects) of the Google Cloud project where the Artifact Registry repository is located.
|
||||
- `<your_workload_identity_pool_id>` with the ID of the workload identity pool. This is the same value used for the Google Cloud IAM integration.
|
||||
- `<your_google_cloud_project_number>` with the [number](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects) of the Google Cloud project where the workload identity pool is located. This is the same value used for the Google Cloud IAM integration.
|
||||
- `<your_workload_identity_pool_id>` with the ID of the workload identity pool. This is the same value used for the [Google Cloud IAM integration](../../../integration/google_cloud_iam.md).
|
||||
- `<your_google_cloud_project_number>` with the [number](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects) of the Google Cloud project where the workload identity pool is located. This is the same value used for the [Google Cloud IAM integration](../../../integration/google_cloud_iam.md).
|
||||
|
||||
```shell
|
||||
gcloud projects add-iam-policy-binding '<your_google_cloud_project_id>' \
|
||||
|
|
@ -111,7 +111,7 @@ gcloud projects add-iam-policy-binding '<your_google_cloud_project_id>' \
|
|||
--role='roles/artifactregistry.writer'
|
||||
```
|
||||
|
||||
For a list of available claims, see OIDC custom claims.
|
||||
For a list of available claims, see [OIDC custom claims](../../../integration/google_cloud_iam.md#oidc-custom-claims).
|
||||
|
||||
### Examples
|
||||
|
||||
|
|
|
|||
|
|
@ -87,9 +87,6 @@ To assign topics to a project:
|
|||
1. In the **Topics** text box, enter the project topics. Popular topics are suggested as you type.
|
||||
1. Select **Save changes**.
|
||||
|
||||
NOTE:
|
||||
The assigned topics are visible only to users with access to the project, but everyone can see which topics exist on the GitLab instance. Do not include sensitive information in the name of a topic.
|
||||
|
||||
## Administer topics
|
||||
|
||||
Instance administrators can administer all project topics from the
|
||||
|
|
|
|||
|
|
@ -517,10 +517,14 @@ If a task is closed with a locked discussion, then you cannot reopen it until th
|
|||
|
||||
## Two-column layout
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/415077) in GitLab 16.2 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default.
|
||||
DETAILS:
|
||||
**Status:** Beta
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/415077) in GitLab 16.2 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default. This feature is in [Beta](../policy/experiment-beta-support.md).
|
||||
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/446064) to feature flag named `work_items_beta` in GitLab 16.10. Disabled by default.
|
||||
|
||||
FLAG:
|
||||
On self-managed GitLab, by default this feature is not available. To make it available, an administrator can [enable the feature flag](../administration/feature_flags.md) named `work_items_mvc_2`.
|
||||
On self-managed GitLab, by default this feature is not available. To make it available per group, an administrator can [enable the feature flag](../administration/feature_flags.md) named `work_items_beta`.
|
||||
On GitLab.com and GitLab Dedicated, this feature is not available.
|
||||
This feature is not ready for production use.
|
||||
|
||||
|
|
@ -528,7 +532,10 @@ When enabled, tasks use a two-column layout, similar to issues.
|
|||
The description and threads are on the left, and attributes, such as labels
|
||||
or assignees, on the right.
|
||||
|
||||
|
||||
This feature is in [Beta](../policy/experiment-beta-support.md).
|
||||
If you find a bug, [comment on the feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/442090).
|
||||
|
||||
|
||||
|
||||
## Linked items in tasks
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,9 @@ describe('containsSensitiveToken', () => {
|
|||
'token: GlPat-abcdefghijklmnopqrstuvwxyz',
|
||||
'token: feed_token=ABCDEFGHIJKLMNOPQRSTUVWXYZ',
|
||||
'token: feed_token=glft-ABCDEFGHIJKLMNOPQRSTUVWXYZ',
|
||||
'glft-ABCDEFGHIJKLMNOPQRSTUVWXYZ',
|
||||
'token: feed_token=glft-a8cc74ccb0de004d09a968705ba49099229b288b3de43f26c473a9d8d7fb7693-1234',
|
||||
'glft-a8cc74ccb0de004d09a968705ba49099229b288b3de43f26c473a9d8d7fb7693-1234',
|
||||
'token: gloas-a8cc74ccb0de004d09a968705ba49099229b288b3de43f26c473a9d8d7fb7693',
|
||||
'https://example.com/feed?feed_token=123456789_abcdefghij',
|
||||
'glpat-1234567890 and feed_token=ABCDEFGHIJKLMNOPQRSTUVWXYZ',
|
||||
|
|
@ -39,6 +41,9 @@ describe('containsSensitiveToken', () => {
|
|||
'Use this secret job token: glcbt-1_cgyKc1k_AsnEpmP-5fRL',
|
||||
'token: glffct-cgyKc1k_AsnEpmP-5fRL',
|
||||
'Here is the runner token for this job:glrt-abc123_x-yzABCDEF01234',
|
||||
'token: glimt-abde52f19d2e53e987d14c8ea',
|
||||
'token: glagent-3ed828e723deff468979daf3bf007f9f528c959911bdeea90f',
|
||||
'token: glptt-dfc184477c9d3987c7b837e541063577f2ad6426',
|
||||
];
|
||||
|
||||
it.each(sensitiveMessages)('returns true for message: %s', (message) => {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,58 @@
|
|||
import { GlBadge } from '@gitlab/ui';
|
||||
import projects from 'test_fixtures/api/users/projects/get.json';
|
||||
import { shallowMountExtended } from 'helpers/vue_test_utils_helper';
|
||||
import { convertObjectPropsToCamelCase } from '~/lib/utils/common_utils';
|
||||
import ProjectListItemInactiveBadge from '~/vue_shared/components/projects_list/project_list_item_inactive_badge.vue';
|
||||
|
||||
describe('ProjectListItemInactiveBadgeCE', () => {
|
||||
let wrapper;
|
||||
|
||||
const [project] = convertObjectPropsToCamelCase(projects, { deep: true });
|
||||
|
||||
const defaultProps = {
|
||||
project,
|
||||
};
|
||||
|
||||
const createComponent = ({ props = {} } = {}) => {
|
||||
wrapper = shallowMountExtended(ProjectListItemInactiveBadge, {
|
||||
propsData: { ...defaultProps, ...props },
|
||||
});
|
||||
};
|
||||
|
||||
const findGlBadge = () => wrapper.findComponent(GlBadge);
|
||||
|
||||
describe('project is marked as archived', () => {
|
||||
beforeEach(() => {
|
||||
createComponent({
|
||||
props: {
|
||||
project: {
|
||||
...project,
|
||||
archived: true,
|
||||
},
|
||||
},
|
||||
});
|
||||
});
|
||||
|
||||
it('renders badge correctly', () => {
|
||||
expect(findGlBadge().props('variant')).toBe('info');
|
||||
expect(findGlBadge().text()).toBe('Archived');
|
||||
});
|
||||
});
|
||||
|
||||
describe('project is not marked as archived', () => {
|
||||
beforeEach(() => {
|
||||
createComponent({
|
||||
props: {
|
||||
project: {
|
||||
...project,
|
||||
archived: false,
|
||||
},
|
||||
},
|
||||
});
|
||||
});
|
||||
|
||||
it('does not render badge', () => {
|
||||
expect(findGlBadge().exists()).toBe(false);
|
||||
});
|
||||
});
|
||||
});
|
||||
|
|
@ -2,6 +2,7 @@ import { GlAvatarLabeled, GlBadge, GlIcon, GlPopover } from '@gitlab/ui';
|
|||
import uniqueId from 'lodash/uniqueId';
|
||||
import projects from 'test_fixtures/api/users/projects/get.json';
|
||||
import { mountExtended } from 'helpers/vue_test_utils_helper';
|
||||
import ProjectListItemInactiveBadge from 'ee_else_ce/vue_shared/components/projects_list/project_list_item_inactive_badge.vue';
|
||||
import ProjectsListItem from '~/vue_shared/components/projects_list/projects_list_item.vue';
|
||||
import ListActions from '~/vue_shared/components/list_actions/list_actions.vue';
|
||||
import { ACTION_EDIT, ACTION_DELETE } from '~/vue_shared/components/list_actions/constants';
|
||||
|
|
@ -53,7 +54,7 @@ describe('ProjectsListItem', () => {
|
|||
const findVisibilityIcon = () => findAvatarLabeled().findComponent(GlIcon);
|
||||
const findListActions = () => wrapper.findComponent(ListActions);
|
||||
const findAccessLevelBadge = () => wrapper.findByTestId('access-level-badge');
|
||||
const findInactiveBadge = () => wrapper.findByTestId('inactive-badge');
|
||||
const findInactiveBadge = () => wrapper.findComponent(ProjectListItemInactiveBadge);
|
||||
|
||||
beforeEach(() => {
|
||||
uniqueId.mockImplementation(jest.requireActual('lodash/uniqueId'));
|
||||
|
|
@ -133,42 +134,10 @@ describe('ProjectsListItem', () => {
|
|||
});
|
||||
});
|
||||
|
||||
describe('project is marked as inactive', () => {
|
||||
describe('archived', () => {
|
||||
beforeEach(() => {
|
||||
createComponent({
|
||||
propsData: {
|
||||
project: {
|
||||
...project,
|
||||
archived: true,
|
||||
},
|
||||
},
|
||||
});
|
||||
});
|
||||
it('renders inactive badge', () => {
|
||||
createComponent();
|
||||
|
||||
it('renders badge correctly', () => {
|
||||
expect(findInactiveBadge().props('variant')).toBe('info');
|
||||
expect(findInactiveBadge().text()).toBe('Archived');
|
||||
});
|
||||
});
|
||||
|
||||
describe('pending deletion', () => {
|
||||
beforeEach(() => {
|
||||
createComponent({
|
||||
propsData: {
|
||||
project: {
|
||||
...project,
|
||||
markedForDeletionOn: '2024-01-01',
|
||||
},
|
||||
},
|
||||
});
|
||||
});
|
||||
|
||||
it('renders badge correctly', () => {
|
||||
expect(findInactiveBadge().props('variant')).toBe('warning');
|
||||
expect(findInactiveBadge().text()).toBe('Pending deletion');
|
||||
});
|
||||
});
|
||||
expect(findInactiveBadge().exists()).toBe(true);
|
||||
});
|
||||
|
||||
it('renders stars count', () => {
|
||||
|
|
|
|||
|
|
@ -15,7 +15,8 @@ RSpec.describe Integrations::Jira, feature_category: :integrations do
|
|||
let(:jira_issue_prefix) { '' }
|
||||
let(:jira_issue_regex) { '' }
|
||||
let(:password) { 'jira-password' }
|
||||
let(:project_key) { nil }
|
||||
let(:project_key) { 'TEST' }
|
||||
let(:project_keys) { %w[TEST1 TEST2] }
|
||||
let(:transition_id) { 'test27' }
|
||||
let(:server_info_results) { { 'deploymentType' => 'Cloud' } }
|
||||
let(:jira_integration) do
|
||||
|
|
@ -24,7 +25,8 @@ RSpec.describe Integrations::Jira, feature_category: :integrations do
|
|||
url: url,
|
||||
username: username,
|
||||
password: password,
|
||||
project_key: project_key
|
||||
project_key: project_key,
|
||||
project_keys: project_keys
|
||||
)
|
||||
end
|
||||
|
||||
|
|
@ -206,7 +208,7 @@ RSpec.describe Integrations::Jira, feature_category: :integrations do
|
|||
subject(:fields) { integration.fields }
|
||||
|
||||
it 'returns custom fields' do
|
||||
expect(fields.pluck(:name)).to eq(%w[url api_url jira_auth_type username password jira_issue_regex jira_issue_prefix jira_issue_transition_id])
|
||||
expect(fields.pluck(:name)).to eq(%w[url api_url jira_auth_type username password jira_issue_regex jira_issue_prefix jira_issue_transition_id project_keys])
|
||||
end
|
||||
end
|
||||
|
||||
|
|
@ -382,7 +384,9 @@ RSpec.describe Integrations::Jira, feature_category: :integrations do
|
|||
username: username, password: password,
|
||||
jira_issue_regex: jira_issue_regex,
|
||||
jira_issue_prefix: jira_issue_prefix,
|
||||
jira_issue_transition_id: transition_id
|
||||
jira_issue_transition_id: transition_id,
|
||||
project_key: project_key,
|
||||
project_keys: project_keys
|
||||
}
|
||||
end
|
||||
|
||||
|
|
@ -402,6 +406,18 @@ RSpec.describe Integrations::Jira, feature_category: :integrations do
|
|||
expect(integration.jira_tracker_data.jira_issue_prefix).to eq(jira_issue_prefix)
|
||||
expect(integration.jira_tracker_data.jira_issue_transition_id).to eq(transition_id)
|
||||
expect(integration.jira_tracker_data.deployment_cloud?).to be_truthy
|
||||
expect(integration.jira_tracker_data.project_key).to eq(project_key)
|
||||
expect(integration.jira_tracker_data.project_keys).to eq(project_keys)
|
||||
end
|
||||
|
||||
context 'when the jira_multiple_project_keys feature is disabled' do
|
||||
before do
|
||||
stub_feature_flags(jira_multiple_project_keys: false)
|
||||
end
|
||||
|
||||
it 'copies project_key into project_keys' do
|
||||
expect(integration.jira_tracker_data.project_keys).to eq([project_key])
|
||||
end
|
||||
end
|
||||
|
||||
context 'when loading serverInfo' do
|
||||
|
|
|
|||
|
|
@ -225,4 +225,11 @@ RSpec.describe ServiceResponse, feature_category: :shared do
|
|||
expect(status).to eq(:error)
|
||||
end
|
||||
end
|
||||
|
||||
describe '#cause' do
|
||||
it 'returns a string inquirer' do
|
||||
response = described_class.error(message: 'Bad apple', reason: :invalid_input)
|
||||
expect(response.cause).to be_invalid_input
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -2732,22 +2732,6 @@
|
|||
- './ee/spec/services/security/ingestion/ingest_report_slice_service_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/ingest_reports_service_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/mark_as_resolved_service_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/attach_findings_to_vulnerabilities_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/hooks_execution_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_finding_evidence_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_finding_identifiers_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_finding_links_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_finding_pipelines_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_finding_signatures_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_findings_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_identifiers_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_remediations_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_vulnerabilities/create_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_vulnerabilities/mark_resolved_as_detected_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_vulnerabilities_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_vulnerability_flags_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/ingest_vulnerability_statistics_spec.rb'
|
||||
- './ee/spec/services/security/ingestion/tasks/update_vulnerability_uuids_spec.rb'
|
||||
- './ee/spec/services/security/merge_reports_service_spec.rb'
|
||||
- './ee/spec/services/security/orchestration/assign_service_spec.rb'
|
||||
- './ee/spec/services/security/orchestration/unassign_service_spec.rb'
|
||||
|
|
|
|||
|
|
@ -1,7 +1,29 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
RSpec.shared_examples 'a time trackable' do
|
||||
describe '#reload' do
|
||||
it 'clears memoized total_time_spent' do
|
||||
expect(trackable).to receive(:clear_memoization).with(:total_time_spent)
|
||||
|
||||
trackable.reload
|
||||
end
|
||||
end
|
||||
|
||||
describe '#reset' do
|
||||
it 'clears memoized total_time_spent' do
|
||||
expect(trackable).to receive(:clear_memoization).with(:total_time_spent)
|
||||
|
||||
trackable.reset
|
||||
end
|
||||
end
|
||||
|
||||
describe '#total_time_spent' do
|
||||
let(:user) { create(:user) }
|
||||
|
||||
before do
|
||||
trackable.project.add_developer(user)
|
||||
end
|
||||
|
||||
context 'when total time spent exceeds the allowed limit' do
|
||||
let(:time_spent) { Timelog::MAX_TOTAL_TIME_SPENT + 1.second }
|
||||
|
||||
|
|
@ -21,5 +43,15 @@ RSpec.shared_examples 'a time trackable' do
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when trackable is saved' do
|
||||
it 'gets cleared' do
|
||||
allow(trackable).to receive(:clear_memoization)
|
||||
|
||||
trackable.save!
|
||||
|
||||
expect(trackable).to have_received(:clear_memoization).with(:total_time_spent)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue