Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
200217febe
commit
9e832dded2
|
|
@ -49,6 +49,7 @@ export default {
|
|||
'issuableType',
|
||||
'isGroupBoard',
|
||||
'fullPath',
|
||||
'commentTemplatePaths',
|
||||
],
|
||||
props: {
|
||||
boardId: {
|
||||
|
|
@ -370,6 +371,7 @@ export default {
|
|||
:open="Boolean(activeIssuable && activeIssuable.iid)"
|
||||
:active-item="activeIssuable"
|
||||
:issuable-type="issuableType"
|
||||
:new-comment-template-paths="commentTemplatePaths"
|
||||
click-outside-exclude-selector=".board-card"
|
||||
@close="
|
||||
onDrawerClosed();
|
||||
|
|
|
|||
|
|
@ -68,6 +68,7 @@ function mountBoardApp(el) {
|
|||
wiHasScopedLabelsFeature,
|
||||
wiGroupPath,
|
||||
wiCanAdminLabel,
|
||||
wiNewCommentTemplatePaths,
|
||||
} = el.dataset;
|
||||
|
||||
const rawFilterParams = queryToObject(window.location.search, { gatherArrays: true });
|
||||
|
|
@ -140,6 +141,7 @@ function mountBoardApp(el) {
|
|||
hasSubepicsFeature: parseBoolean(el.dataset.subEpicsFeatureAvailable),
|
||||
hasLinkedItemsEpicsFeature: parseBoolean(el.dataset.hasLinkedItemsEpicsFeature),
|
||||
hasOkrsFeature: parseBoolean(el.dataset.hasOkrsFeature),
|
||||
commentTemplatePaths: JSON.parse(wiNewCommentTemplatePaths),
|
||||
},
|
||||
render: (createComponent) => createComponent(BoardApp),
|
||||
});
|
||||
|
|
|
|||
|
|
@ -198,6 +198,7 @@ export default {
|
|||
'rssPath',
|
||||
'showNewIssueLink',
|
||||
'groupId',
|
||||
'commentTemplatePaths',
|
||||
],
|
||||
props: {
|
||||
eeSearchTokens: {
|
||||
|
|
@ -946,6 +947,7 @@ export default {
|
|||
:open="isIssuableSelected"
|
||||
:active-item="activeIssuable"
|
||||
:issuable-type="$options.issuableType"
|
||||
:new-comment-template-paths="commentTemplatePaths"
|
||||
click-outside-exclude-selector=".issuable-list"
|
||||
@close="activeIssuable = null"
|
||||
@work-item-updated="updateIssuablesCache"
|
||||
|
|
|
|||
|
|
@ -118,6 +118,7 @@ export async function mountIssuesListApp() {
|
|||
wiIssuesListPath,
|
||||
wiLabelsManagePath,
|
||||
wiReportAbusePath,
|
||||
wiNewCommentTemplatePaths,
|
||||
hasLinkedItemsEpicsFeature,
|
||||
} = el.dataset;
|
||||
|
||||
|
|
@ -204,6 +205,7 @@ export async function mountIssuesListApp() {
|
|||
reportAbusePath: wiReportAbusePath,
|
||||
hasSubepicsFeature: false,
|
||||
hasLinkedItemsEpicsFeature: parseBoolean(hasLinkedItemsEpicsFeature),
|
||||
commentTemplatePaths: JSON.parse(wiNewCommentTemplatePaths),
|
||||
},
|
||||
render: (createComponent) => createComponent(IssuesListApp),
|
||||
});
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
<script>
|
||||
import { GlButton, GlAlert, GlTabs, GlTab, GlLink } from '@gitlab/ui';
|
||||
import { GlButton, GlAlert, GlTabs, GlTab, GlLink, GlBanner } from '@gitlab/ui';
|
||||
import mergeRequestIllustration from '@gitlab/svgs/dist/illustrations/merge-requests-sm.svg';
|
||||
import { helpPagePath } from '~/helpers/help_page_helper';
|
||||
import UserCalloutDismisser from '~/vue_shared/components/user_callout_dismisser.vue';
|
||||
import TabTitle from './tab_title.vue';
|
||||
import MergeRequestsQuery from './merge_requests_query.vue';
|
||||
import CollapsibleSection from './collapsible_section.vue';
|
||||
|
|
@ -13,6 +15,8 @@ export default {
|
|||
GlTabs,
|
||||
GlTab,
|
||||
GlLink,
|
||||
GlBanner,
|
||||
UserCalloutDismisser,
|
||||
TabTitle,
|
||||
MergeRequestsQuery,
|
||||
CollapsibleSection,
|
||||
|
|
@ -42,12 +46,34 @@ export default {
|
|||
.map((list) => ({ query: list.query, variables: list.variables }));
|
||||
},
|
||||
},
|
||||
mergeRequestIllustration,
|
||||
docsPath: helpPagePath('/tutorials/merge_requests/homepage.html'),
|
||||
};
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<div>
|
||||
<user-callout-dismisser feature-name="new_merge_request_dashboard_welcome">
|
||||
<template #default="{ shouldShowCallout, dismiss }">
|
||||
<gl-banner
|
||||
v-if="shouldShowCallout"
|
||||
:title="__('New, streamlined merge request homepage!')"
|
||||
variant="introduction"
|
||||
:button-text="__('See how it works')"
|
||||
:button-link="$options.docsPath"
|
||||
:svg-path="$options.mergeRequestIllustration"
|
||||
@close="dismiss"
|
||||
>
|
||||
<p>
|
||||
{{
|
||||
__(
|
||||
"Welcome to the new merge request homepage! This page gives you a centralized view of all the merge requests you're working on. Know at a glance what merge requests need your attention first so you can spend less time checking in, and more time reviewing and responding to feedback.",
|
||||
)
|
||||
}}
|
||||
</p>
|
||||
</gl-banner>
|
||||
</template>
|
||||
</user-callout-dismisser>
|
||||
<gl-tabs no-key-nav>
|
||||
<gl-tab
|
||||
v-for="tab in tabs"
|
||||
|
|
|
|||
|
|
@ -1115,6 +1115,7 @@ export default {
|
|||
:active-item="activeChildItem"
|
||||
:open="isItemSelected"
|
||||
:issuable-type="activeChildItemType"
|
||||
:new-comment-template-paths="newCommentTemplatePaths"
|
||||
click-outside-exclude-selector=".issuable-list"
|
||||
@close="activeChildItem = null"
|
||||
@workItemDeleted="deleteChildItem"
|
||||
|
|
|
|||
|
|
@ -55,6 +55,11 @@ export default {
|
|||
required: false,
|
||||
default: null,
|
||||
},
|
||||
newCommentTemplatePaths: {
|
||||
type: Array,
|
||||
required: false,
|
||||
default: () => [],
|
||||
},
|
||||
},
|
||||
data() {
|
||||
return {
|
||||
|
|
@ -280,6 +285,7 @@ export default {
|
|||
:work-item-iid="activeItem.iid"
|
||||
:modal-work-item-full-path="activeItemFullPath"
|
||||
:modal-is-group="modalIsGroup"
|
||||
:new-comment-template-paths="newCommentTemplatePaths"
|
||||
is-drawer
|
||||
class="work-item-drawer !gl-pt-0 xl:!gl-px-6"
|
||||
@deleteWorkItem="deleteWorkItem"
|
||||
|
|
|
|||
|
|
@ -134,6 +134,11 @@ export default {
|
|||
required: false,
|
||||
default: true,
|
||||
},
|
||||
newCommentTemplatePaths: {
|
||||
type: Array,
|
||||
required: false,
|
||||
default: () => [],
|
||||
},
|
||||
},
|
||||
data() {
|
||||
return {
|
||||
|
|
@ -683,6 +688,7 @@ export default {
|
|||
:active-item="activeItem"
|
||||
:open="isItemSelected"
|
||||
:issuable-type="activeWorkItemType"
|
||||
:new-comment-template-paths="newCommentTemplatePaths"
|
||||
click-outside-exclude-selector=".issuable-list"
|
||||
@close="activeItem = null"
|
||||
@addChild="refetchItems"
|
||||
|
|
|
|||
|
|
@ -99,7 +99,8 @@ module Users
|
|||
new_mr_dashboard_banner: 96,
|
||||
planner_role_callout: 97,
|
||||
# EE-only
|
||||
pipl_compliance_alert: 98
|
||||
pipl_compliance_alert: 98,
|
||||
new_merge_request_dashboard_welcome: 99
|
||||
}
|
||||
|
||||
validates :feature_name,
|
||||
|
|
|
|||
|
|
@ -5,5 +5,5 @@ introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/161076
|
|||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/428577
|
||||
milestone: '17.8'
|
||||
group: group::authentication
|
||||
type: gitlab_com_derisk
|
||||
default_enabled: false
|
||||
type: beta
|
||||
default_enabled: true
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
name: sbom_ingest_unknown_licenses_with_count
|
||||
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/482764
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179373
|
||||
rollout_issue_url:
|
||||
milestone: '17.9'
|
||||
group: group::security insights
|
||||
type: wip
|
||||
default_enabled: false
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
- title: "Secret detection analyzer doesn't run as root user by default"
|
||||
removal_milestone: "18.0"
|
||||
announcement_milestone: "17.9"
|
||||
breaking_change: true
|
||||
breaking_change: false
|
||||
window: 3
|
||||
reporter: abellucci
|
||||
stage: application_security_testing
|
||||
|
|
|
|||
|
|
@ -42507,6 +42507,7 @@ Name of the feature that the callout is for.
|
|||
| <a id="usercalloutfeaturenameenumnamespace_storage_limit_alert_error_threshold"></a>`NAMESPACE_STORAGE_LIMIT_ALERT_ERROR_THRESHOLD` | Callout feature name for namespace_storage_limit_alert_error_threshold. |
|
||||
| <a id="usercalloutfeaturenameenumnamespace_storage_limit_alert_warning_threshold"></a>`NAMESPACE_STORAGE_LIMIT_ALERT_WARNING_THRESHOLD` | Callout feature name for namespace_storage_limit_alert_warning_threshold. |
|
||||
| <a id="usercalloutfeaturenameenumnamespace_storage_pre_enforcement_banner"></a>`NAMESPACE_STORAGE_PRE_ENFORCEMENT_BANNER` | Callout feature name for namespace_storage_pre_enforcement_banner. |
|
||||
| <a id="usercalloutfeaturenameenumnew_merge_request_dashboard_welcome"></a>`NEW_MERGE_REQUEST_DASHBOARD_WELCOME` | Callout feature name for new_merge_request_dashboard_welcome. |
|
||||
| <a id="usercalloutfeaturenameenumnew_mr_dashboard_banner"></a>`NEW_MR_DASHBOARD_BANNER` | Callout feature name for new_mr_dashboard_banner. |
|
||||
| <a id="usercalloutfeaturenameenumnew_top_level_group_alert"></a>`NEW_TOP_LEVEL_GROUP_ALERT` | Callout feature name for new_top_level_group_alert. |
|
||||
| <a id="usercalloutfeaturenameenumnew_user_signups_cap_reached"></a>`NEW_USER_SIGNUPS_CAP_REACHED` | Callout feature name for new_user_signups_cap_reached. |
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ You can deploy an application to Heroku by using GitLab CI/CD.
|
|||
1. In Heroku:
|
||||
1. Create an application and copy the application name.
|
||||
1. Browse to **Account Settings** and copy the API key.
|
||||
1. In your GitLab project, create two [variables](../../ci/variables/index.md):
|
||||
1. In your GitLab project, create two [variables](../variables/index.md):
|
||||
- `HEROKU_APP_NAME` for the application name.
|
||||
- `HEROKU_PRODUCTION_KEY` for the API key
|
||||
1. Edit your `.gitlab-ci.yml` file to add the Heroku deployment command. This example uses the `dpl` gem for Ruby:
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ This section provides practical examples of implementing common patterns in CI/C
|
|||
### Use boolean inputs to conditionally configure jobs
|
||||
|
||||
You can compose jobs with two conditionals by combining `boolean` type inputs and
|
||||
[`extends`](../../ci/yaml/index.md#extends) functionality.
|
||||
[`extends`](../yaml/index.md#extends) functionality.
|
||||
|
||||
For example, to configure complex caching behavior with a `boolean` input:
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ the appropriate configuration is selected from the predefined hidden jobs
|
|||
### Use `options` to conditionally configure jobs
|
||||
|
||||
You can compose jobs with multiple options, for behavior similar to `if` and `elseif`
|
||||
conditionals. Use the [`extends`](../../ci/yaml/index.md#extends) with `string` type
|
||||
conditionals. Use the [`extends`](../yaml/index.md#extends) with `string` type
|
||||
and multiple `options` for any number of conditions.
|
||||
|
||||
For example, to configure complex caching behavior with 3 different options:
|
||||
|
|
|
|||
|
|
@ -248,7 +248,7 @@ This section describes some best practices for creating high quality component p
|
|||
While it's possible for a component to use other components in turn, make sure to carefully select the dependencies. To manage dependencies, you should:
|
||||
|
||||
- Keep dependencies to a minimum. A small amount of duplication is usually better than having dependencies.
|
||||
- Rely on local dependencies whenever possible. For example, using [`include:local`](../../ci/yaml/index.md#includelocal) is a good way
|
||||
- Rely on local dependencies whenever possible. For example, using [`include:local`](../yaml/index.md#includelocal) is a good way
|
||||
to ensure the same Git SHA is used across multiple files.
|
||||
- When depending on components from other projects, pin their version to a release from the catalog rather than using moving target
|
||||
versions such as `~latest` or a Git reference. Using a release or Git SHA guarantees that you are fetching the same revision
|
||||
|
|
@ -771,7 +771,7 @@ When using third-party CI/CD components, consider the following security best pr
|
|||
with self-managed runners.
|
||||
- **Securely handle cache and artifacts**: Do not pass cache or artifacts from other jobs
|
||||
in your pipeline to CI/CD component jobs unless absolutely necessary.
|
||||
- **Limit CI_JOB_TOKEN access**: Restrict [CI/CD job token (`CI_JOB_TOKEN`) project access and permissions](../../ci/jobs/ci_job_token.md#control-job-token-access-to-your-project)
|
||||
- **Limit CI_JOB_TOKEN access**: Restrict [CI/CD job token (`CI_JOB_TOKEN`) project access and permissions](../jobs/ci_job_token.md#control-job-token-access-to-your-project)
|
||||
for projects using CI/CD components.
|
||||
- **Review CI/CD component changes**: Carefully review all changes to the CI/CD component configuration
|
||||
before changing to use an updated commit SHA or release tag for the component.
|
||||
|
|
|
|||
|
|
@ -333,7 +333,7 @@ A Pipeline that has more jobs than the instance's defined [CI/CD limits](../admi
|
|||
fails to start.
|
||||
|
||||
To reduce the number of jobs in a single pipeline, you can split your `.gitlab-ci.yml`
|
||||
configuration into more independent [parent-child pipelines](../ci/pipelines/pipeline_architectures.md#parent-child-pipelines).
|
||||
configuration into more independent [parent-child pipelines](pipelines/pipeline_architectures.md#parent-child-pipelines).
|
||||
|
||||
## Pipeline warnings
|
||||
|
||||
|
|
@ -488,8 +488,8 @@ To resolve this, see the [workaround in issue 352382](https://gitlab.com/gitlab-
|
|||
|
||||
### `config should be an array of hashes` error message
|
||||
|
||||
You might see an error similar to the following when using [`!reference` tags](../ci/yaml/yaml_optimization.md#reference-tags)
|
||||
with the [`parallel:matrix` keyword](../ci/yaml/index.md#parallelmatrix):
|
||||
You might see an error similar to the following when using [`!reference` tags](yaml/yaml_optimization.md#reference-tags)
|
||||
with the [`parallel:matrix` keyword](yaml/index.md#parallelmatrix):
|
||||
|
||||
```plaintext
|
||||
This GitLab CI configuration is invalid: jobs:my_job_name:parallel:matrix config should be an array of hashes.
|
||||
|
|
|
|||
|
|
@ -816,7 +816,7 @@ You might get an error that says
|
|||
`docker: error during connect: Post https://docker:2376/v1.40/containers/create: dial tcp: lookup docker on x.x.x.x:53: no such host`.
|
||||
|
||||
This issue can occur when the service's image name
|
||||
[includes a registry hostname](../../ci/services/index.md#available-settings-for-services). For example:
|
||||
[includes a registry hostname](../services/index.md#available-settings-for-services). For example:
|
||||
|
||||
```yaml
|
||||
default:
|
||||
|
|
@ -825,7 +825,7 @@ default:
|
|||
- registry.hub.docker.com/library/docker:24.0.5-dind
|
||||
```
|
||||
|
||||
A service's hostname is [derived from the full image name](../../ci/services/index.md#accessing-the-services).
|
||||
A service's hostname is [derived from the full image name](../services/index.md#accessing-the-services).
|
||||
However, the shorter service hostname `docker` is expected.
|
||||
To allow service resolution and access, add an explicit alias for the service name `docker`:
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ rollout 10%:
|
|||
|
||||
After the jobs are built, select **Run** (**{play}**) next to the job's name
|
||||
to release each stage of pods. You can also rollback by running a lower percentage job. Once 100%
|
||||
is reached, you cannot roll back using this method. To roll back a deployment, see [retry or roll back a deployment](../../ci/environments/deployments.md#retry-or-roll-back-a-deployment).
|
||||
is reached, you cannot roll back using this method. To roll back a deployment, see [retry or roll back a deployment](../environments/deployments.md#retry-or-roll-back-a-deployment).
|
||||
|
||||
A [deployable application](https://gitlab.com/gl-release/incremental-rollout-example) is
|
||||
available, demonstrating manually triggered incremental rollouts.
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Dynamic environments:
|
|||
- Have dynamic names, usually based on the value of a CI/CD variable.
|
||||
- Are a feature of [review apps](../review_apps/index.md).
|
||||
|
||||
An environment has one of three states, depending on whether its [stop job](../../ci/yaml/index.md#environmenton_stop) has run:
|
||||
An environment has one of three states, depending on whether its [stop job](../yaml/index.md#environmenton_stop) has run:
|
||||
|
||||
- `available`: The environment exists. There might be a deployment.
|
||||
- `stopping`: The _on stop job_ has started. This state does not apply when there is no on stop job defined.
|
||||
|
|
@ -238,7 +238,7 @@ Note the following:
|
|||
- If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
|
||||
the environment URL.
|
||||
- If the script that runs in `stop_review` exists only in your repository and therefore can't use
|
||||
`GIT_STRATEGY: none` or `GIT_STRATEGY: empty`, configure [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md)
|
||||
`GIT_STRATEGY: none` or `GIT_STRATEGY: empty`, configure [merge request pipelines](../pipelines/merge_request_pipelines.md)
|
||||
for these jobs. This ensures that runners can fetch the repository even after a feature branch is
|
||||
deleted. For more information, see [Ref Specs for Runners](../pipelines/index.md#ref-specs-for-runners).
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ To achieve the same result as renaming an environment:
|
|||
## CI/CD variables
|
||||
|
||||
To customize your environments and deployments, you can use any of the
|
||||
[predefined CI/CD variables](../../ci/variables/predefined_variables.md),
|
||||
[predefined CI/CD variables](../variables/predefined_variables.md),
|
||||
and define custom CI/CD variables.
|
||||
|
||||
### Limit the environment scope of a CI/CD variable
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ and the product documentation refers to it as the `.gitlab-ci.yml` file or the C
|
|||
For more information, see:
|
||||
|
||||
- [Tutorial: Create your first `.gitlab-ci.yml` file](quick_start/index.md)
|
||||
- [The CI/CD YAML syntax reference](../ci/yaml/index.md), which lists all possible keywords
|
||||
- [The CI/CD YAML syntax reference](yaml/index.md), which lists all possible keywords
|
||||
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Continuous Integration overview](https://www.youtube-nocookie.com/embed/eyr5YnkWq_I)
|
||||
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Continuous Delivery overview](https://www.youtube-nocookie.com/embed/M7rBDZYsx8U)
|
||||
- [Basics of CI blog](https://about.gitlab.com/blog/2020/12/10/basics-of-gitlab-ci-updated/)
|
||||
|
|
|
|||
|
|
@ -753,7 +753,7 @@ the following questions in preparation:
|
|||
Before doing any migration work, you should first:
|
||||
|
||||
1. Get familiar with GitLab.
|
||||
- Read about the [key GitLab CI/CD features](../../ci/index.md).
|
||||
- Read about the [key GitLab CI/CD features](../index.md).
|
||||
- Follow tutorials to create [your first GitLab pipeline](../quick_start/index.md)
|
||||
and [more complex pipelines](../quick_start/tutorial.md) that build, test, and deploy
|
||||
a static site.
|
||||
|
|
|
|||
|
|
@ -306,8 +306,8 @@ Pipelines can also be [scheduled by using Cron syntax](../pipelines/schedules.md
|
|||
|
||||
#### Container Images
|
||||
|
||||
With GitLab you can [run your CI/CD jobs in separate, isolated Docker containers](../../ci/docker/using_docker_images.md)
|
||||
by using the [`image`](../../ci/yaml/index.md#image) keyword.
|
||||
With GitLab you can [run your CI/CD jobs in separate, isolated Docker containers](../docker/using_docker_images.md)
|
||||
by using the [`image`](../yaml/index.md#image) keyword.
|
||||
|
||||
For example, in a GitHub Actions `workflow` file:
|
||||
|
||||
|
|
@ -430,7 +430,7 @@ login:
|
|||
```
|
||||
|
||||
Additionally, [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/contexts)
|
||||
and [GitLab CI/CD](../../ci/variables/predefined_variables.md) provide built-in variables
|
||||
and [GitLab CI/CD](../variables/predefined_variables.md) provide built-in variables
|
||||
which contain data relevant to the pipeline and repository.
|
||||
|
||||
#### Conditionals
|
||||
|
|
@ -510,8 +510,8 @@ windows_job:
|
|||
|
||||
#### Artifacts
|
||||
|
||||
In GitLab, any job can use the [artifacts](../../ci/yaml/index.md#artifacts) keyword to define a set
|
||||
of artifacts to be stored when a job completes. [Artifacts](../../ci/jobs/job_artifacts.md) are files
|
||||
In GitLab, any job can use the [artifacts](../yaml/index.md#artifacts) keyword to define a set
|
||||
of artifacts to be stored when a job completes. [Artifacts](../jobs/job_artifacts.md) are files
|
||||
that can be used in later jobs.
|
||||
|
||||
For example, in a GitHub Actions `workflow` file:
|
||||
|
|
@ -562,7 +562,7 @@ use_cat:
|
|||
|
||||
#### Caching
|
||||
|
||||
A [cache](../../ci/caching/index.md) is created when a job downloads one or more files and
|
||||
A [cache](../caching/index.md) is created when a job downloads one or more files and
|
||||
saves them for faster access in the future. Subsequent jobs that use the same cache don't have to download the files again,
|
||||
so they execute more quickly. The cache is stored on the runner and uploaded to S3 if
|
||||
[distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
|
||||
|
|
@ -597,7 +597,7 @@ cache-job:
|
|||
|
||||
In GitHub an Action is a set of complex tasks that need to be frequently repeated and is saved
|
||||
to enable reuse without redefining a CI/CD pipeline. In GitLab the equivalent to an action would
|
||||
be a the [`include` keyword](../yaml/includes.md), which allows you to [add CI/CD pipelines from other files](../../ci/yaml/includes.md),
|
||||
be a the [`include` keyword](../yaml/includes.md), which allows you to [add CI/CD pipelines from other files](../yaml/includes.md),
|
||||
including template files built into GitLab.
|
||||
|
||||
Sample GitHub Actions configuration:
|
||||
|
|
@ -675,7 +675,7 @@ Before starting a migration you should create a [migration plan](plan_a_migratio
|
|||
Before doing any migration work, you should first:
|
||||
|
||||
1. Get familiar with GitLab.
|
||||
- Read about the [key GitLab CI/CD features](../../ci/index.md).
|
||||
- Read about the [key GitLab CI/CD features](../index.md).
|
||||
- Follow tutorials to create [your first GitLab pipeline](../quick_start/index.md) and [more complex pipelines](../quick_start/tutorial.md) that build, test, and deploys a static site.
|
||||
- Review the [CI/CD YAML syntax reference](../yaml/index.md).
|
||||
1. Set up and configure GitLab.
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ from Jenkins to GitLab CI/CD.
|
|||
|
||||
[Jenkins pipelines](https://www.jenkins.io/doc/book/pipeline/) generate automated CI/CD jobs
|
||||
that are triggered when certain event take place, such as a new commit being pushed.
|
||||
A Jenkins pipeline is defined in a `Jenkinsfile`. The GitLab equivalent is the [`.gitlab-ci.yml` configuration file](../../ci/yaml/index.md).
|
||||
A Jenkins pipeline is defined in a `Jenkinsfile`. The GitLab equivalent is the [`.gitlab-ci.yml` configuration file](../yaml/index.md).
|
||||
|
||||
Jenkins does not provide a place to store source code, so the `Jenkinsfile` must be stored
|
||||
in a separate source control repository.
|
||||
|
|
@ -316,8 +316,8 @@ deploy-job:
|
|||
|
||||
#### Container Images
|
||||
|
||||
In GitLab you can [run your CI/CD jobs in separate, isolated Docker containers](../../ci/docker/using_docker_images.md)
|
||||
using the [image](../../ci/yaml/index.md#image) keyword.
|
||||
In GitLab you can [run your CI/CD jobs in separate, isolated Docker containers](../docker/using_docker_images.md)
|
||||
using the [image](../yaml/index.md#image) keyword.
|
||||
|
||||
For example, in a `Jenkinsfile`:
|
||||
|
||||
|
|
@ -541,8 +541,8 @@ windows_job:
|
|||
|
||||
#### Artifacts
|
||||
|
||||
In GitLab, any job can use the [`artifacts`](../../ci/yaml/index.md#artifacts) keyword to define a set of artifacts to
|
||||
be stored when a job completes. [Artifacts](../../ci/jobs/job_artifacts.md) are files that can be used in later jobs,
|
||||
In GitLab, any job can use the [`artifacts`](../yaml/index.md#artifacts) keyword to define a set of artifacts to
|
||||
be stored when a job completes. [Artifacts](../jobs/job_artifacts.md) are files that can be used in later jobs,
|
||||
for example for testing or deployment.
|
||||
|
||||
For example, in a `Jenkinsfile`:
|
||||
|
|
@ -597,7 +597,7 @@ use_cat:
|
|||
|
||||
#### Caching
|
||||
|
||||
A [cache](../../ci/caching/index.md) is created when a job downloads one or more files and
|
||||
A [cache](../caching/index.md) is created when a job downloads one or more files and
|
||||
saves them for faster access in the future. Subsequent jobs that use the same cache don't have to download the files again,
|
||||
so they execute more quickly. The cache is stored on the runner and uploaded to S3 if
|
||||
[distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
|
||||
|
|
@ -705,7 +705,7 @@ Before starting a migration you should create a [migration plan](plan_a_migratio
|
|||
Before doing any migration work, you should first:
|
||||
|
||||
1. Get familiar with GitLab.
|
||||
- Read about the [key GitLab CI/CD features](../../ci/index.md).
|
||||
- Read about the [key GitLab CI/CD features](../index.md).
|
||||
- Follow tutorials to create [your first GitLab pipeline](../quick_start/index.md) and [more complex pipelines](../quick_start/tutorial.md) that build, test, and deploys a static site.
|
||||
- Review the [CI/CD YAML syntax reference](../yaml/index.md).
|
||||
1. Set up and configure GitLab.
|
||||
|
|
|
|||
|
|
@ -184,8 +184,8 @@ spanish:
|
|||
|
||||
Build configurations in TeamCity allow you to define [artifacts](https://www.jetbrains.com/help/teamcity/build-artifact.html) generated during the build process.
|
||||
|
||||
In GitLab, any job can use the [`artifacts`](../../ci/yaml/index.md#artifacts) keyword to define a set of artifacts to
|
||||
be stored when a job completes. [Artifacts](../../ci/jobs/job_artifacts.md) are files that can be used in later jobs,
|
||||
In GitLab, any job can use the [`artifacts`](../yaml/index.md#artifacts) keyword to define a set of artifacts to
|
||||
be stored when a job completes. [Artifacts](../jobs/job_artifacts.md) are files that can be used in later jobs,
|
||||
for testing or deployment.
|
||||
|
||||
For example, a GitLab CI/CD `.gitlab-ci.yml` file that uses artifacts:
|
||||
|
|
@ -265,7 +265,7 @@ For a migration from TeamCity, ask yourself the following questions in preparati
|
|||
Before doing any migration work, you should first:
|
||||
|
||||
1. Get familiar with GitLab.
|
||||
- Read about the [key GitLab CI/CD features](../../ci/index.md).
|
||||
- Read about the [key GitLab CI/CD features](../index.md).
|
||||
- Follow tutorials to create [your first GitLab pipeline](../quick_start/index.md) and [more complex pipelines](../quick_start/tutorial.md) that build, test, and deploys a static site.
|
||||
- Review the [CI/CD YAML syntax reference](../yaml/index.md).
|
||||
1. Set up and configure GitLab.
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ The compute used by one pipeline is the total compute minutes used by all the jo
|
|||
that ran in the pipeline. Jobs can run concurrently, so the total compute usage
|
||||
can be higher than the end-to-end duration of a pipeline.
|
||||
|
||||
[Trigger jobs](../../ci/yaml/index.md#trigger) do not execute on runners, so they do not
|
||||
[Trigger jobs](../yaml/index.md#trigger) do not execute on runners, so they do not
|
||||
consume compute minutes, even when using [`strategy:depend`](../yaml/index.md#triggerstrategy)
|
||||
to wait for the [downstream pipeline](../pipelines/downstream_pipelines.md) status.
|
||||
The triggered downstream pipeline consumes compute minutes the same as other pipelines.
|
||||
|
|
|
|||
|
|
@ -274,7 +274,7 @@ DETAILS:
|
|||
|
||||
WARNING:
|
||||
This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/501460) in GitLab 17.6
|
||||
and is planned for removal in 19.0. Use [CI/CD jobs with pipeline trigger tokens](../../ci/triggers/index.md#use-a-cicd-job) instead.
|
||||
and is planned for removal in 19.0. Use [CI/CD jobs with pipeline trigger tokens](../triggers/index.md#use-a-cicd-job) instead.
|
||||
This is a breaking change.
|
||||
|
||||
You can set up your project to automatically trigger a pipeline based on tags in a different project.
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ For more information about how caching works, see [Architecture diagram of hoste
|
|||
Jobs that run on hosted runners for GitLab.com consume [compute minutes](../../pipelines/compute_minutes.md) allocated to your namespace.
|
||||
The number of minutes you can use on these runners depends on the included compute minutes in your [subscription plan](https://about.gitlab.com/pricing/) or [additionally purchased compute minutes](../../../subscriptions/gitlab_com/compute_minutes.md#purchase-additional-compute-minutes).
|
||||
|
||||
For more information about the cost factor applied to the machine type based on size, see [cost factor](../../../ci/pipelines/compute_minutes.md#gitlab-hosted-runner-cost-factors).
|
||||
For more information about the cost factor applied to the machine type based on size, see [cost factor](../../pipelines/compute_minutes.md#gitlab-hosted-runner-cost-factors).
|
||||
|
||||
### SLO & Release cycle for hosted runners for GitLab.com
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ For more details, see [issue 473739](https://gitlab.com/gitlab-org/gitlab/-/issu
|
|||
## Container images
|
||||
|
||||
As runners on Linux are using the `docker+machine` [executor](https://docs.gitlab.com/runner/executors/#docker-machine-executor),
|
||||
you can choose any container image by defining the [`image`](../../../ci/yaml/index.md#image) in your `.gitlab-ci.yml` file.
|
||||
you can choose any container image by defining the [`image`](../../yaml/index.md#image) in your `.gitlab-ci.yml` file.
|
||||
Please be mindful that the selected Docker image is compatible with the underlying processor architecture.
|
||||
|
||||
If no image is set, the default is `ruby:3.1`.
|
||||
|
|
@ -57,7 +57,7 @@ If no image is set, the default is `ruby:3.1`.
|
|||
## Docker-in-Docker support
|
||||
|
||||
Runners with any of the `saas-linux-<size>-<architecture>` tags are configured to run in `privileged` mode
|
||||
to support [Docker-in-Docker](../../../ci/docker/using_docker_build.md#use-docker-in-docker).
|
||||
to support [Docker-in-Docker](../../docker/using_docker_build.md#use-docker-in-docker).
|
||||
With these runners, you can build Docker images natively or run multiple containers in your isolated job.
|
||||
|
||||
Runners with the `gitlab-org` tag do not run in `privileged` mode and cannot be used for Docker-in-Docker builds.
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ DETAILS:
|
|||
**Offering:** GitLab.com
|
||||
**Status:** Beta
|
||||
|
||||
Hosted runners on macOS provide an on-demand macOS environment, fully integrated with GitLab [CI/CD](../../../ci/index.md).
|
||||
Hosted runners on macOS provide an on-demand macOS environment, fully integrated with GitLab [CI/CD](../../index.md).
|
||||
You can use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, watchOS, tvOS).
|
||||
Our [Mobile DevOps section](../../../ci/mobile_devops/mobile_devops_tutorial_ios.md#set-up-your-build-environment) provides features, documentation, and guidance on building and deploying mobile applications for iOS.
|
||||
Our [Mobile DevOps section](../../mobile_devops/mobile_devops_tutorial_ios.md#set-up-your-build-environment) provides features, documentation, and guidance on building and deploying mobile applications for iOS.
|
||||
|
||||
Hosted runners on macOS are in [beta](../../../policy/development_stages_support.md#beta) and available for open source programs and customers in Premium and Ultimate plans.
|
||||
[General availability](../../../policy/development_stages_support.md#generally-available) of Hosted runners on macOS is proposed in [epic 8267](https://gitlab.com/groups/gitlab-org/-/epics/8267).
|
||||
|
|
@ -88,7 +88,7 @@ Before you can integrate GitLab with Apple services, install to a device, or dep
|
|||
Included in each runner on macOS VM image is [fastlane](https://fastlane.tools/),
|
||||
an open-source solution aimed at simplifying mobile app deployment.
|
||||
|
||||
For information about how to set up code signing for your application, see the instructions in the [Mobile DevOps documentation](../../../ci/mobile_devops/mobile_devops_tutorial_ios.md#configure-code-signing-with-fastlane).
|
||||
For information about how to set up code signing for your application, see the instructions in the [Mobile DevOps documentation](../../mobile_devops/mobile_devops_tutorial_ios.md#configure-code-signing-with-fastlane).
|
||||
|
||||
Related topics:
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ source 'https://cdn.cocoapods.org/'
|
|||
Use caching in Cocoapods packages in GitLab to only run `pod install`
|
||||
when pods change, which can improve build performance.
|
||||
|
||||
To [configure caching](../../../ci/caching/index.md) for your project:
|
||||
To [configure caching](../../caching/index.md) for your project:
|
||||
|
||||
1. Add the `cache` configuration to your `.gitlab-ci.yml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ GitLab offers the following machine type for hosted runners on Windows.
|
|||
## Supported Windows versions
|
||||
|
||||
The Windows runner virtual machine instances do not use the GitLab Docker executor. This means that you can't specify
|
||||
[`image`](../../../ci/yaml/index.md#image) or [`services`](../../../ci/yaml/index.md#services) in your pipeline configuration.
|
||||
[`image`](../../yaml/index.md#image) or [`services`](../../yaml/index.md#services) in your pipeline configuration.
|
||||
|
||||
You can execute your job in one of the following Windows versions:
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Prerequisites:
|
|||
- Have a [Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/general/quick-create-portal) on Azure.
|
||||
- Your IAM user must be [granted the **Key Vault Administrator** role assignment](https://learn.microsoft.com/en-us/azure/role-based-access-control/quickstart-assign-role-user-portal#grant-access)
|
||||
for the **resource group** assigned to the Key Vault. Otherwise, you can't create secrets inside the Key Vault.
|
||||
- [Configure OpenID Connect in Azure to retrieve temporary credentials](../../ci/cloud_services/azure/index.md). These
|
||||
- [Configure OpenID Connect in Azure to retrieve temporary credentials](../cloud_services/azure/index.md). These
|
||||
steps include instructions on how to create an Azure AD application for Key Vault access.
|
||||
- Add [CI/CD variables to your project](../variables/index.md#for-a-project) to provide details about your Vault server:
|
||||
- `AZURE_KEY_VAULT_SERVER_URL`: The URL of your Azure Key Vault server, such as `https://vault.example.com`.
|
||||
|
|
@ -48,7 +48,7 @@ job:
|
|||
|
||||
In this example:
|
||||
|
||||
- `aud` is the audience, which must match the audience used when [creating the federated identity credentials](../../ci/cloud_services/azure/index.md#create-azure-ad-federated-identity-credentials)
|
||||
- `aud` is the audience, which must match the audience used when [creating the federated identity credentials](../cloud_services/azure/index.md#create-azure-ad-federated-identity-credentials)
|
||||
- `name` is the name of the secret in Azure Key Vault.
|
||||
- `version` is the version of the secret in Azure Key Vault. The version is a generated
|
||||
GUID without dashes, which can be found on the Azure Key Vault secrets page.
|
||||
|
|
@ -58,7 +58,7 @@ In this example:
|
|||
|
||||
## Troubleshooting
|
||||
|
||||
Refer to [OIDC for Azure troubleshooting](../../ci/cloud_services/azure/index.md#troubleshooting) for general
|
||||
Refer to [OIDC for Azure troubleshooting](../cloud_services/azure/index.md#troubleshooting) for general
|
||||
problems when setting up OIDC with Azure.
|
||||
|
||||
### `JWT token is invalid or malformed` message
|
||||
|
|
|
|||
|
|
@ -231,10 +231,10 @@ job:
|
|||
file: false
|
||||
```
|
||||
|
||||
Both `VAULT_SERVER_URL` and `VAULT_AUTH_PATH` can be [defined as project or group CI/CD variables](../../ci/variables/index.md#define-a-cicd-variable-in-the-ui),
|
||||
Both `VAULT_SERVER_URL` and `VAULT_AUTH_PATH` can be [defined as project or group CI/CD variables](../variables/index.md#define-a-cicd-variable-in-the-ui),
|
||||
if preferred.
|
||||
|
||||
We use [`secrets:file:false`](../../ci/yaml/index.md#secretsfile) because ID tokens place secrets in a file by default, but we need it to work as a regular variable to match the old behavior.
|
||||
We use [`secrets:file:false`](../yaml/index.md#secretsfile) because ID tokens place secrets in a file by default, but we need it to work as a regular variable to match the old behavior.
|
||||
|
||||
### KV Secrets Engine v2
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ still succeeds even if that warning was printed. For example:
|
|||
because the job is not trying to connect to it, it does not fail.
|
||||
|
||||
If the services start successfully, they start before the
|
||||
[`before_script`](../../ci/yaml/index.md#before_script) runs. This means you can
|
||||
[`before_script`](../yaml/index.md#before_script) runs. This means you can
|
||||
write a `before_script` that queries the service.
|
||||
|
||||
Services stop at the end of the job, even if the job fails.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ When working with Code Quality, you might encounter the following issues.
|
|||
|
||||
You are probably using a private runner with the Docker-in-Docker socket-binding configuration.
|
||||
You should configure Code Quality checks to run on your worker as documented in
|
||||
[Use private runners](../../ci/testing/code_quality_codeclimate_scanning.md#use-private-runners).
|
||||
[Use private runners](../testing/code_quality_codeclimate_scanning.md#use-private-runners).
|
||||
|
||||
## Changing the default configuration has no effect
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ Verify the presence of report on the base commit by obtaining the `base_sha` usi
|
|||
|
||||
## Only a single Code Quality report is displayed, but more are defined
|
||||
|
||||
Code Quality automatically [combines multiple reports](../../ci/testing/code_quality.md#scan-code-for-quality-violations).
|
||||
Code Quality automatically [combines multiple reports](../testing/code_quality.md#scan-code-for-quality-violations).
|
||||
|
||||
In GitLab 15.6 and earlier, Code Quality used only the artifact from the latest created job (with the largest job ID). Code Quality artifacts from earlier jobs were ignored.
|
||||
|
||||
|
|
|
|||
|
|
@ -828,7 +828,7 @@ To limit the use of pipeline variables to only the Maintainer role and higher:
|
|||
When users with the Developer role or lower try to [use pipeline variables](#use-pipeline-variables),
|
||||
they receive the `Insufficient permissions to set pipeline variables` error message.
|
||||
|
||||
If you [store your CI/CD configurations in a different repository](../../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file),
|
||||
If you [store your CI/CD configurations in a different repository](../pipelines/settings.md#specify-a-custom-cicd-configuration-file),
|
||||
use this setting for control over the environment the pipeline runs in.
|
||||
|
||||
#### Set a minimum role for pipeline variables
|
||||
|
|
|
|||
|
|
@ -2356,7 +2356,7 @@ Every time the review app is deployed, that lifetime is also reset to `1 day`.
|
|||
|
||||
The `auto_stop_in` keyword can be used for all [environment actions](#environmentaction) except `stop`.
|
||||
Some actions can be used to reset the scheduled stop time for the environment. For more information, see
|
||||
[Access an environment for preparation or verification purposes](../../ci/environments/index.md#access-an-environment-for-preparation-or-verification-purposes).
|
||||
[Access an environment for preparation or verification purposes](../environments/index.md#access-an-environment-for-preparation-or-verification-purposes).
|
||||
|
||||
**Related topics**:
|
||||
|
||||
|
|
@ -5299,10 +5299,10 @@ In this example, only runners with *both* the `ruby` and `postgres` tags can run
|
|||
- [Use tags to control which jobs a runner can run](../runners/configure_runners.md#control-jobs-that-a-runner-can-run)
|
||||
- [Select different runner tags for each parallel matrix job](../jobs/job_control.md#select-different-runner-tags-for-each-parallel-matrix-job)
|
||||
- Runner tags for hosted runners:
|
||||
- [Hosted runners on Linux](../../ci/runners/hosted_runners/linux.md)
|
||||
- [GPU-enabled hosted runners](../../ci/runners/hosted_runners/gpu_enabled.md)
|
||||
- [Hosted runners on macOS](../../ci/runners/hosted_runners/macos.md)
|
||||
- [Hosted runners on Windows](../../ci/runners/hosted_runners/windows.md)
|
||||
- [Hosted runners on Linux](../runners/hosted_runners/linux.md)
|
||||
- [GPU-enabled hosted runners](../runners/hosted_runners/gpu_enabled.md)
|
||||
- [Hosted runners on macOS](../runners/hosted_runners/macos.md)
|
||||
- [Hosted runners on Windows](../runners/hosted_runners/windows.md)
|
||||
|
||||
### `timeout`
|
||||
|
||||
|
|
|
|||
|
|
@ -968,6 +968,32 @@ allow stubs in `before(:all)`.
|
|||
See this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/340487) for more details.
|
||||
To resolve, use `let`, or change the factory to not use stubs.
|
||||
|
||||
### `let_it_be` must not depend on a before block
|
||||
|
||||
When using `let_it_be` in the middle of a spec, make sure that it does not depend on a `before` block, since the `let_it_be` will be executed first during `before(:all)`.
|
||||
|
||||
In [this example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179302#note_2323774955), `create(:bar)` ran a callback which depended on the stub:
|
||||
|
||||
```ruby
|
||||
let_it_be(:node) { create(:geo_node, :secondary) }
|
||||
|
||||
before do
|
||||
stub_current_geo_node(node)
|
||||
end
|
||||
|
||||
context 'foo' do
|
||||
let_it_be(:bar) { create(:bar) }
|
||||
|
||||
...
|
||||
end
|
||||
```
|
||||
|
||||
The stub isn't set when `create(:bar)` executes, so the tests are flaky.
|
||||
|
||||
In this example, `before` cannot be replaced with `before_all` because you cannot use doubles or partial doubles from RSpec-mocks outside of the per-test lifecycle.
|
||||
|
||||
Therefore, the solution is to use `let` or `let!` instead of `let_it_be(:bar)`.
|
||||
|
||||
### Time-sensitive tests
|
||||
|
||||
[`ActiveSupport::Testing::TimeHelpers`](https://api.rubyonrails.org/classes/ActiveSupport/Testing/TimeHelpers.html)
|
||||
|
|
|
|||
|
|
@ -52,6 +52,7 @@ it's reset to a pristine test after each test.
|
|||
- [Example 7](https://gitlab.com/gitlab-org/quality/engineering-productivity/master-broken-incidents/-/issues/3389#note_1534827164):
|
||||
A TCP socket used in a test was not closed before the next test, which also used
|
||||
the same port with another TCP socket.
|
||||
[Example 8](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179302#note_2324238692): A `let_it_be` depended on a stub defined in a `before` block. `let_it_be` executes during `before(:all)`, so the stub was not yet set. This exposed the tests to the actual method call, which happened to use a method cache.
|
||||
|
||||
#### Dataset-specific
|
||||
|
||||
|
|
|
|||
|
|
@ -6,9 +6,14 @@ description: "Connect and use GitLab Duo in Visual Studio."
|
|||
title: Install and set up the GitLab extension for Visual Studio
|
||||
---
|
||||
|
||||
Download the extension from the
|
||||
[Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio)
|
||||
and install it.
|
||||
To get the extension, use any of these methods:
|
||||
|
||||
- Inside Visual Studio, go to **Extensions > Manage extensions... > Browse**, and search for `GitLab`.
|
||||
- From the [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio).
|
||||
- From GitLab, either from the
|
||||
[list of releases](https://gitlab.com/gitlab-org/editor-extensions/gitlab-visual-studio-extension/-/releases), or by
|
||||
[downloading the latest version](https://gitlab.com/gitlab-org/editor-extensions/gitlab-visual-studio-extension/-/releases/permalink/latest/downloads/GitLab.Extension.vsix)
|
||||
directly.
|
||||
|
||||
The extension requires:
|
||||
|
||||
|
|
|
|||
|
|
@ -91,5 +91,4 @@ This window takes place on May 5 - 7, 2025 from 09:00 UTC to 22:00 UTC.
|
|||
| [Dependency Proxy token scope enforcement](https://gitlab.com/gitlab-org/gitlab/-/issues/426887) | High | Package | Group |
|
||||
| [REST API endpoint `pre_receive_secret_detection_enabled` is deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/514413) | Medium | Application_security_testing | Instance |
|
||||
| [Remove duoProAssignedUsersCount GraphQL field](https://gitlab.com/gitlab-org/gitlab/-/issues/498671) | Low | Plan | Group, project |
|
||||
| [Secret detection analyzer doesn't run as root user by default](https://gitlab.com/gitlab-org/gitlab/-/issues/476160) | Low | Application_security_testing | Instance |
|
||||
| [Remove `previousStageJobsOrNeeds` from GraphQL](https://gitlab.com/gitlab-org/gitlab/-/issues/424417) | Low | Verify | Instance |
|
||||
|
|
|
|||
|
|
@ -1484,14 +1484,14 @@ If you need to use the cache when scanning a project, you can restore the previo
|
|||
|
||||
</div>
|
||||
|
||||
<div class="deprecation breaking-change" data-milestone="18.0">
|
||||
<div class="deprecation " data-milestone="18.0">
|
||||
|
||||
### Secret detection analyzer doesn't run as root user by default
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
||||
- Announced in GitLab <span class="milestone">17.9</span>
|
||||
- Removal in GitLab <span class="milestone">18.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
|
||||
- Removal in GitLab <span class="milestone">18.0</span>
|
||||
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/476160).
|
||||
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -16,8 +16,10 @@ their organization.
|
|||
Security teams can ensure:
|
||||
|
||||
- Security scanners are enforced in development team pipelines with proper configuration.
|
||||
- That all scan jobs execute without any changes or alterations.
|
||||
- That proper approvals are provided on merge requests based on results from those findings.
|
||||
- All scan jobs execute without any changes or alterations.
|
||||
- Proper approvals are provided on merge requests, based on results from those findings.
|
||||
- Vulnerabilities that are no longer detected are resolved automatically, reducing the workload of
|
||||
triaging vulnerabilities.
|
||||
|
||||
Compliance teams can:
|
||||
|
||||
|
|
@ -32,6 +34,8 @@ The following policy types are available:
|
|||
- [Merge request approval policy](merge_request_approval_policies.md). Enforce project-level settings and
|
||||
approval rules based on scan results.
|
||||
- [Pipeline execution policy](pipeline_execution_policies.md). Enforce CI/CD jobs as part of project pipelines.
|
||||
- [Vulnerability management policy](vulnerability_management_policy.md). Automatically resolve
|
||||
vulnerabilities that are no longer detected in the default branch.
|
||||
|
||||
## Security policy project
|
||||
|
||||
|
|
|
|||
|
|
@ -399,6 +399,21 @@ The following table describes the rate limits for GitLab.com:
|
|||
| API requests from a user to `/api/v4/users/:id` | 300 requests per 10 minutes |
|
||||
| GitLab package cloud requests for an IP address ([introduced](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/24083) in GitLab 16.11) | 3,000 requests per minute |
|
||||
| GitLab repository files | 500 requests per minute |
|
||||
| User followers requests (`/api/v4/users/:id/followers`) | 100 requests per minute |
|
||||
| User following requests (`/api/v4/users/:id/following`) | 100 requests per minute |
|
||||
| User status requests (`/api/v4/users/:user_id/status`) | 240 requests per minute |
|
||||
| User SSH keys requests (`/api/v4/users/:user_id/keys`) | 120 requests per minute |
|
||||
| Single SSH key requests (`/api/v4/users/:id/keys/:key_id`) | 120 requests per minute |
|
||||
| User GPG keys requests (`/api/v4/users/:id/gpg_keys`) | 120 requests per minute |
|
||||
| Single GPG key requests (`/api/v4/users/:id/gpg_keys/:key_id`) | 120 requests per minute |
|
||||
| User projects requests (`/api/v4/users/:user_id/projects`) | 300 requests per minute |
|
||||
| User contributed projects requests (`/api/v4/users/:user_id/contributed_projects`) | 100 requests per minute |
|
||||
| User starred projects requests (`/api/v4/users/:user_id/starred_projects`) | 100 requests per minute |
|
||||
| Projects list requests (`/api/v4/projects`) | 2,000 requests per 10 minutes |
|
||||
| Group projects requests (`/api/v4/groups/:id/projects`) | 600 requests per minute |
|
||||
| Single project requests (`/api/v4/projects/:id`) | 400 requests per minute |
|
||||
| Groups list requests (`/api/v4/groups`) | 200 requests per minute |
|
||||
| Single group requests (`/api/v4/groups/:id`) | 400 requests per minute |
|
||||
|
||||
More details are available on the rate limits for
|
||||
[protected paths](#protected-paths-throttle) and
|
||||
|
|
|
|||
|
|
@ -167,7 +167,7 @@ When you delete or block an enterprise user account, their personal access token
|
|||
|
||||
> - In GitLab 16.0 and earlier, token usage information is updated every 24 hours.
|
||||
> - The frequency of token usage information updates [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/410168) in GitLab 16.1 from 24 hours to 10 minutes.
|
||||
> - Ability to view IP addresses [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/428577) in GitLab 17.8 [with a flag](../../administration/feature_flags.md) named `pat_ip`. Disabled by default.
|
||||
> - Ability to view IP addresses [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/428577) in GitLab 17.8 [with a flag](../../administration/feature_flags.md) named `pat_ip`. Enabled by default in 17.9.
|
||||
|
||||
Token usage information is updated every 10 minutes. GitLab considers a token used when the token is used to:
|
||||
|
||||
|
|
|
|||
|
|
@ -5333,6 +5333,9 @@ msgstr ""
|
|||
msgid "AiPowered|Enroll in the Early Access Program"
|
||||
msgstr ""
|
||||
|
||||
msgid "AiPowered|Enter the URL for your local AI Gateway. This endpoint is used for self-hosted models requests.%{br}The URL must be a complete URL, including either the \"http://\" or \"https://\" protocol. For example \"http://EXAMPLE-URL\".%{br}For more information, see how to %{linkStart}install the GitLab AI Gateway.%{linkEnd}"
|
||||
msgstr ""
|
||||
|
||||
msgid "AiPowered|Experiment and beta features"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -5360,6 +5363,9 @@ msgstr ""
|
|||
msgid "AiPowered|Indirect connections through GitLab self-managed instance"
|
||||
msgstr ""
|
||||
|
||||
msgid "AiPowered|Local AI Gateway URL"
|
||||
msgstr ""
|
||||
|
||||
msgid "AiPowered|Might result in requests having higher latency."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -6684,6 +6690,9 @@ msgstr ""
|
|||
msgid "An error occurred while updating your settings."
|
||||
msgstr ""
|
||||
|
||||
msgid "An error occurred while updating your settings. Reload the page to try again."
|
||||
msgstr ""
|
||||
|
||||
msgid "An error occurred while uploading the file. Please try again."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -37670,6 +37679,9 @@ msgstr ""
|
|||
msgid "New! Suggest changes directly"
|
||||
msgstr ""
|
||||
|
||||
msgid "New, streamlined merge request homepage!"
|
||||
msgstr ""
|
||||
|
||||
msgid "NewFramework|All todos done."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -53019,6 +53031,9 @@ msgstr ""
|
|||
msgid "See examples."
|
||||
msgstr ""
|
||||
|
||||
msgid "See how it works"
|
||||
msgstr ""
|
||||
|
||||
msgid "See our website for help"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -64338,6 +64353,9 @@ msgstr ""
|
|||
msgid "Welcome to GitLab,%{br_tag}%{name}!"
|
||||
msgstr ""
|
||||
|
||||
msgid "Welcome to the new merge request homepage! This page gives you a centralized view of all the merge requests you're working on. Know at a glance what merge requests need your attention first so you can spend less time checking in, and more time reviewing and responding to feedback."
|
||||
msgstr ""
|
||||
|
||||
msgid "Welcome, %{name}!"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -545,17 +545,18 @@ function log_disk_usage() {
|
|||
}
|
||||
|
||||
# all functions below are for customizing CI job exit code
|
||||
export TRACE_FILE=stdout_stderr_log.out
|
||||
|
||||
function run_with_custom_exit_code() {
|
||||
set +e # temprorarily disable exit on error to prevent premature exit
|
||||
|
||||
# runs command passed in as argument, save standard error and standard output
|
||||
output=$("$@" 2>&1)
|
||||
initial_exit_code=$?
|
||||
echo "$output" | tee "$TRACE_FILE"
|
||||
|
||||
find_custom_exit_code "$initial_exit_code"
|
||||
local trace_file="stdout_stderr_log.out"
|
||||
|
||||
echo "$output" | tee "$trace_file"
|
||||
|
||||
find_custom_exit_code "$initial_exit_code" "$trace_file"
|
||||
new_exit_code=$?
|
||||
|
||||
echo "new_exit_code=$new_exit_code"
|
||||
|
|
@ -566,33 +567,34 @@ function run_with_custom_exit_code() {
|
|||
|
||||
function find_custom_exit_code() {
|
||||
local exit_code="$1"
|
||||
local trace_file="$2"
|
||||
|
||||
# Early return if exit code is 0
|
||||
[ "$exit_code" -eq 0 ] && return 0
|
||||
|
||||
# Check if TRACE_FILE is set
|
||||
if [ -z "$TRACE_FILE" ] || [ ! -f "$TRACE_FILE" ]; then
|
||||
echoerr "TRACE_FILE is not set or file does not exist"
|
||||
# Check if trace_file is set
|
||||
if [ -z "$trace_file" ] || [ ! -f "$trace_file" ]; then
|
||||
echoerr "$trace_file is not set or file does not exist"
|
||||
exit "$exit_code"
|
||||
fi
|
||||
|
||||
if grep -i -q \
|
||||
-e "Failed to connect to 127.0.0.1" \
|
||||
-e "Failed to open TCP connection to" \
|
||||
-e "connection reset by peer" "$TRACE_FILE"; then
|
||||
-e "connection reset by peer" "$trace_file"; then
|
||||
|
||||
echoerr "Detected network connection error. Changing exit code to 110."
|
||||
exit_code=110
|
||||
alert_job_in_slack "$exit_code" "Network connection error"
|
||||
|
||||
elif grep -i -q -e "no space left on device" "$TRACE_FILE"; then
|
||||
elif grep -i -q -e "no space left on device" "$trace_file"; then
|
||||
echoerr "Detected no space left on device. Changing exit code to 111."
|
||||
exit_code=111
|
||||
alert_job_in_slack "$exit_code" "Low disk space"
|
||||
|
||||
elif grep -i -q \
|
||||
-e "error: downloading artifacts from coordinator" \
|
||||
-e "error: uploading artifacts as \"archive\" to coordinator" "$TRACE_FILE"; then
|
||||
-e "error: uploading artifacts as \"archive\" to coordinator" "$trace_file"; then
|
||||
echoerr "Detected artifact transit error. Changing exit code to 160."
|
||||
exit_code=160
|
||||
alert_job_in_slack "$exit_code" "Artifact transit error"
|
||||
|
|
@ -601,18 +603,18 @@ function find_custom_exit_code() {
|
|||
-e "500 Internal Server Error" \
|
||||
-e "Internal Server Error 500" \
|
||||
-e "502 Bad Gateway" \
|
||||
-e "503 Service Unavailable" "$TRACE_FILE"; then
|
||||
-e "503 Service Unavailable" "$trace_file"; then
|
||||
echoerr "Detected 5XX error. Changing exit code to 161."
|
||||
exit_code=161
|
||||
alert_job_in_slack "$exit_code" "5XX error"
|
||||
|
||||
elif grep -i -q -e "gitaly spawn failed" "$TRACE_FILE"; then
|
||||
elif grep -i -q -e "gitaly spawn failed" "$trace_file"; then
|
||||
echoerr "Detected gitaly spawn failure error. Changing exit code to 162."
|
||||
exit_code=162
|
||||
alert_job_in_slack "$exit_code" "Gitaly spawn failure"
|
||||
|
||||
elif grep -i -q -e \
|
||||
"Rspec suite is exceeding the 80 minute limit and is forced to exit with error" "$TRACE_FILE"; then
|
||||
"Rspec suite is exceeding the 80 minute limit and is forced to exit with error" "$trace_file"; then
|
||||
echoerr "Detected rspec timeout risk. Changing exit code to 163."
|
||||
exit_code=163
|
||||
alert_job_in_slack "$exit_code" "RSpec taking longer than 80 minutes and forced to fail."
|
||||
|
|
@ -620,23 +622,23 @@ function find_custom_exit_code() {
|
|||
elif grep -i -q \
|
||||
-e "Redis client could not fetch cluster information: Connection refused" \
|
||||
-e "Redis::Cluster::CommandErrorCollection" \
|
||||
-e "CLUSTERDOWN The cluster is down" "$TRACE_FILE"; then
|
||||
-e "CLUSTERDOWN The cluster is down" "$trace_file"; then
|
||||
echoerr "Detected Redis cluster error. Changing exit code to 164."
|
||||
exit_code=164
|
||||
alert_job_in_slack "$exit_code" "Redis cluster error"
|
||||
|
||||
elif grep -i -q -e "segmentation fault" "$TRACE_FILE"; then
|
||||
elif grep -i -q -e "segmentation fault" "$trace_file"; then
|
||||
echoerr "Detected segmentation fault. Changing exit code to 165."
|
||||
exit_code=165
|
||||
alert_job_in_slack "$exit_code" "Segmentation fault"
|
||||
|
||||
elif grep -i -q -e "Error: EEXIST: file already exists" "$TRACE_FILE"; then
|
||||
elif grep -i -q -e "Error: EEXIST: file already exists" "$trace_file"; then
|
||||
echoerr "Detected EEXIST error. Changing exit code to 166."
|
||||
exit_code=166
|
||||
alert_job_in_slack "$exit_code" "EEXIST: file already exists"
|
||||
|
||||
elif grep -i -q -e \
|
||||
"fatal: remote error: GitLab is currently unable to handle this request due to load" "$TRACE_FILE"; then
|
||||
"fatal: remote error: GitLab is currently unable to handle this request due to load" "$trace_file"; then
|
||||
echoerr "Detected GitLab overload error in job trace. Changing exit code to 167."
|
||||
exit_code=167
|
||||
alert_job_in_slack "$exit_code" "gitlab.com overload"
|
||||
|
|
@ -650,8 +652,8 @@ function find_custom_exit_code() {
|
|||
}
|
||||
|
||||
function alert_job_in_slack() {
|
||||
exit_code=$1
|
||||
alert_reason=$2
|
||||
local exit_code=$1
|
||||
local alert_reason=$2
|
||||
local slack_channel="#dx_development-analytics_alerts"
|
||||
|
||||
echoinfo "Reporting ${CI_JOB_URL} to Slack channel ${slack_channel}"
|
||||
|
|
|
|||
|
|
@ -82,6 +82,7 @@ describe('BoardContent', () => {
|
|||
isGroupBoard: true,
|
||||
disabled: false,
|
||||
fullPath: 'project-path',
|
||||
commentTemplatePaths: [],
|
||||
},
|
||||
stubs: {
|
||||
BoardContentSidebar: stubComponent(BoardContentSidebar, {
|
||||
|
|
|
|||
|
|
@ -141,6 +141,7 @@ describe('CE IssuesListApp component', () => {
|
|||
showNewIssueLink: true,
|
||||
signInPath: 'sign/in/path',
|
||||
groupId: '',
|
||||
commentTemplatePaths: [],
|
||||
};
|
||||
|
||||
let defaultQueryResponse = getIssuesQueryResponse;
|
||||
|
|
|
|||
Loading…
Reference in New Issue