Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
6d04658a73
commit
3984d44893
|
|
@ -50,9 +50,6 @@ export default {
|
|||
};
|
||||
},
|
||||
update: (data) => data.project?.mergeRequest?.userPermissions,
|
||||
skip() {
|
||||
return !this.drawerOpened;
|
||||
},
|
||||
},
|
||||
},
|
||||
components: {
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ export default {
|
|||
<component
|
||||
:is="showAsLink ? 'gl-link' : 'strong'"
|
||||
v-bind="linkHref"
|
||||
class="file-title-name js-blob-header-filepath gl-mr-1 gl-break-all gl-font-bold gl-text-strong"
|
||||
class="file-title-name js-blob-header-filepath gl-break-all gl-font-bold gl-text-strong"
|
||||
:class="{ '!gl-text-blue-700 hover:gl-cursor-pointer': showAsLink }"
|
||||
data-testid="file-title-content"
|
||||
>{{ fileName }}</component
|
||||
|
|
@ -78,11 +78,12 @@ export default {
|
|||
:text="blob.path"
|
||||
:gfm="gfmCopyText"
|
||||
:title="__('Copy file path')"
|
||||
size="small"
|
||||
category="tertiary"
|
||||
css-class="gl-mr-2"
|
||||
css-class="gl-ml-3"
|
||||
/>
|
||||
|
||||
<small v-if="showBlobSize" class="gl-mr-3 gl-text-subtle">{{ blobSize }}</small>
|
||||
<small v-if="showBlobSize" class="gl-mx-3 gl-text-subtle">{{ blobSize }}</small>
|
||||
|
||||
<gl-badge v-if="showLfsBadge">{{ __('LFS') }}</gl-badge>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -406,8 +406,21 @@ export default {
|
|||
selectedWorkItemType() {
|
||||
return this.workItemTypes?.find((item) => item.id === this.selectedWorkItemTypeId);
|
||||
},
|
||||
allowedParentTypesForSelectedType() {
|
||||
if (this.workItemTypes.length) {
|
||||
const widgetDefinitionsForCurrentType =
|
||||
this.workItemTypes.find((workItemType) => workItemType.id === this.selectedWorkItemTypeId)
|
||||
?.widgetDefinitions || [];
|
||||
|
||||
return (
|
||||
widgetDefinitionsForCurrentType.find((widget) => widget.type === WIDGET_TYPE_HIERARCHY)
|
||||
?.allowedParentTypes?.nodes || []
|
||||
);
|
||||
}
|
||||
return [];
|
||||
},
|
||||
selectedWorkItemTypeName() {
|
||||
return this.selectedWorkItemType?.name;
|
||||
return this.selectedWorkItemType?.name || '';
|
||||
},
|
||||
selectedWorkItemTypeIconName() {
|
||||
return this.selectedWorkItemType?.iconName;
|
||||
|
|
@ -1104,6 +1117,7 @@ export default {
|
|||
:full-path="selectedProjectFullPath"
|
||||
:parent="workItemParent"
|
||||
:is-group="isGroup"
|
||||
:allowed-parent-types-for-new-work-item="allowedParentTypesForSelectedType"
|
||||
@error="$emit('error', $event)"
|
||||
@parentMilestone="onParentMilestone"
|
||||
/>
|
||||
|
|
|
|||
|
|
@ -24,7 +24,6 @@ import {
|
|||
NAME_TO_ENUM_MAP,
|
||||
NAME_TO_TEXT_LOWERCASE_MAP,
|
||||
NO_WORK_ITEM_IID,
|
||||
WORK_ITEM_TYPE_ENUM_EPIC,
|
||||
WORK_ITEM_TYPE_NAME_EPIC,
|
||||
WORK_ITEM_TYPE_NAME_ISSUE,
|
||||
} from '../constants';
|
||||
|
|
@ -68,6 +67,11 @@ export default {
|
|||
required: false,
|
||||
default: '',
|
||||
},
|
||||
allowedParentTypesForNewWorkItem: {
|
||||
type: Array,
|
||||
required: false,
|
||||
default: () => [],
|
||||
},
|
||||
hasParent: {
|
||||
type: Boolean,
|
||||
required: false,
|
||||
|
|
@ -136,8 +140,8 @@ export default {
|
|||
isSearchingByReference() {
|
||||
return isReference(this.searchTerm) || isValidURL(this.searchTerm);
|
||||
},
|
||||
allowedParentTypesForNewWorkItem() {
|
||||
return this.workItemId === newWorkItemId(this.workItemType) ? [WORK_ITEM_TYPE_ENUM_EPIC] : [];
|
||||
allowedParentTypesForNewWorkItemEnums() {
|
||||
return this.allowedParentTypesForNewWorkItem.map((type) => NAME_TO_ENUM_MAP[type.name]) || [];
|
||||
},
|
||||
},
|
||||
watch: {
|
||||
|
|
@ -161,7 +165,7 @@ export default {
|
|||
return {
|
||||
fullPath: this.isIssue ? this.groupPath : this.fullPath,
|
||||
searchTerm: this.searchTerm,
|
||||
types: [...this.allowedParentTypes, ...this.allowedParentTypesForNewWorkItem],
|
||||
types: [...this.allowedParentTypes, ...this.allowedParentTypesForNewWorkItemEnums],
|
||||
in: this.searchTerm ? 'TITLE' : undefined,
|
||||
iid: null,
|
||||
isNumber: false,
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
.dropdown.gl-dropdown.gl-flex-1
|
||||
#js-check-out-modal{ data: how_merge_modal_data(@merge_request) }
|
||||
= render Pajamas::ButtonComponent.new(category: :primary, variant: :confirm, button_text_classes: 'gl-inline-flex gl-justify-between gl-w-full', button_options: { class: 'gl-flex gl-self-start gl-w-full sm:gl-w-auto !gl-pr-3', data: { toggle: 'dropdown', testid: 'mr-code-dropdown' } }) do
|
||||
= render Pajamas::ButtonComponent.new(button_text_classes: 'gl-inline-flex gl-justify-between gl-w-full', button_options: { class: 'gl-flex gl-self-start gl-w-full sm:gl-w-auto !gl-pr-3', data: { toggle: 'dropdown', testid: 'mr-code-dropdown' } }) do
|
||||
= _('Code')
|
||||
= sprite_icon "chevron-down", size: 16, css_class: "gl-icon gl-ml-2 !gl-mr-0"
|
||||
.dropdown-menu.dropdown-menu-right
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ For more examples of a question you can ask, see
|
|||
| Feature | Available on GitLab Duo Self-Hosted | GitLab version | Status |
|
||||
| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | ---------------------- | --- |
|
||||
| [GitLab Duo for the CLI](../../editor_extensions/gitlab_cli/_index.md#gitlab-duo-for-the-cli) | {{< icon name="check-circle-filled" >}} Yes | GitLab 18.1 and later | Beta |
|
||||
| [GitLab Duo Workflow](../../user/duo_workflow/_index.md) | {{< icon name="dash-circle" >}} No | GitLab 17.4 and later | Not applicable |
|
||||
| [GitLab Duo Agent Platform](../../user/duo_agent_platform/_index.md) | {{< icon name="dash-circle" >}} No | GitLab 17.4 and later | Not applicable |
|
||||
| [Vulnerability Resolution](../../user/application_security/vulnerabilities/_index.md#vulnerability-resolution) | {{< icon name="check-circle-filled" >}} Yes | GitLab 18.1 and later | Beta |
|
||||
| [AI Impact Dashboard](../../user/analytics/ai_impact_analytics.md) | {{< icon name="check-circle-filled" >}} Yes | GitLab 17.9 and later | Beta |
|
||||
|
||||
|
|
|
|||
|
|
@ -7956,6 +7956,36 @@ Input type: `MarkAsSpamSnippetInput`
|
|||
| <a id="mutationmarkasspamsnippeterrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during the mutation. |
|
||||
| <a id="mutationmarkasspamsnippetsnippet"></a>`snippet` | [`Snippet`](#snippet) | Snippet after mutation. |
|
||||
|
||||
### `Mutation.mavenUpstreamCreate`
|
||||
|
||||
{{< details >}}
|
||||
**Introduced** in GitLab 18.2.
|
||||
**Status**: Experiment.
|
||||
{{< /details >}}
|
||||
|
||||
Input type: `MavenUpstreamCreateInput`
|
||||
|
||||
#### Arguments
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="mutationmavenupstreamcreatecachevalidityhours"></a>`cacheValidityHours` | [`Int!`](#int) | Cache validity period. Defaults to 24 hours. |
|
||||
| <a id="mutationmavenupstreamcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
|
||||
| <a id="mutationmavenupstreamcreatedescription"></a>`description` | [`String`](#string) | Description of the upstream registry. |
|
||||
| <a id="mutationmavenupstreamcreateid"></a>`id` | [`VirtualRegistriesPackagesMavenRegistryID!`](#virtualregistriespackagesmavenregistryid) | ID of the upstream registry. |
|
||||
| <a id="mutationmavenupstreamcreatename"></a>`name` | [`String!`](#string) | Name of upstream registry. |
|
||||
| <a id="mutationmavenupstreamcreatepassword"></a>`password` | [`String`](#string) | Password of the upstream registry. |
|
||||
| <a id="mutationmavenupstreamcreateurl"></a>`url` | [`String!`](#string) | URL of the upstream registry. |
|
||||
| <a id="mutationmavenupstreamcreateusername"></a>`username` | [`String`](#string) | Username of the upstream registry. |
|
||||
|
||||
#### Fields
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="mutationmavenupstreamcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
|
||||
| <a id="mutationmavenupstreamcreateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during the mutation. |
|
||||
| <a id="mutationmavenupstreamcreateupstream"></a>`upstream` | [`MavenUpstream`](#mavenupstream) | Maven upstream after the mutation. |
|
||||
|
||||
### `Mutation.memberRoleAdminCreate`
|
||||
|
||||
{{< details >}}
|
||||
|
|
@ -48932,6 +48962,12 @@ A `UsersSavedReplyID` is a global ID. It is encoded as a string.
|
|||
|
||||
An example `UsersSavedReplyID` is: `"gid://gitlab/Users::SavedReply/1"`.
|
||||
|
||||
### `VirtualRegistriesPackagesMavenRegistryID`
|
||||
|
||||
A `VirtualRegistriesPackagesMavenRegistryID` is a global ID. It is encoded as a string.
|
||||
|
||||
An example `VirtualRegistriesPackagesMavenRegistryID` is: `"gid://gitlab/VirtualRegistries::Packages::Maven::Registry/1"`.
|
||||
|
||||
### `VulnerabilitiesExternalIssueLinkID`
|
||||
|
||||
A `VulnerabilitiesExternalIssueLinkID` is a global ID. It is encoded as a string.
|
||||
|
|
|
|||
|
|
@ -383,11 +383,9 @@ trigger-job:
|
|||
trigger-job:
|
||||
trigger:
|
||||
strategy: depend
|
||||
include:
|
||||
- project: project-group/my-downstream-project
|
||||
file: ".gitlab-ci.yml"
|
||||
inputs:
|
||||
job-name: "defined"
|
||||
project: project-group/my-downstream-project
|
||||
inputs:
|
||||
job-name: "defined"
|
||||
rules:
|
||||
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -270,7 +270,7 @@ The source attribute can have the following values:
|
|||
- `api`: Job initiated by a REST call to the Jobs API.
|
||||
- `chat`: Job initiated by a chat command using GitLab ChatOps.
|
||||
- `container_registry_push`: Job initiated by container registry push.
|
||||
- `duo_workflow`: Job initiated by GitLab Duo Workflow.
|
||||
- `duo_workflow`: Job initiated by GitLab Duo Agent Platform.
|
||||
- `external`: Job initiated by an event in an external repository integrated with GitLab. This does not include pull request events.
|
||||
- `external_pull_request_event`: Job initiated by a pull request event in an external repository.
|
||||
- `merge_request_event`: Job initiated by a merge request event.
|
||||
|
|
|
|||
|
|
@ -163,7 +163,7 @@ The following settings pages are available for configuring GitLab Duo on GitLab.
|
|||
##### Admin Level
|
||||
|
||||
- `/admin/gitlab_duo`
|
||||
- Onboard GitLab Duo Workflow
|
||||
- Onboard GitLab Duo Agent Platform
|
||||
|
||||
##### Top-Level Group Settings
|
||||
|
||||
|
|
|
|||
|
|
@ -1169,6 +1169,12 @@ the following are the names of GitLab Duo features:
|
|||
Excluding GitLab Duo Self-Hosted, after the first use, use the feature name
|
||||
without **GitLab Duo**.
|
||||
|
||||
## GitLab Duo Agent Platform
|
||||
|
||||
Use **GitLab Duo Agent Platform**. After first use, use **Agent Platform**.
|
||||
|
||||
Do not use **Duo Agent Platform** by itself.
|
||||
|
||||
## GitLab Duo Enterprise
|
||||
|
||||
Always use **GitLab Duo Enterprise** for the add-on. Do not use **Duo Enterprise** unless approved by legal.
|
||||
|
|
@ -1191,12 +1197,6 @@ and in title case, unless you are
|
|||
|
||||
Do not use **Self-Hosted** by itself.
|
||||
|
||||
## GitLab Duo Workflow
|
||||
|
||||
Use **GitLab Duo Workflow**. After first use, use **Workflow**.
|
||||
|
||||
Do not use **Duo Workflow** by itself.
|
||||
|
||||
## GitLab Flavored Markdown
|
||||
|
||||
When possible, spell out [**GitLab Flavored Markdown**](../../../user/markdown.md).
|
||||
|
|
|
|||
|
|
@ -2,10 +2,16 @@
|
|||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/development/development_processes/#development-guidelines-review.
|
||||
title: Development of GitLab Duo Workflow
|
||||
title: Development of GitLab Duo Agent Platform
|
||||
---
|
||||
|
||||
How to set up the local development environment to run [GitLab Duo Workflow](../../user/duo_workflow/_index.md).
|
||||
{{< history >}}
|
||||
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
How to set up the local development environment to run [GitLab Duo Agent Platform](../../user/duo_agent_platform/_index.md).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
@ -25,18 +31,18 @@ Workflow consists of four separate services:
|
|||
|
||||
### Development Setup for Backend Components
|
||||
|
||||
You should [set up GitLab Duo Workflow with the GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/duo_workflow.md)
|
||||
You should [set up GitLab Duo Agent Platform with the GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/duo_workflow.md)
|
||||
to run local versions of GitLab, Duo Workflow Service, and Executor.
|
||||
|
||||
This setup can be used as-is with the [publicly available version of the VS Code Extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow).
|
||||
|
||||
### Development Setup for Frontend Components
|
||||
|
||||
There is no need to set up the backend components of Duo Workflow to test changes for the GitLab Duo Workflow UI.
|
||||
There is no need to set up the backend components of the Agent Platform to test changes for the Agent Platform UI in the IDE.
|
||||
|
||||
A local build of the UI is required if you are making Duo Workflow UI changes that you need to view locally. A local build is also required if you want to use a version of the UI that has not been released yet.
|
||||
|
||||
Refer to the [GitLab Duo Workflow README](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/blob/main/packages/webview_duo_workflow/README.md) file in the Language Server project to get started with local development of GitLab Duo Workflow UI.
|
||||
Refer to the [GitLab Duo Workflow README](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/blob/main/packages/webview_duo_workflow/README.md) file in the Language Server project to get started with local development of GitLab Duo Agent Platform UI in the IDE.
|
||||
|
||||
## Development settings
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +1,26 @@
|
|||
---
|
||||
title: Create triage policies with the assistance of GitLab Duo Workflow
|
||||
title: Create triage policies with the assistance of GitLab Duo Agent Platform
|
||||
---
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
## Summary
|
||||
|
||||
This guide provides comprehensive instructions for writing triage automation policies in [triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) using GitLab Duo Workflow. You will be able to self service label migrations after a department re-org by following this page.
|
||||
This guide provides comprehensive instructions for writing triage automation policies in [triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) using GitLab Duo Agent Platform. You will be able to self service label migrations after a department re-org by following this page.
|
||||
|
||||
Todo: include instructions for writing policies to perform other types of automated tasks.
|
||||
|
||||
## Purpose
|
||||
|
||||
Triage policies are used when team members migrate labels across existing issues, merge requests, and epics using [GitLab-triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage). This tool automates triaging through [policies defined in YAML](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#what-is-a-triage-policy). To optimize operational efficiency and ensure seamless implementation, we recommend self-servicing the label migration MRs using [GitLab Duo Workflow](../../user/duo_workflow/_index.md).
|
||||
Triage policies are used when team members migrate labels across existing issues, merge requests, and epics using [GitLab-triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage). This tool automates triaging through [policies defined in YAML](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#what-is-a-triage-policy). To optimize operational efficiency and ensure seamless implementation, we recommend self-servicing the label migration MRs using [GitLab Duo Agent Platform](../../user/duo_agent_platform/_index.md).
|
||||
|
||||
## Before you start
|
||||
|
||||
Follow the [GitLab Duo Workflow documentation](../../user/duo_workflow/_index.md) to learn how to set up and access GitLab Duo Workflow in your code editor.
|
||||
Follow the [GitLab Duo Agent Platform documentation](../../user/duo_agent_platform/_index.md) to learn how to set up and access GitLab Duo Agent Platform in your code editor.
|
||||
|
||||
## Build your prompt
|
||||
|
||||
|
|
@ -56,7 +62,7 @@ Note: the gem only performs [these actions](https://gitlab.com/gitlab-org/ruby/g
|
|||
|
||||
### Reference material
|
||||
|
||||
GitLab Duo Workflow requires reference materials, preferably with examples, to write these files.
|
||||
GitLab Duo Agent Platform requires reference materials, preferably with examples, to write these files.
|
||||
|
||||
Example prompt snippet: `Read instructions and example yml files in policies/one-off/duo-workflow-guide-and-example-policies to ensure the result has the correct syntax.`
|
||||
|
||||
|
|
@ -74,7 +80,7 @@ Example prompt:
|
|||
|
||||
> Update the policy you created in `policies/one-off/auth-migration.yml` by adding a new condition to skip resources currently labeled with ~"workflow::completed" using the forbidden_labels field
|
||||
|
||||
### Resulting policy written by GitLab Duo Workflow
|
||||
### Resulting policy written by GitLab Duo Agent Platform
|
||||
|
||||
The 2 prompts above generated the following policy:
|
||||
|
||||
|
|
|
|||
|
|
@ -150,6 +150,26 @@ If you encounter timeout errors, use:
|
|||
COMPOSE_HTTP_TIMEOUT=300 docker-compose up -d
|
||||
```
|
||||
|
||||
### Optional: Use an external ClickHouse database
|
||||
|
||||
If you'd prefer, you can use your own ClickHouse database.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Ensure your external ClickHouse instance is accessible and properly configured with
|
||||
any required authentication credentials.
|
||||
|
||||
Before you run `docker-compose up -d`, complete the following steps:
|
||||
|
||||
1. Open `docker-compose.yml` file.
|
||||
1. Open `docker-compose.yml` and comment out:
|
||||
- The `clickhouse` and `zookeeper` services.
|
||||
- The `x-clickhouse-defaults` and `x-clickhouse-depend` sections.
|
||||
1. Replace all occurrences of `clickhouse:9000` with your relevant ClickHouse endpoint and TCP port (for example, `my-clickhouse.example.com:9000`) in the following files. If your ClickHouse instance requires authentication, you may also need to update connection strings to include credentials:
|
||||
- `docker-compose.yml`
|
||||
- `otel-collector-config.yaml`
|
||||
- `prometheus-config.yml`
|
||||
|
||||
### Configure network access for GitLab Observability
|
||||
|
||||
To properly receive telemetry data, you need to open specific ports in your GitLab O11y instance's security group:
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ even if the vulnerability already exists on the default branch.
|
|||
|
||||
For more information, see:
|
||||
|
||||
- [Enable Secret Detection](secret_detection/pipeline/_index.md#enable-the-analyzer)
|
||||
- [Enable Secret Detection](secret_detection/pipeline/_index.md#getting-started)
|
||||
- [Secret Detection settings](secret_detection/pipeline/configure.md)
|
||||
- [Enable Dependency Scanning](dependency_scanning/_index.md#getting-started)
|
||||
- [Dependency Scanning settings](dependency_scanning/_index.md#available-cicd-variables)
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ title: Pipeline secret detection
|
|||
|
||||
Pipeline secret detection scans files after they are committed to a Git repository and pushed to GitLab.
|
||||
|
||||
After you [enable pipeline secret detection](#enable-the-analyzer), scans run in a CI/CD job named `secret_detection`.
|
||||
After you [enable pipeline secret detection](#getting-started), scans run in a CI/CD job named `secret_detection`.
|
||||
You can run scans and view [pipeline secret detection JSON report artifacts](../../../../ci/yaml/artifacts_reports.md#artifactsreportssecret_detection) in any GitLab tier.
|
||||
|
||||
With GitLab Ultimate, pipeline secret detection results are also processed so you can:
|
||||
|
|
@ -49,27 +49,9 @@ Different features are available in different [GitLab tiers](https://about.gitla
|
|||
| [Customize analyzer rulesets](configure.md#customize-analyzer-rulesets) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
|
||||
| [Enable security policies](../../policies/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
|
||||
|
||||
## Getting Started
|
||||
## Getting started
|
||||
|
||||
You can implement pipeline secret detection incrementally.
|
||||
Start with a small-scale pilot to understand the tool's behavior before rolling out the feature across your organization.
|
||||
|
||||
Follow these guidelines when you implement pipeline secret detection:
|
||||
|
||||
1. Choose a pilot project. Suitable projects have:
|
||||
- Active development with regular commits.
|
||||
- A manageable codebase size.
|
||||
- A team familiar with GitLab CI/CD.
|
||||
- Willingness to iterate on configuration.
|
||||
1. Start simple. Enable pipeline secret detection with default settings on your pilot project.
|
||||
1. Monitor results. Run the analyzer for one or two weeks to understand typical findings.
|
||||
1. Address detected secrets. Remediate any legitimate secrets found.
|
||||
1. Tune your configuration. Adjust settings based on initial results.
|
||||
1. Document the implementation. Record common false positives and remediation patterns.
|
||||
|
||||
## Enable the Analyzer
|
||||
|
||||
Enable the analyzer to use pipeline secret detection.
|
||||
To get started with pipeline secret detection, select a pilot project and enable the analyzer.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
|
|
@ -311,6 +293,24 @@ Before applying optimizations organization-wide:
|
|||
1. Track false positive reduction and scan performance improvements.
|
||||
1. Maintain records of effective optimization patterns.
|
||||
|
||||
## Roll out
|
||||
|
||||
You should implement pipeline secret detection incrementally.
|
||||
Start with a small-scale pilot to understand the tool's behavior before rolling out the feature across your organization.
|
||||
|
||||
Follow these guidelines when you roll out pipeline secret detection:
|
||||
|
||||
1. Choose a pilot project. Suitable projects have:
|
||||
- Active development with regular commits.
|
||||
- A manageable codebase size.
|
||||
- A team familiar with GitLab CI/CD.
|
||||
- Willingness to iterate on configuration.
|
||||
1. Start simple. Enable pipeline secret detection with default settings on your pilot project.
|
||||
1. Monitor results. Run the analyzer for one or two weeks to understand typical findings.
|
||||
1. Address detected secrets. Remediate any legitimate secrets found.
|
||||
1. Tune your configuration. Adjust settings based on initial results.
|
||||
1. Document the implementation. Record common false positives and remediation patterns.
|
||||
|
||||
## FIPS-enabled images
|
||||
|
||||
{{< history >}}
|
||||
|
|
@ -393,7 +393,7 @@ the `secret-detection` job on.
|
|||
|
||||
#### `exec /bin/sh: exec format error` message in job log
|
||||
|
||||
The GitLab pipeline secret detection analyzer [only supports](#enable-the-analyzer) running on the `amd64` CPU architecture.
|
||||
The GitLab pipeline secret detection analyzer [only supports](#getting-started) running on the `amd64` CPU architecture.
|
||||
This message indicates that the job is being run on a different architecture, such as `arm`.
|
||||
|
||||
#### Error: `fatal: detected dubious ownership in repository at '/builds/<project dir>'`
|
||||
|
|
|
|||
|
|
@ -0,0 +1,192 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: GitLab Duo Agent Platform
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
- LLM: Anthropic [Claude Sonnet 4](https://www.anthropic.com/claude/sonnet)
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/14153) in GitLab 17.4 [with a flag](../../administration/feature_flags/_index.md) named `duo_workflow`. Enabled for GitLab team members only. This feature is a [private beta](../../policy/development_stages_support.md).
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="flag" >}}
|
||||
|
||||
The availability of this feature is controlled by a feature flag.
|
||||
For more information, see the history.
|
||||
This feature is available for internal GitLab team members for testing, but not ready for production use.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="disclaimer" />}}
|
||||
|
||||
With the GitLab Duo Agent Platform, multiple AI agents can work in parallel, helping you create code,
|
||||
research results, and perform tasks simultaneously.
|
||||
The agents have full context across your entire software development lifecycle.
|
||||
For more details, [view this blog post](https://about.gitlab.com/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/).
|
||||
|
||||
The GitLab Duo Agent Platform is currently available in the VS Code IDE.
|
||||
|
||||
- It runs in your IDE so that you do not have to switch contexts or tools.
|
||||
- It creates and works through a plan, in response to your prompt.
|
||||
- It stages proposed changes in your project's repository.
|
||||
You control when to accept, modify, or reject the suggestions.
|
||||
- Understands the context of your project structure, codebase, and history.
|
||||
You can also add your own context, such as relevant GitLab issues or merge requests.
|
||||
|
||||
For a click-through demo, see [GitLab Duo Agent Platform](https://gitlab.navattic.com/duo-workflow).
|
||||
<!-- Demo published on 2025-03-18 -->
|
||||
|
||||
For an overview, watch <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Enhancing your quality assurance with GitLab Duo Agent Platform](https://youtu.be/Tuj7TgqY81Q?si=IbxaKv7IhAHYnHkN). <!-- Video published on 2025-03-20-->
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you can use the Agent Platform in VS Code, you must:
|
||||
|
||||
- [Install Visual Studio Code](https://code.visualstudio.com/download) (VS Code).
|
||||
- [Set up the GitLab Workflow extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow#setup). Minimum version 5.16.0.
|
||||
- Have an account on GitLab.com.
|
||||
- Have a project that meets the following requirements:
|
||||
- The project is on GitLab.com.
|
||||
- You have at least the Developer role.
|
||||
- The project belongs to a [group namespace](../namespace/_index.md) with an Ultimate subscription.
|
||||
- [Beta and experimental features must be turned on](../gitlab_duo/turn_on_off.md#turn-on-beta-and-experimental-features).
|
||||
- [GitLab Duo must be turned on](../gitlab_duo/turn_on_off.md).
|
||||
- [Successfully connect to your repository](#connect-to-your-repository).
|
||||
- [Ensure an HTTP/2 connection to the backend service is possible](troubleshooting.md#network-issues).
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Though not recommended, you can [set up the Agent Platform in a Docker container](docker_set_up.md).
|
||||
You do not need to use Docker to run the Agent Platform.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Connect to your repository
|
||||
|
||||
To use the Agent Platform in VS Code, ensure your repository is properly connected.
|
||||
|
||||
1. In VS Code, on the top menu, select **Terminal > New Terminal**.
|
||||
1. Clone your repository: `git clone <repository>`.
|
||||
1. Change to the directory where your repository was cloned and check out your branch: `git checkout <branch_name>`.
|
||||
1. Ensure your project is selected:
|
||||
1. On the left sidebar, select **GitLab Workflow** ({{< icon name="tanuki" >}}).
|
||||
1. Select the project name. If you have multiple projects, select the one you want to work with.
|
||||
1. In the terminal, ensure your repository is configured with a remote: `git remote -v`. The results should look similar to:
|
||||
|
||||
```plaintext
|
||||
origin git@gitlab.com:gitlab-org/gitlab.git (fetch)
|
||||
origin git@gitlab.com:gitlab-org/gitlab.git (push)
|
||||
```
|
||||
|
||||
If no remote is defined, or you have multiple remotes:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. On the **Source Control** label, right-click and select **Repositories**.
|
||||
1. Next to your repository, select the ellipsis ({{< icon name=ellipsis_h >}}), then **Remote > Add Remote**.
|
||||
1. Select **Add remote from GitLab**.
|
||||
1. Choose a remote.
|
||||
|
||||
Now you can use the Agent Platform to help solve your coding tasks.
|
||||
|
||||
## Use the Agent Platform in VS Code
|
||||
|
||||
The software development flow is one of many possible flows in the GitLab Duo Agent Platform.
|
||||
|
||||
To use the software development flow:
|
||||
|
||||
1. On the left sidebar, select **GitLab Duo Workflow** ({{< icon name="pencil" >}}).
|
||||
1. In the text box, specify a code task in detail.
|
||||
- For assistance writing your prompt, see [use case examples](use_cases.md) and [best practices](best_practices.md).
|
||||
- The Agent Platform is aware of all files available to Git in the project branch.
|
||||
- You can also give the Agent Platform [additional context](#the-context-the-agent-platform-is-aware-of).
|
||||
- The Agent Platform cannot access external sources or the web.
|
||||
1. Select **Start**.
|
||||
|
||||
After you describe your task, a plan is generated and executed.
|
||||
You can pause or ask it to adjust the plan.
|
||||
|
||||
For more information about how to interact with the Agent Platform, see [best practices](best_practices.md).
|
||||
|
||||
## The context the Agent Platform is aware of
|
||||
|
||||
When you ask for help with a task in the Agent Platform, it will refer to files available to Git in the current branch of the project in your VS Code workspace.
|
||||
|
||||
You can ask about other projects, but they must meet the [prerequisites](#prerequisites).
|
||||
|
||||
You can also provide it with additional context.
|
||||
|
||||
| Area | Enter | Examples |
|
||||
|-------------------------|------------------------|----------|
|
||||
| Local files | The file with path. |• Summarize the file `src/main.js`<br>• Review the code in `app/models/`<br>• List all JavaScript files in the project |
|
||||
| Epics | Either:<br>• The URL of the group or epic. <br>• The epic ID and the name of the group the epic is in. | Examples:<br>• List all epics in `https://gitlab.com/groups/namespace/group`<br>• Summarize the epic: `https://gitlab.com/groups/namespace/group/-/epics/42`<br>• `Summarize epic 42 in group namespace/group` |
|
||||
| Issues | Either:<br>• The URL of the project or issue. <br>• The issue ID in the current or another project. | Examples:<br>• List all issues in the project at `https://gitlab.com/namespace/project`<br>• Summarize the issue at `https://gitlab.com/namespace/project/-/issues/103`<br>• Review the comment with ID `42` in `https://gitlab.com/namespace/project/-/issues/103`<br>• List all comments on the issue at `https://gitlab.com/namespace/project/-/issues/103`<br>• Summarize issue `103` in this project |
|
||||
| Merge requests | Either:<br>• The URL of the merge request. <br>• The merge request ID in the current or another project. |• Summarize `https://gitlab.com/namespace/project/-/merge_requests/103`<br>• Review the diffs in `https://gitlab.com/namespace/project/-/merge_requests/103`<br>• Summarize the comments on `https://gitlab.com/namespace/project/-/merge_requests/103`<br>• Summarize merge request `103` in this project |
|
||||
| Merge request pipelines | The merge request ID in the current or another project. |• Review the failures in merge request `12345`<br>• Can you identify the cause of the error in the merge request `54321` in project `gitlab-org/gitlab-qa` <br>• Suggest a solution to the pipeline failure in `https://gitlab.com/namespace/project/-/merge_requests/54321` |
|
||||
|
||||
The Agent Platform also has access to the GitLab [Search API](../../api/search.md) to find related issues or merge requests.
|
||||
|
||||
## Supported languages
|
||||
|
||||
The Agent Platform officially supports the following languages:
|
||||
|
||||
- CSS
|
||||
- Go
|
||||
- HTML
|
||||
- Java
|
||||
- JavaScript
|
||||
- Markdown
|
||||
- Python
|
||||
- Ruby
|
||||
- TypeScript
|
||||
|
||||
## APIs that the Agent Platform has access to
|
||||
|
||||
To create solutions and understand the context of the problem,
|
||||
the Agent Platform accesses several GitLab APIs.
|
||||
|
||||
Specifically, an OAuth token with the `ai_workflows` scope has access
|
||||
to the following APIs:
|
||||
|
||||
- [Projects API](../../api/projects.md)
|
||||
- [Search API](../../api/search.md)
|
||||
- [CI Pipelines API](../../api/pipelines.md)
|
||||
- [CI Jobs API](../../api/jobs.md)
|
||||
- [Merge Requests API](../../api/merge_requests.md)
|
||||
- [Epics API](../../api/epics.md)
|
||||
- [Issues API](../../api/issues.md)
|
||||
- [Notes API](../../api/notes.md)
|
||||
- [Usage Data API](../../api/usage_data.md)
|
||||
|
||||
## Audit log
|
||||
|
||||
An audit event is created for each API request done by the Agent Platform.
|
||||
On your GitLab Self-Managed instance, you can view these events on the
|
||||
[instance audit events](../../administration/compliance/audit_event_reports.md#instance-audit-events) page.
|
||||
|
||||
## Give feedback
|
||||
|
||||
The Agent Platform is a private beta and your feedback is crucial to improve it for you and others.
|
||||
To report issues or suggest improvements,
|
||||
[complete this survey](https://gitlab.fra1.qualtrics.com/jfe/form/SV_9GmCPTV7oH9KNuu).
|
||||
|
||||
## Related topics
|
||||
|
||||
- [Use GitLab Duo Agent Platform to improve application quality assurance](https://about.gitlab.com/blog/2025/04/10/use-gitlab-duo-workflow-to-improve-application-quality-assurance/)
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Best practices for GitLab Duo Agent Platform
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
When you use the GitLab Duo Agent Platform in the IDE, follow these best practices to get the most value from the software development flow.
|
||||
|
||||
## Create focused prompts
|
||||
|
||||
A prompt is the text input that you give to the Agent Platform. To create an effective prompt:
|
||||
|
||||
- Define a clear goal with measurable outcomes.
|
||||
- Provide clear context by including relevant files, merge requests, or issues.
|
||||
For information about the types of context the Agent Platform understands, see
|
||||
[context](_index.md#the-context-the-agent-platform-is-aware-of).
|
||||
- Provide examples of expected changes.
|
||||
- Include or link to any technical requirements or rules.
|
||||
|
||||
Example prompt:
|
||||
|
||||
```plaintext
|
||||
Scan all Vue.js components in the 'src/components' directory. Add appropriate ARIA attributes
|
||||
to improve accessibility. Focus on buttons, forms, and navigation elements.
|
||||
Ensure changes maintain existing functionality.
|
||||
```
|
||||
|
||||
## Review the plan
|
||||
|
||||
After you enter your prompt, the Agent Platform generates a plan containing tasks. You can pause and restart while it creates and works through its plan.
|
||||
|
||||
During this process:
|
||||
|
||||
- Confirm all target files are correctly identified.
|
||||
- Verify proposed changes align with requirements.
|
||||
- Check for any missing dependencies or integration points.
|
||||
- Pause the workflow and adjust if needed.
|
||||
|
||||
## Check proposed changes
|
||||
|
||||
As the Agent Platform works through its plan, it stages corresponding changes to the files in your project. The changes might include new or modified files.
|
||||
|
||||
Before committing the changes:
|
||||
|
||||
1. Check that the Agent Platform:
|
||||
|
||||
- Targeted the correct files.
|
||||
- Made appropriate changes.
|
||||
- Followed the requirements and rules from your prompt.
|
||||
|
||||
1. Look for patterns in what it's missing or misinterpreting. Use that data to refine your prompt. Common errors include:
|
||||
|
||||
- The incorrect solution. We are continuing to work on the accuracy of overall generated content. However, suggestions might be:
|
||||
- Irrelevant.
|
||||
- Incomplete.
|
||||
- Results in failed pipelines.
|
||||
- Potentially insecure.
|
||||
- Offensive or insensitive.
|
||||
- Adds code in the wrong location.
|
||||
- Includes code changes that can't be used by other parts of the system.
|
||||
|
||||
## Iterate and improve
|
||||
|
||||
When the Agent Platform does not produce the expected results:
|
||||
|
||||
- Document the specific areas that need improvement.
|
||||
- Break complex goals into smaller workflows.
|
||||
- Add examples of correct and incorrect implementations.
|
||||
- Refine prompts to address gaps.
|
||||
|
||||
For example, refine your prompts from the general to the specific:
|
||||
|
||||
General:
|
||||
|
||||
```plaintext
|
||||
Add ARIA attributes to improve accessibility.
|
||||
```
|
||||
|
||||
Specific:
|
||||
|
||||
```plaintext
|
||||
Add aria-label attributes to buttons without text content.
|
||||
Use the button's function for the label value.
|
||||
Required format: aria-label="Action description"
|
||||
```
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Set up Docker for GitLab Duo Agent Platform (optional)
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Use the following guide to set up GitLab Duo Agent Platform locally with Docker.
|
||||
|
||||
This is not the preferred method to run the Agent Platform.
|
||||
If you have VS Code and at least version 5.16.0 of the GitLab Workflow extension for VS Code,
|
||||
you can use the Agent Platform. For more information, see [the prerequisites](_index.md#prerequisites).
|
||||
|
||||
## Install Docker and set the socket file path
|
||||
|
||||
The Agent Platform needs an execution platform like Docker where it can execute arbitrary code,
|
||||
read and write files, and make API calls to GitLab.
|
||||
|
||||
If you are on macOS or Linux, you can either:
|
||||
|
||||
- Use the [automated setup script](#automated-setup). Recommended.
|
||||
- Follow the [manual setup](#manual-setup).
|
||||
|
||||
If you are not on macOS or Linux, follow the [manual setup](#manual-setup).
|
||||
|
||||
### Automated setup
|
||||
|
||||
The automated setup script:
|
||||
|
||||
- Installs [Docker](https://formulae.brew.sh/formula/docker) and [Colima](https://github.com/abiosoft/colima).
|
||||
- Sets Docker socket path in VS Code settings.
|
||||
|
||||
You can run the script with the `--dry-run` flag to check the dependencies
|
||||
that get installed with the script.
|
||||
|
||||
1. Download the [setup script](https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-executor/-/blob/main/scripts/install-runtime).
|
||||
|
||||
```shell
|
||||
wget https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-executor/-/raw/main/scripts/install-runtime
|
||||
```
|
||||
|
||||
1. Run the script.
|
||||
|
||||
```shell
|
||||
chmod +x install-runtime
|
||||
./install-runtime
|
||||
```
|
||||
|
||||
### Manual setup
|
||||
|
||||
1. Install a Docker container engine, such as [Rancher Desktop](https://docs.rancherdesktop.io/getting-started/installation/).
|
||||
1. Set the Docker socket path and Docker settings in VS Code:
|
||||
1. Open VS Code, then open the [Command Palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette):
|
||||
- On macOS: <kbd>Cmd</kbd> + <kbd>,</kbd>
|
||||
- On Windows and Linux: <kbd>Ctrl</kbd> + <kbd>,</kbd>
|
||||
1. In the open Command Palette search for `settings.json`.
|
||||
1. Add a line to `settings.json` that defines the Docker socket path setting `gitlab.duoWorkflow.dockerSocket`,
|
||||
according to your container manager, and save your settings file. Some examples for common container
|
||||
managers on macOS, where you would replace `<your_user>` with your user's home folder:
|
||||
|
||||
- Rancher Desktop:
|
||||
|
||||
```json
|
||||
"gitlab.duoWorkflow.dockerSocket": "/Users/<your_user>/.rd/docker.sock",
|
||||
"gitlab.duoWorkflow.useDocker": true,
|
||||
```
|
||||
|
||||
- Colima:
|
||||
|
||||
```json
|
||||
"gitlab.duoWorkflow.dockerSocket": "/Users/<your_user>/.colima/default/docker.sock",
|
||||
"gitlab.duoWorkflow.useDocker": true,
|
||||
```
|
||||
|
|
@ -0,0 +1,83 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Risks in GitLab Duo Agent Platform
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
The Agent Platform is a beta product and users should consider their
|
||||
circumstances before using this tool. It is subject to [the GitLab Testing Agreement](https://handbook.gitlab.com/handbook/legal/testing-agreement/).
|
||||
The Agent Platform is an AI Agent that is given some ability to perform actions on the user's behalf. AI tools based on LLMs are
|
||||
inherently unpredictable and you should take appropriate precautions.
|
||||
|
||||
The Agent Platform in VS Code runs workflows on your local workstation or in a Docker container.
|
||||
Running inside of a Docker container is not a security measure but a
|
||||
convenience to reduce the amount of disruption to your usual development
|
||||
environment. All the documented risks should be considered before using this
|
||||
product. The following risks are important to understand:
|
||||
|
||||
1. The Agent Platform has access to the local file system of the
|
||||
project where you started running it. The Agent Platform respects your local `.gitignore` file,
|
||||
but it can still access files that are not committed to the project and not called out in `.gitignore`.
|
||||
Such files can contain credentials (for example, `.env` files).
|
||||
1. The Agent Platform also gets access to a time-limited `ai_workflows` scoped GitLab
|
||||
OAuth token with your user's identity. This token can be used to access
|
||||
GitLab APIs on your behalf. This token is limited to the duration of
|
||||
the workflow and only has access to certain APIs in GitLab.
|
||||
Without user approval, the Agent Platform will only perform read operations but the token can still,
|
||||
by design, perform write operations on the users behalf. You should consider
|
||||
the access your user has in GitLab before running the Agent Platform.
|
||||
1. You should not give the Agent Platform any additional credentials or secrets, in
|
||||
goals or messages, as there is a chance it might end up using those in code
|
||||
or other API calls.
|
||||
|
||||
Risks specifically when using Docker to isolate the Agent Platform:
|
||||
|
||||
1. Our supported Docker servers are running in a VM. We do not support Docker
|
||||
Engine running on the host as this offers less isolation. Because Docker
|
||||
Engine is the most common way to run Docker on Linux we will likely not
|
||||
support many Linux setups by default, but instead we'll require them to
|
||||
install an additional Docker runtime to use the Agent Platform.
|
||||
1. This VM running on your local workstation likely has access to your local
|
||||
network, unless you have created additional firewall rules to prevent it.
|
||||
Local network access may be an issue if you are running local development
|
||||
servers on your host that you would not want reachable by the workflow
|
||||
commands. Local network access may also be risky in a corporate intranet
|
||||
environment where you have internal resources that you do not want
|
||||
accessible by the Agent Platform.
|
||||
1. The VM may be able to consume a lot of CPU, RAM and storage based on the
|
||||
limits configured with your Docker VM installation.
|
||||
1. Depending on the configuration of the VM in your Docker installation it may
|
||||
also have access to other hardware on your host.
|
||||
1. Unpatched installations of Docker may contain vulnerabilities that could
|
||||
eventually lead to code execution escaping the VM to the host or accessing
|
||||
resources on the host that you didn't intend.
|
||||
1. Each version of Docker has different ways of mounting directories into the
|
||||
containers. The Agent Platform only mounts the directory for the project you have
|
||||
open in VS Code but depending on how your Docker installation works and
|
||||
whether or not you are running other containers there may still be some
|
||||
risks it could access other parts of your file system.
|
||||
1. All your Docker containers usually run in a single VM. So this
|
||||
may mean that the containers are running in the same VM as other
|
||||
non-Agent Platform containers. While the containers are isolated to some
|
||||
degree this isolation is not as strict as VM level isolation.
|
||||
|
|
@ -0,0 +1,160 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Troubleshooting GitLab Duo Agent Platform
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## General guidance
|
||||
|
||||
If you encounter issues, ensure that you have:
|
||||
|
||||
1. The latest version of the GitLab Workflow extension for VS Code.
|
||||
1. A project that meets the [prerequisites](_index.md#prerequisites).
|
||||
1. The repository open in VS Code.
|
||||
1. The branch checked out.
|
||||
|
||||
For details on these steps, see [the prerequisites](_index.md#prerequisites) and
|
||||
[how to connect to your repository](_index.md#connect-to-your-repository).
|
||||
|
||||
## View debugging logs
|
||||
|
||||
You can troubleshoot some issues by viewing debugging logs.
|
||||
|
||||
1. Open local debugging logs:
|
||||
- On macOS: <kbd>Cmd</kbd> + <kbd>,</kbd>
|
||||
- On Windows and Linux: <kbd>Ctrl</kbd> + <kbd>,</kbd>
|
||||
1. Search for the setting **GitLab: Debug** and enable it.
|
||||
1. Open the language server logs:
|
||||
1. In VS Code, select **View** > **Output**.
|
||||
1. In the output panel at the bottom, in the upper-right corner,
|
||||
select **GitLab Workflow** or **GitLab Language Server** from the list.
|
||||
1. Review for errors, warnings, connection issues, or authentication problems.
|
||||
|
||||
## Network issues
|
||||
|
||||
Your network might block the connection to the Agent Platform service,
|
||||
for example, by using a firewall. The network must let HTTP/2 traffic through to the service.
|
||||
|
||||
To confirm that you can connect to the Agent Platform service:
|
||||
|
||||
1. In Google Chrome or Firefox, open Developer Tools and select the **Network** tab.
|
||||
1. Right-click the column headers to show the **Protocol** column.
|
||||
1. In the address bar, enter `https://duo-workflow-svc.runway.gitlab.net/DuoWorkflow/ExecuteWorkflow`.
|
||||
1. Ensure the request was successful and the **Protocol** column includes `h2` in Chrome or `HTTP/2` in Firefox.
|
||||
|
||||
If the request fails or does not show the HTTP/2 protocol:
|
||||
|
||||
- A security system like Netskope or Zscaler might be configured to block or inspect traffic.
|
||||
- The HTTP/2 protocol downgrades to HTTP/1.1, which prevents the Agent Platform from working correctly.
|
||||
|
||||
To correct this issue, ask your network administrator to put `https://duo-workflow-svc.runway.gitlab.net/DuoWorkflow/ExecuteWorkflow`
|
||||
on the correct allowlist, or to exempt it from traffic inspection.
|
||||
|
||||
## Docker setup
|
||||
|
||||
If you encounter issues with your Docker setup, try the following steps.
|
||||
|
||||
1. [Install Docker and set the socket file path](docker_set_up.md#install-docker-and-set-the-socket-file-path).
|
||||
1. Restart your container manager. For example, if you use Colima, `colima restart`.
|
||||
1. Pull the base Docker image:
|
||||
|
||||
```shell
|
||||
docker pull registry.gitlab.com/gitlab-org/duo-workflow/default-docker-image/workflow-generic-image:v0.0.4
|
||||
```
|
||||
|
||||
1. For permission issues, ensure your operating system user has the necessary Docker permissions.
|
||||
1. Verify that Docker has internet connectivity by executing the command `docker image pull redhat/ubi8`.
|
||||
If this does not work, the DNS configuration of Colima might be at fault.
|
||||
Edit the DNS setting in `~/.colima/default/colima.yaml` to `dns: [1.1.1.1]` and then restart Colima with `colima restart`.
|
||||
1. Check the executor logs:
|
||||
- Use `docker ps -a | grep duo-workflow` to get the list of containers and their ids.
|
||||
- Use `docker logs <container_id>` to view the logs for the specific container.
|
||||
|
||||
## IDE configuration
|
||||
|
||||
You can try several things to ensure your repository is properly configured and connected.
|
||||
|
||||
### View the project in the GitLab Workflow extension
|
||||
|
||||
Start by ensuring the correct project is selected in the GitLab Workflow extension for VS Code.
|
||||
|
||||
1. In VS Code, on the left sidebar, select **GitLab Workflow** ({{< icon name="tanuki" >}}).
|
||||
1. Ensure the project is listed and selected.
|
||||
|
||||
If an error message appears next to the project name, select it to reveal what needs to be updated.
|
||||
|
||||
For example, you might have multiple repositories and need to select one, or there might be no repositories at all.
|
||||
|
||||
#### No Git repository
|
||||
|
||||
If your workspace doesn't have a Git repository initialized, you must create a new one:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. Select **Initialize Repository**.
|
||||
|
||||
When the repository is initialized, you should see the name in the **Source Control** view.
|
||||
|
||||
#### Git repository with no GitLab remote
|
||||
|
||||
You might have a Git repository but it's not properly connected to GitLab.
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. On the **Source Control** label, right-click and select **Repositories**.
|
||||
1. Next to your repository, select the ellipsis ({{< icon name=ellipsis_h >}}), then **Remote > Add Remote**.
|
||||
1. Enter your GitLab project URL.
|
||||
1. Select the newly added remote as your upstream.
|
||||
|
||||
#### Multiple GitLab remotes
|
||||
|
||||
Your repository might have multiple GitLab remotes configured.
|
||||
To select the correct one:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. On the status bar, select the current remote name.
|
||||
1. From the list, select the appropriate GitLab remote.
|
||||
1. Ensure the selected remote belongs to a group namespace in GitLab.
|
||||
|
||||
#### Multiple GitLab projects
|
||||
|
||||
If your VS Code workspace contains multiple GitLab projects, you might want
|
||||
to close all the projects you're not using.
|
||||
|
||||
To close projects:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. Ensure repositories are shown: on the **Source Control** label, right-click and select **Repositories**.
|
||||
1. Right-click the repository you want to close and select **Close Repository**.
|
||||
|
||||
### Project not in a group namespace
|
||||
|
||||
GitLab Duo Agent Platform requires that projects belong to a group namespace.
|
||||
|
||||
To determine the namespace your project is in, [look at the URL](../namespace/_index.md#determine-which-type-of-namespace-youre-in).
|
||||
|
||||
If necessary, you can
|
||||
[transfer your project to a group namespace](../../tutorials/move_personal_project_to_group/_index.md#move-your-project-to-a-group).
|
||||
|
||||
## Still having issues?
|
||||
|
||||
Contact your GitLab administrator for assistance.
|
||||
|
|
@ -0,0 +1,262 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: GitLab Duo Agent Platform use cases
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/551382) from `Workflow` to `Agent Platform` in GitLab 18.2.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
The following use case examples demonstrate some of the ways you might use GitLab Duo Agent Platform.
|
||||
|
||||
## Refactor existing code
|
||||
|
||||
Use this approach when you need to improve performance, readability, or maintainability of existing code.
|
||||
|
||||
### Analyze
|
||||
|
||||
Ask GitLab Duo to analyze the current implementation.
|
||||
|
||||
- Request identification of complexity issues, performance bottlenecks, and readability concerns.
|
||||
- Have the Agent Platform suggest applicable design patterns.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Analyze the UserPermissions class in app/models/user_permissions.rb. Focus on:
|
||||
|
||||
1. Current methods and their complexity
|
||||
2. Performance bottlenecks
|
||||
3. Areas where readability can be improved
|
||||
4. Potential design patterns that could be applied
|
||||
|
||||
Provide a summary of your findings and suggestions for refactoring.
|
||||
Reference any similar refactoring in our codebase if applicable (link existing files if any).
|
||||
Document your analysis process.
|
||||
```
|
||||
|
||||
### Plan
|
||||
|
||||
Then, request a structured refactoring proposal.
|
||||
|
||||
- Ask for clear documentation of proposed changes.
|
||||
- Have the Agent Platform outline potential risks and estimated effort.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Based on the analysis of UserPermissions, create a refactoring proposal:
|
||||
|
||||
1. Outline the new structure for UserPermissions
|
||||
2. Suggest new method names and their purposes
|
||||
3. Propose any new classes or modules if needed
|
||||
4. Explain how this refactoring will improve performance and readability
|
||||
|
||||
Format the proposal as a GitLab issue template, including:
|
||||
|
||||
- Problem statement
|
||||
- Proposed solution
|
||||
- Potential risks
|
||||
- Estimated effort
|
||||
```
|
||||
|
||||
### Implement
|
||||
|
||||
Now, ask GitLab Duo to create implementation files that follow your coding standards.
|
||||
|
||||
- Request detailed comments explaining the changes.
|
||||
- Ask for test coverage of the new implementation.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Implement the refactoring of UserPermissions as proposed:
|
||||
|
||||
1. Create a new file app/models/user_permissions_refactored.rb
|
||||
2. Implement the new UserPermissions class structure
|
||||
3. Include detailed comments explaining the changes
|
||||
4. Update one existing method in app/controllers/users_controller.rb to use the new UserPermissions class
|
||||
5. Write RSpec tests for the new UserPermissions class in spec/models/user_permissions_spec.rb
|
||||
|
||||
Follow our Ruby style guide and best practices for testing.
|
||||
Document any decisions made during implementation.
|
||||
```
|
||||
|
||||
### Evaluate results
|
||||
|
||||
Finally, verify the changes work as expected through testing.
|
||||
|
||||
- If issues arise, provide specific feedback to guide improvement.
|
||||
- Document performance gains or other improvements.
|
||||
|
||||
## Bootstrap a new project
|
||||
|
||||
Use this approach when you start a new application or service from scratch.
|
||||
|
||||
### Initialize the project
|
||||
|
||||
Request a project structure that follow best practices for your tech stack.
|
||||
|
||||
- Ask for recommended dependencies and configurations.
|
||||
- Have GitLab Duo generate initial documentation.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Initialize a new Ruby on Rails project for a team collaboration tool:
|
||||
|
||||
1. Generate a project structure following our best practices
|
||||
2. Include recommended gems for development, testing, and production
|
||||
3. Set up a basic CI/CD configuration
|
||||
4. Create an initial README.md with project overview and setup instructions
|
||||
|
||||
Use our existing Rails projects as reference. Document your decisions and reasoning.
|
||||
```
|
||||
|
||||
### Plan the feature
|
||||
|
||||
Now, ask GitLab Duo to create feature definitions and user stories.
|
||||
|
||||
- Request technical approaches for each core feature.
|
||||
- Have the Agent Platform identify potential challenges.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Create an issue template for the core features of our team collaboration tool:
|
||||
|
||||
1. User authentication and authorization
|
||||
2. Team creation and management
|
||||
3. Task tracking and assignment
|
||||
4. Real-time chat functionality
|
||||
5. File sharing and version control
|
||||
|
||||
For each feature:
|
||||
|
||||
- Provide a brief description
|
||||
- List key user stories
|
||||
- Suggest potential technical approaches
|
||||
- Identify any potential challenges or considerations
|
||||
|
||||
Format this as an epic with individual issues for each core feature.
|
||||
```
|
||||
|
||||
### Set up a foundation
|
||||
|
||||
Now, ask GitLab Duo to design initial data models and schemas.
|
||||
|
||||
- Request setup of testing frameworks and CI/CD configurations.
|
||||
- Ask for implementation of authentication and core APIs.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Design an initial database schema for our team collaboration tool:
|
||||
|
||||
1. Create migrations for core models (User, Team, Task, Message, File)
|
||||
2. Define associations between models
|
||||
3. Include necessary indexes for performance
|
||||
4. Add comments explaining design decisions
|
||||
|
||||
Use our database best practices and naming conventions.
|
||||
Generate the migrations in db/migrate/ directory.
|
||||
Provide a visual representation of the schema (for example, using Mermaid diagram syntax).
|
||||
```
|
||||
|
||||
### Track progress
|
||||
|
||||
Finally, request a summary of implemented features.
|
||||
|
||||
- Ask for a prioritized list of remaining tasks.
|
||||
- Have GitLab Duo identify risks or challenges.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Create a progress report and next steps plan:
|
||||
|
||||
1. Summarize implemented features and their current status
|
||||
2. Identify any deviations from the initial plan and explain reasons
|
||||
3. List remaining tasks from the core features epic
|
||||
4. Suggest a prioritized roadmap for the next development sprint
|
||||
5. Identify any potential risks or challenges for upcoming work
|
||||
|
||||
Format this as an issue with appropriate labels and mentions.
|
||||
Include relevant metrics (like test coverage and security scan results).
|
||||
```
|
||||
|
||||
## Add a new feature
|
||||
|
||||
Use this approach to extend functionality in existing projects.
|
||||
|
||||
### Provision the context
|
||||
|
||||
First, specify the technology stack and relevant files.
|
||||
|
||||
- Clearly define the desired behavior and requirements.
|
||||
- Point to similar implementations that can serve as reference.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
In this project, let's add a new page for users to submit feedback.
|
||||
The current implementation is in Vue and routes are served from a fastify HTTP server,
|
||||
located at path/to/fastify/server.ts. The new route should be `/feedback` and serve
|
||||
a new vue component called `feedback.vue`.
|
||||
|
||||
The feedback vue component should have 3 fields:
|
||||
|
||||
- User email as an input field
|
||||
- A dropdown with 5 values to ask how they heard about us
|
||||
- One textarea for the actual feedback
|
||||
|
||||
The dropdown field is optional. There should also be a submit button.
|
||||
When the button is clicked, show a banner to tell users their feedback was sent.
|
||||
```
|
||||
|
||||
### Request implementation
|
||||
|
||||
Now, ask for all necessary component parts (UI, logic, data models).
|
||||
|
||||
- Request test files for the new functionality.
|
||||
- Specify expected output formats and integration points.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Please implement:
|
||||
|
||||
1. The new Vue component at src/components/feedback.vue
|
||||
2. The route handling in the fastify server at path/to/fastify/server.ts
|
||||
3. Any necessary backend API endpoints to handle the form submission
|
||||
4. Unit tests for the Vue component and API endpoints
|
||||
|
||||
The implementation should follow our existing patterns for
|
||||
form validation and API responses. Reference the contact form at
|
||||
src/components/contact.vue for styling and error handling approaches.
|
||||
```
|
||||
|
||||
### Review and refine
|
||||
|
||||
Finally, verify the implementation meets requirements.
|
||||
|
||||
- Check for adherence to code standards.
|
||||
- Test the feature thoroughly.
|
||||
|
|
@ -270,8 +270,11 @@ With the condition key, you can limit who can use CMK for encrypting or decrypti
|
|||
"AWS": "arn:aws:iam::<awsAccountId>:role/<rolename>"
|
||||
},
|
||||
"Action": [
|
||||
"kms:GenerateDataKeyWithoutPlaintext",
|
||||
"kms:Decrypt",
|
||||
"kms:DescribeKey",
|
||||
"kms:Encrypt",
|
||||
"kms:GenerateDataKey",
|
||||
"kms:GenerateDataKeyWithoutPlaintext",
|
||||
"kms:ReEncryptFrom",
|
||||
"kms:ReEncryptTo"
|
||||
],
|
||||
|
|
|
|||
|
|
@ -1,191 +1,13 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: GitLab Duo Workflow
|
||||
redirect_to: '../duo_agent_platform/_index.md'
|
||||
remove_date: '2025-09-29'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
- LLM: Anthropic [Claude Sonnet 4](https://www.anthropic.com/claude/sonnet)
|
||||
This document was moved to [another location](../duo_agent_platform/_index.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/14153) in GitLab 17.4 [with a flag](../../administration/feature_flags/_index.md) named `duo_workflow`. Enabled for GitLab team members only. This feature is a [private beta](../../policy/development_stages_support.md).
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="flag" >}}
|
||||
|
||||
The availability of this feature is controlled by a feature flag.
|
||||
For more information, see the history.
|
||||
This feature is available for internal GitLab team members for testing, but not ready for production use.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="disclaimer" />}}
|
||||
|
||||
GitLab Duo Workflow helps you complete development tasks directly in the VS Code integrated development environment (IDE).
|
||||
|
||||
Workflow:
|
||||
|
||||
- Runs in your IDE so that you do not have to switch contexts or tools.
|
||||
- Creates and works through a plan, in response to your prompt.
|
||||
- Stages proposed changes in your project's repository.
|
||||
You control when to accept, modify, or reject the suggestions.
|
||||
- Understands the context of your project structure, codebase, and history.
|
||||
You can also add your own context, such as relevant GitLab issues or merge requests.
|
||||
|
||||
For a click-through demo, see [GitLab Duo Workflow](https://gitlab.navattic.com/duo-workflow).
|
||||
<!-- Demo published on 2025-03-18 -->
|
||||
|
||||
For an overview, watch <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Enhancing your quality assurance with GitLab Duo Workflow](https://youtu.be/Tuj7TgqY81Q?si=IbxaKv7IhAHYnHkN). <!-- Video published on 2025-03-20-->
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you can use Workflow, you must:
|
||||
|
||||
- [Install Visual Studio Code](https://code.visualstudio.com/download) (VS Code).
|
||||
- [Set up the GitLab Workflow extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow#setup). Minimum version 5.16.0.
|
||||
- Have an account on GitLab.com.
|
||||
- Have a project that meets the following requirements:
|
||||
- The project is on GitLab.com.
|
||||
- You have at least the Developer role.
|
||||
- The project belongs to a [group namespace](../namespace/_index.md) with an Ultimate subscription.
|
||||
- [Beta and experimental features must be turned on](../gitlab_duo/turn_on_off.md#turn-on-beta-and-experimental-features).
|
||||
- [GitLab Duo must be turned on](../gitlab_duo/turn_on_off.md).
|
||||
- The repository you want to work with should be small or medium-sized.
|
||||
Workflow can be slow or fail for large repositories.
|
||||
- [Successfully connect to your repository](#connect-to-your-repository).
|
||||
- [Ensure an HTTP/2 connection to the Workflow service is possible](troubleshooting.md#network-issues).
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Though not recommended, you can [set up Workflow in a Docker container](docker_set_up.md).
|
||||
You do not need to use Docker to run Workflow.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Connect to your repository
|
||||
|
||||
To use Workflow in VS Code, ensure your repository is properly connected.
|
||||
|
||||
1. In VS Code, on the top menu, select **Terminal > New Terminal**.
|
||||
1. Clone your repository: `git clone <repository>`.
|
||||
1. Change to the directory where your repository was cloned and check out your branch: `git checkout <branch_name>`.
|
||||
1. Ensure your project is selected:
|
||||
1. On the left sidebar, select **GitLab Workflow** ({{< icon name="tanuki" >}}).
|
||||
1. Select the project name. If you have multiple projects, select the one you want to work with.
|
||||
1. In the terminal, ensure your repository is configured with a remote: `git remote -v`. The results should look similar to:
|
||||
|
||||
```plaintext
|
||||
origin git@gitlab.com:gitlab-org/gitlab.git (fetch)
|
||||
origin git@gitlab.com:gitlab-org/gitlab.git (push)
|
||||
```
|
||||
|
||||
If no remote is defined, or you have multiple remotes:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. On the **Source Control** label, right-click and select **Repositories**.
|
||||
1. Next to your repository, select the ellipsis ({{< icon name=ellipsis_h >}}), then **Remote > Add Remote**.
|
||||
1. Select **Add remote from GitLab**.
|
||||
1. Choose a remote.
|
||||
|
||||
Now you can use Workflow to help solve your coding tasks.
|
||||
|
||||
## Use Workflow in VS Code
|
||||
|
||||
To use Workflow in VS Code:
|
||||
|
||||
1. Open the Command Palette:
|
||||
- On macOS: <kbd>Cmd</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd>.
|
||||
- On Windows and Linux: <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd>.
|
||||
1. Type `GitLab Duo Workflow` and select **GitLab: Show Duo Workflow**.
|
||||
1. In the text box, specify a code task in detail.
|
||||
- For assistance writing your prompt, see [use case examples](use_cases.md) and [best practices](best_practices.md).
|
||||
- Workflow is aware of all files available to Git in the project branch.
|
||||
- You can also give Workflow [additional context](#the-context-workflow-is-aware-of).
|
||||
- Workflow cannot access external sources or the web.
|
||||
1. Select **Start**.
|
||||
|
||||
After you describe your task, Workflow generates and executes on a plan to address it.
|
||||
While it executes, you can pause or ask it to adjust the plan.
|
||||
|
||||
For more information about how to interact with Workflow, see [best practices](best_practices.md).
|
||||
|
||||
## The context Workflow is aware of
|
||||
|
||||
When you ask Workflow for help with a task, it will refer to files available to Git in the current branch of the project in your VS Code workspace.
|
||||
|
||||
You can ask about other projects, but they must meet the [prerequisites](#prerequisites).
|
||||
|
||||
You can also provide it with additional context.
|
||||
|
||||
| Area | Enter in Workflow | Examples |
|
||||
|-------------------------|------------------------|----------|
|
||||
| Local files | The file with path. |• Summarize the file `src/main.js`<br>• Review the code in `app/models/`<br>• List all JavaScript files in the project |
|
||||
| Epics | Either:<br>• The URL of the group or epic. <br>• The epic ID and the name of the group the epic is in. | Examples:<br>• List all epics in `https://gitlab.com/groups/namespace/group`<br>• Summarize the epic: `https://gitlab.com/groups/namespace/group/-/epics/42`<br>• `Summarize epic 42 in group namespace/group` |
|
||||
| Issues | Either:<br>• The URL of the project or issue. <br>• The issue ID in the current or another project. | Examples:<br>• List all issues in the project at `https://gitlab.com/namespace/project`<br>• Summarize the issue at `https://gitlab.com/namespace/project/-/issues/103`<br>• Review the comment with ID `42` in `https://gitlab.com/namespace/project/-/issues/103`<br>• List all comments on the issue at `https://gitlab.com/namespace/project/-/issues/103`<br>• Summarize issue `103` in this project |
|
||||
| Merge requests | Either:<br>• The URL of the merge request. <br>• The merge request ID in the current or another project. |• Summarize `https://gitlab.com/namespace/project/-/merge_requests/103`<br>• Review the diffs in `https://gitlab.com/namespace/project/-/merge_requests/103`<br>• Summarize the comments on `https://gitlab.com/namespace/project/-/merge_requests/103`<br>• Summarize merge request `103` in this project |
|
||||
| Merge request pipelines | The merge request ID in the current or another project. |• Review the failures in merge request `12345`<br>• Can you identify the cause of the error in the merge request `54321` in project `gitlab-org/gitlab-qa` <br>• Suggest a solution to the pipeline failure in `https://gitlab.com/namespace/project/-/merge_requests/54321` |
|
||||
|
||||
Workflow also has access to the GitLab [Search API](../../api/search.md) to find related issues or merge requests.
|
||||
|
||||
## Supported languages
|
||||
|
||||
Workflow officially supports the following languages:
|
||||
|
||||
- CSS
|
||||
- Go
|
||||
- HTML
|
||||
- Java
|
||||
- JavaScript
|
||||
- Markdown
|
||||
- Python
|
||||
- Ruby
|
||||
- TypeScript
|
||||
|
||||
## APIs that Workflow has access to
|
||||
|
||||
To create solutions and understand the context of the problem,
|
||||
Workflow accesses several GitLab APIs.
|
||||
|
||||
Specifically, an OAuth token with the `ai_workflows` scope has access
|
||||
to the following APIs:
|
||||
|
||||
- [Projects API](../../api/projects.md)
|
||||
- [Search API](../../api/search.md)
|
||||
- [CI Pipelines API](../../api/pipelines.md)
|
||||
- [CI Jobs API](../../api/jobs.md)
|
||||
- [Merge Requests API](../../api/merge_requests.md)
|
||||
- [Epics API](../../api/epics.md)
|
||||
- [Issues API](../../api/issues.md)
|
||||
- [Notes API](../../api/notes.md)
|
||||
- [Usage Data API](../../api/usage_data.md)
|
||||
|
||||
## Audit log
|
||||
|
||||
An audit event is created for each API request done by Workflow.
|
||||
On your GitLab Self-Managed instance, you can view these events on the
|
||||
[instance audit events](../../administration/compliance/audit_event_reports.md#instance-audit-events) page.
|
||||
|
||||
## Give feedback
|
||||
|
||||
Workflow is a private beta and your feedback is crucial to improve it for you and others.
|
||||
To report issues or suggest improvements,
|
||||
[complete this survey](https://gitlab.fra1.qualtrics.com/jfe/form/SV_9GmCPTV7oH9KNuu).
|
||||
|
||||
## Related topics
|
||||
|
||||
- [Use GitLab Duo Workflow to improve application quality assurance](https://about.gitlab.com/blog/2025/04/10/use-gitlab-duo-workflow-to-improve-application-quality-assurance/)
|
||||
<!-- This redirect file can be deleted after <2025-09-29>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/development/documentation/redirects -->
|
||||
|
|
@ -1,100 +1,13 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Best practices for GitLab Duo Workflow
|
||||
redirect_to: '../duo_agent_platform/best_practices.md'
|
||||
remove_date: '2025-09-29'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
This document was moved to [another location](../duo_agent_platform/best_practices.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Follow these best practices to get the most value from GitLab Duo Workflow.
|
||||
|
||||
## Create focused prompts
|
||||
|
||||
A prompt is the text input that you give to Workflow. To create an effective prompt:
|
||||
|
||||
- Define a clear goal with measurable outcomes.
|
||||
- Provide clear context by including relevant files, merge requests, or issues.
|
||||
For information about the types of context Workflow understands, see
|
||||
[context](_index.md#the-context-workflow-is-aware-of).
|
||||
- Provide examples of expected changes.
|
||||
- Include or link to any technical requirements or rules.
|
||||
|
||||
Example prompt:
|
||||
|
||||
```plaintext
|
||||
Scan all Vue.js components in the 'src/components' directory. Add appropriate ARIA attributes
|
||||
to improve accessibility. Focus on buttons, forms, and navigation elements.
|
||||
Ensure changes maintain existing functionality.
|
||||
```
|
||||
|
||||
## Review the plan
|
||||
|
||||
After you enter your prompt, Workflow generates a plan containing tasks. You can pause and restart Workflow as it creates and works through its plan.
|
||||
|
||||
During this process:
|
||||
|
||||
- Confirm all target files are correctly identified.
|
||||
- Verify proposed changes align with requirements.
|
||||
- Check for any missing dependencies or integration points.
|
||||
- Pause the workflow and adjust if needed.
|
||||
|
||||
## Check proposed changes
|
||||
|
||||
As Workflow works through its plan, it stages corresponding changes to the files in your project. The changes might include new or modified files.
|
||||
|
||||
Before committing the changes:
|
||||
|
||||
1. Check that Workflow:
|
||||
|
||||
- Targeted the correct files.
|
||||
- Made appropriate changes.
|
||||
- Followed the requirements and rules from your prompt.
|
||||
|
||||
1. Look for patterns in what it's missing or misinterpreting. Use that data to refine your prompt. Common errors include:
|
||||
|
||||
- The incorrect solution. We are continuing to work on the accuracy of overall generated content. However, Workflow might generate suggestions that are:
|
||||
- Irrelevant.
|
||||
- Incomplete.
|
||||
- Results in failed pipelines.
|
||||
- Potentially insecure.
|
||||
- Offensive or insensitive.
|
||||
- Adds code in the wrong location.
|
||||
- Includes code changes that can't be used by other parts of the system.
|
||||
|
||||
## Iterate and improve
|
||||
|
||||
When Workflow does not produce the expected results:
|
||||
|
||||
- Document the specific areas that need improvement.
|
||||
- Break complex goals into smaller workflows.
|
||||
- Add examples of correct and incorrect implementations.
|
||||
- Refine prompts to address gaps.
|
||||
|
||||
For example, refine your prompts from the general to the specific:
|
||||
|
||||
General:
|
||||
|
||||
```plaintext
|
||||
Add ARIA attributes to improve accessibility.
|
||||
```
|
||||
|
||||
Specific:
|
||||
|
||||
```plaintext
|
||||
Add aria-label attributes to buttons without text content.
|
||||
Use the button's function for the label value.
|
||||
Required format: aria-label="Action description"
|
||||
```
|
||||
<!-- This redirect file can be deleted after <2025-09-29>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/development/documentation/redirects -->
|
||||
|
|
@ -1,87 +1,13 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Set up Docker for GitLab Duo Workflow (optional)
|
||||
redirect_to: '../duo_agent_platform/docker_set_up.md'
|
||||
remove_date: '2025-09-29'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
This document was moved to [another location](../duo_agent_platform/docker_set_up.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Use the following guide to set up GitLab Duo Workflow with Docker.
|
||||
|
||||
This is not the preferred method to run Workflow.
|
||||
If you have VS Code and at least version 5.16.0 of the GitLab Workflow extension for VS Code,
|
||||
you can use Workflow. For more information, see [the prerequisites](_index.md#prerequisites).
|
||||
|
||||
## Install Docker and set the socket file path
|
||||
|
||||
Workflow needs an execution platform like Docker where it can execute arbitrary code,
|
||||
read and write files, and make API calls to GitLab.
|
||||
|
||||
If you are on macOS or Linux, you can either:
|
||||
|
||||
- Use the [automated setup script](docker_set_up.md#automated-setup). Recommended.
|
||||
- Follow the [manual setup](docker_set_up.md#manual-setup).
|
||||
|
||||
If you are not on macOS or Linux, follow the [manual setup](docker_set_up.md#manual-setup).
|
||||
|
||||
### Automated setup
|
||||
|
||||
The automated setup script:
|
||||
|
||||
- Installs [Docker](https://formulae.brew.sh/formula/docker) and [Colima](https://github.com/abiosoft/colima).
|
||||
- Sets Docker socket path in VS Code settings.
|
||||
|
||||
You can run the script with the `--dry-run` flag to check the dependencies
|
||||
that get installed with the script.
|
||||
|
||||
1. Download the [setup script](https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-executor/-/blob/main/scripts/install-runtime).
|
||||
|
||||
```shell
|
||||
wget https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-executor/-/raw/main/scripts/install-runtime
|
||||
```
|
||||
|
||||
1. Run the script.
|
||||
|
||||
```shell
|
||||
chmod +x install-runtime
|
||||
./install-runtime
|
||||
```
|
||||
|
||||
### Manual setup
|
||||
|
||||
1. Install a Docker container engine, such as [Rancher Desktop](https://docs.rancherdesktop.io/getting-started/installation/).
|
||||
1. Set the Docker socket path and Docker settings in VS Code:
|
||||
1. Open VS Code, then open the [Command Palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette):
|
||||
- On macOS: <kbd>Cmd</kbd> + <kbd>,</kbd>
|
||||
- On Windows and Linux: <kbd>Ctrl</kbd> + <kbd>,</kbd>
|
||||
1. In the open Command Palette search for `settings.json`.
|
||||
1. Add a line to `settings.json` that defines the Docker socket path setting `gitlab.duoWorkflow.dockerSocket`,
|
||||
according to your container manager, and save your settings file. Some examples for common container
|
||||
managers on macOS, where you would replace `<your_user>` with your user's home folder:
|
||||
|
||||
- Rancher Desktop:
|
||||
|
||||
```json
|
||||
"gitlab.duoWorkflow.dockerSocket": "/Users/<your_user>/.rd/docker.sock",
|
||||
"gitlab.duoWorkflow.useDocker": true,
|
||||
```
|
||||
|
||||
- Colima:
|
||||
|
||||
```json
|
||||
"gitlab.duoWorkflow.dockerSocket": "/Users/<your_user>/.colima/default/docker.sock",
|
||||
"gitlab.duoWorkflow.useDocker": true,
|
||||
```
|
||||
<!-- This redirect file can be deleted after <2025-09-29>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/development/documentation/redirects -->
|
||||
|
|
@ -1,77 +1,13 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Risks in GitLab Duo Workflow
|
||||
redirect_to: '../duo_agent_platform/risks.md'
|
||||
remove_date: '2025-09-29'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
This document was moved to [another location](../duo_agent_platform/risks.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Workflow is a beta product and users should consider their
|
||||
circumstances before using this tool. It is subject to [the GitLab Testing Agreement](https://handbook.gitlab.com/handbook/legal/testing-agreement/).
|
||||
Workflow is an AI Agent that is given some ability to perform actions on the user's behalf. AI tools based on LLMs are
|
||||
inherently unpredictable and you should take appropriate precautions.
|
||||
|
||||
Workflow in VS Code runs workflows on your local workstation or in a Docker container.
|
||||
Running Duo Workflow inside of a Docker container is not a security measure but a
|
||||
convenience to reduce the amount of disruption to your usual development
|
||||
environment. All the documented risks should be considered before using this
|
||||
product. The following risks are important to understand:
|
||||
|
||||
1. Workflow has access to the local file system of the
|
||||
project where you started running Workflow. Workflow respects your local `.gitignore` file,
|
||||
but it can still access files that are not committed to the project and not called out in `.gitignore`.
|
||||
Such files can contain credentials (for example, `.env` files).
|
||||
1. Workflow also gets access to a time-limited `ai_workflows` scoped GitLab
|
||||
OAuth token with your user's identity. This token can be used to access
|
||||
GitLab APIs on your behalf. This token is limited to the duration of
|
||||
the workflow and only has access to certain APIs in GitLab.
|
||||
Without user approval, Workflow will only perform read operations but the token can still,
|
||||
by design, perform write operations on the users behalf. You should consider
|
||||
the access your user has in GitLab before running Workflow.
|
||||
1. You should not give Workflow any additional credentials or secrets, in
|
||||
goals or messages, as there is a chance it might end up using those in code
|
||||
or other API calls.
|
||||
|
||||
Risks specifically when using Docker to isolate Workflow:
|
||||
|
||||
1. Our supported Docker servers are running in a VM. We do not support Docker
|
||||
Engine running on the host as this offers less isolation. Because Docker
|
||||
Engine is the most common way to run Docker on Linux we will likely not
|
||||
support many Linux setups by default, but instead we'll require them to
|
||||
install an additional Docker runtime to use Workflow.
|
||||
1. This VM running on your local workstation likely has access to your local
|
||||
network, unless you have created additional firewall rules to prevent it.
|
||||
Local network access may be an issue if you are running local development
|
||||
servers on your host that you would not want reachable by the workflow
|
||||
commands. Local network access may also be risky in a corporate intranet
|
||||
environment where you have internal resources that you do not want
|
||||
accessible by Workflow.
|
||||
1. The VM may be able to consume a lot of CPU, RAM and storage based on the
|
||||
limits configured with your Docker VM installation.
|
||||
1. Depending on the configuration of the VM in your Docker installation it may
|
||||
also have access to other hardware on your host.
|
||||
1. Unpatched installations of Docker may contain vulnerabilities that could
|
||||
eventually lead to code execution escaping the VM to the host or accessing
|
||||
resources on the host that you didn't intend.
|
||||
1. Each version of Docker has different ways of mounting directories into the
|
||||
containers. Workflow only mounts the directory for the project you have
|
||||
open in VS Code but depending on how your Docker installation works and
|
||||
whether or not you are running other containers there may still be some
|
||||
risks it could access other parts of your file system.
|
||||
1. All your Docker containers usually run in a single VM. So this
|
||||
may mean that Workflow containers are running in the same VM as other
|
||||
non Workflow containers. While the containers are isolated to some
|
||||
degree this isolation is not as strict as VM level isolation
|
||||
<!-- This redirect file can be deleted after <2025-09-29>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/development/documentation/redirects -->
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
redirect_to: 'docker_set_up.md'
|
||||
redirect_to: '../duo_agent_platform/docker_set_up.md'
|
||||
remove_date: '2025-06-05'
|
||||
---
|
||||
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
This document was moved to [another location](docker_set_up.md).
|
||||
This document was moved to [another location](../duo_agent_platform/docker_set_up.md).
|
||||
|
||||
<!-- This redirect file can be deleted after <2025-06-05>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
|
|
|
|||
|
|
@ -1,154 +1,13 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: Troubleshooting GitLab Duo Workflow
|
||||
redirect_to: '../duo_agent_platform/troubleshooting.md'
|
||||
remove_date: '2025-06-05'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
This document was moved to [another location](../duo_agent_platform/troubleshooting.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## General guidance
|
||||
|
||||
If you encounter issues, ensure that you have:
|
||||
|
||||
1. The latest version of the GitLab Workflow extension for VS Code.
|
||||
1. A project that meets the [prerequisites](_index.md#prerequisites).
|
||||
1. The repository open in VS Code.
|
||||
1. The branch checked out.
|
||||
|
||||
For details on these steps, see [the prerequisites](_index.md#prerequisites) and
|
||||
[how to connect to your repository](_index.md#connect-to-your-repository).
|
||||
|
||||
## View debugging logs
|
||||
|
||||
You can troubleshoot some issues by viewing debugging logs.
|
||||
|
||||
1. Open local debugging logs:
|
||||
- On macOS: <kbd>Cmd</kbd> + <kbd>,</kbd>
|
||||
- On Windows and Linux: <kbd>Ctrl</kbd> + <kbd>,</kbd>
|
||||
1. Search for the setting **GitLab: Debug** and enable it.
|
||||
1. Open the language server logs:
|
||||
1. In VS Code, select **View** > **Output**.
|
||||
1. In the output panel at the bottom, in the upper-right corner,
|
||||
select **GitLab Workflow** or **GitLab Language Server** from the list.
|
||||
1. Review for errors, warnings, connection issues, or authentication problems.
|
||||
|
||||
## Network issues
|
||||
|
||||
Your network might block the connection to the Workflow service,
|
||||
for example, by using a firewall. The network must let HTTP/2 traffic through to the service.
|
||||
|
||||
To confirm that you can connect to the Workflow service:
|
||||
|
||||
1. In Google Chrome or Firefox, open Developer Tools and select the **Network** tab.
|
||||
1. Right-click the column headers to show the **Protocol** column.
|
||||
1. In the address bar, enter `https://duo-workflow-svc.runway.gitlab.net/DuoWorkflow/ExecuteWorkflow`.
|
||||
1. Ensure the request was successful and the **Protocol** column includes `h2` in Chrome or `HTTP/2` in Firefox.
|
||||
|
||||
If the request fails or does not show the HTTP/2 protocol:
|
||||
|
||||
- A security system like Netskope or Zscaler might be configured to block or inspect traffic.
|
||||
- The HTTP/2 protocol downgrades to HTTP/1.1, which prevents Duo Workflow from working correctly.
|
||||
|
||||
To correct this issue, ask your network administrator to put `https://duo-workflow-svc.runway.gitlab.net/DuoWorkflow/ExecuteWorkflow`
|
||||
on the correct allowlist, or to exempt it from traffic inspection.
|
||||
|
||||
## Docker setup
|
||||
|
||||
If you encounter issues with your Docker setup for Workflow, try the following steps.
|
||||
|
||||
1. [Install Docker and set the socket file path](docker_set_up.md#install-docker-and-set-the-socket-file-path).
|
||||
1. Restart your container manager. For example, if you use Colima, `colima restart`.
|
||||
1. Pull the base Docker image:
|
||||
|
||||
```shell
|
||||
docker pull registry.gitlab.com/gitlab-org/duo-workflow/default-docker-image/workflow-generic-image:v0.0.4
|
||||
```
|
||||
|
||||
1. For permission issues, ensure your operating system user has the necessary Docker permissions.
|
||||
1. Verify that Docker has internet connectivity by executing the command `docker image pull redhat/ubi8`.
|
||||
If this does not work, the DNS configuration of Colima might be at fault.
|
||||
Edit the DNS setting in `~/.colima/default/colima.yaml` to `dns: [1.1.1.1]` and then restart Colima with `colima restart`.
|
||||
1. Check the executor logs:
|
||||
- Use `docker ps -a | grep duo-workflow` to get the list of Workflow containers and their ids.
|
||||
- Use `docker logs <container_id>` to view the logs for the specific container.
|
||||
|
||||
## IDE configuration
|
||||
|
||||
You can try several things to ensure your repository is properly configured and connected.
|
||||
|
||||
### View the project in the GitLab Workflow extension
|
||||
|
||||
Start by ensuring the correct project is selected in the GitLab Workflow extension for VS Code.
|
||||
|
||||
1. In VS Code, on the left sidebar, select **GitLab Workflow** ({{< icon name="tanuki" >}}).
|
||||
1. Ensure the project is listed and selected.
|
||||
|
||||
If an error message appears next to the project name, select it to reveal what needs to be updated.
|
||||
|
||||
For example, you might have multiple repositories and need to select one, or there might be no repositories at all.
|
||||
|
||||
#### No Git repository
|
||||
|
||||
If your workspace doesn't have a Git repository initialized, you must create a new one:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. Select **Initialize Repository**.
|
||||
|
||||
When the repository is initialized, you should see the name in the **Source Control** view.
|
||||
|
||||
#### Git repository with no GitLab remote
|
||||
|
||||
You might have a Git repository but it's not properly connected to GitLab.
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. On the **Source Control** label, right-click and select **Repositories**.
|
||||
1. Next to your repository, select the ellipsis ({{< icon name=ellipsis_h >}}), then **Remote > Add Remote**.
|
||||
1. Enter your GitLab project URL.
|
||||
1. Select the newly added remote as your upstream.
|
||||
|
||||
#### Multiple GitLab remotes
|
||||
|
||||
Your repository might have multiple GitLab remotes configured.
|
||||
To select the correct one:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. On the status bar, select the current remote name.
|
||||
1. From the list, select the appropriate GitLab remote.
|
||||
1. Ensure the selected remote belongs to a group namespace in GitLab.
|
||||
|
||||
#### Multiple GitLab projects
|
||||
|
||||
If your VS Code workspace contains multiple GitLab projects, you might want
|
||||
to close all the projects you're not using.
|
||||
|
||||
To close projects:
|
||||
|
||||
1. On the left sidebar, select **Source Control** ({{< icon name="branch" >}}).
|
||||
1. Ensure repositories are shown: on the **Source Control** label, right-click and select **Repositories**.
|
||||
1. Right-click the repository you want to close and select **Close Repository**.
|
||||
|
||||
### Project not in a group namespace
|
||||
|
||||
GitLab Duo Workflow requires that projects belong to a group namespace.
|
||||
|
||||
To determine the namespace your project is in, [look at the URL](../namespace/_index.md#determine-which-type-of-namespace-youre-in).
|
||||
|
||||
If necessary, you can
|
||||
[transfer your project to a group namespace](../../tutorials/move_personal_project_to_group/_index.md#move-your-project-to-a-group).
|
||||
|
||||
## Still having issues?
|
||||
|
||||
Contact your GitLab administrator for assistance.
|
||||
<!-- This redirect file can be deleted after <2025-06-05>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
|
||||
|
|
|
|||
|
|
@ -1,256 +1,13 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: Duo Workflow
|
||||
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
|
||||
title: GitLab Duo Workflow use cases
|
||||
redirect_to: '../duo_agent_platform/use_cases.md'
|
||||
remove_date: '2025-06-05'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com
|
||||
- Status: Private beta
|
||||
This document was moved to [another location](../duo_agent_platform/use_cases.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
This feature is [a private beta](../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
The following use case examples demonstrate some of the ways you might use GitLab Duo Workflow.
|
||||
|
||||
## Refactor existing code
|
||||
|
||||
Use this approach when you need to improve performance, readability, or maintainability of existing code.
|
||||
|
||||
### Analyze
|
||||
|
||||
Ask Workflow to analyze the current implementation.
|
||||
|
||||
- Request identification of complexity issues, performance bottlenecks, and readability concerns.
|
||||
- Have Workflow suggest applicable design patterns.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Analyze the UserPermissions class in app/models/user_permissions.rb. Focus on:
|
||||
|
||||
1. Current methods and their complexity
|
||||
2. Performance bottlenecks
|
||||
3. Areas where readability can be improved
|
||||
4. Potential design patterns that could be applied
|
||||
|
||||
Provide a summary of your findings and suggestions for refactoring.
|
||||
Reference any similar refactoring in our codebase if applicable (link existing files if any).
|
||||
Document your analysis process.
|
||||
```
|
||||
|
||||
### Plan
|
||||
|
||||
Then, request a structured refactoring proposal.
|
||||
|
||||
- Ask for clear documentation of proposed changes.
|
||||
- Have Workflow outline potential risks and estimated effort.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Based on the analysis of UserPermissions, create a refactoring proposal:
|
||||
|
||||
1. Outline the new structure for UserPermissions
|
||||
2. Suggest new method names and their purposes
|
||||
3. Propose any new classes or modules if needed
|
||||
4. Explain how this refactoring will improve performance and readability
|
||||
|
||||
Format the proposal as a GitLab issue template, including:
|
||||
|
||||
- Problem statement
|
||||
- Proposed solution
|
||||
- Potential risks
|
||||
- Estimated effort
|
||||
```
|
||||
|
||||
### Implement
|
||||
|
||||
Now, ask Workflow to create implementation files that follow your coding standards.
|
||||
|
||||
- Request detailed comments explaining the changes.
|
||||
- Ask for test coverage of the new implementation.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Implement the refactoring of UserPermissions as proposed:
|
||||
|
||||
1. Create a new file app/models/user_permissions_refactored.rb
|
||||
2. Implement the new UserPermissions class structure
|
||||
3. Include detailed comments explaining the changes
|
||||
4. Update one existing method in app/controllers/users_controller.rb to use the new UserPermissions class
|
||||
5. Write RSpec tests for the new UserPermissions class in spec/models/user_permissions_spec.rb
|
||||
|
||||
Follow our Ruby style guide and best practices for testing.
|
||||
Document any decisions made during implementation.
|
||||
```
|
||||
|
||||
### Evaluate results
|
||||
|
||||
Finally, verify the changes work as expected through testing.
|
||||
|
||||
- If issues arise, provide specific feedback to guide improvement.
|
||||
- Document performance gains or other improvements.
|
||||
|
||||
## Bootstrap a new project
|
||||
|
||||
Use this approach when you start a new application or service from scratch.
|
||||
|
||||
### Initialize the project
|
||||
|
||||
Request a project structure that follow best practices for your tech stack.
|
||||
|
||||
- Ask for recommended dependencies and configurations.
|
||||
- Have Workflow generate initial documentation.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Initialize a new Ruby on Rails project for a team collaboration tool:
|
||||
|
||||
1. Generate a project structure following our best practices
|
||||
2. Include recommended gems for development, testing, and production
|
||||
3. Set up a basic CI/CD configuration
|
||||
4. Create an initial README.md with project overview and setup instructions
|
||||
|
||||
Use our existing Rails projects as reference. Document your decisions and reasoning.
|
||||
```
|
||||
|
||||
### Plan the feature
|
||||
|
||||
Now, ask Workflow to create feature definitions and user stories.
|
||||
|
||||
- Request technical approaches for each core feature.
|
||||
- Have Workflow identify potential challenges.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Create an issue template for the core features of our team collaboration tool:
|
||||
|
||||
1. User authentication and authorization
|
||||
2. Team creation and management
|
||||
3. Task tracking and assignment
|
||||
4. Real-time chat functionality
|
||||
5. File sharing and version control
|
||||
|
||||
For each feature:
|
||||
|
||||
- Provide a brief description
|
||||
- List key user stories
|
||||
- Suggest potential technical approaches
|
||||
- Identify any potential challenges or considerations
|
||||
|
||||
Format this as an epic with individual issues for each core feature.
|
||||
```
|
||||
|
||||
### Set up a foundation
|
||||
|
||||
Now, ask Workflow to design initial data models and schemas.
|
||||
|
||||
- Request setup of testing frameworks and CI/CD configurations.
|
||||
- Ask for implementation of authentication and core APIs.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Design an initial database schema for our team collaboration tool:
|
||||
|
||||
1. Create migrations for core models (User, Team, Task, Message, File)
|
||||
2. Define associations between models
|
||||
3. Include necessary indexes for performance
|
||||
4. Add comments explaining design decisions
|
||||
|
||||
Use our database best practices and naming conventions.
|
||||
Generate the migrations in db/migrate/ directory.
|
||||
Provide a visual representation of the schema (for example, using Mermaid diagram syntax).
|
||||
```
|
||||
|
||||
### Track progress
|
||||
|
||||
Finally, request a summary of implemented features.
|
||||
|
||||
- Ask for a prioritized list of remaining tasks.
|
||||
- Have Workflow identify risks or challenges.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Create a progress report and next steps plan:
|
||||
|
||||
1. Summarize implemented features and their current status
|
||||
2. Identify any deviations from the initial plan and explain reasons
|
||||
3. List remaining tasks from the core features epic
|
||||
4. Suggest a prioritized roadmap for the next development sprint
|
||||
5. Identify any potential risks or challenges for upcoming work
|
||||
|
||||
Format this as an issue with appropriate labels and mentions.
|
||||
Include relevant metrics (like test coverage and security scan results).
|
||||
```
|
||||
|
||||
## Add a new feature
|
||||
|
||||
Use this approach to extend functionality in existing projects.
|
||||
|
||||
### Provision the context
|
||||
|
||||
First, specify the technology stack and relevant files.
|
||||
|
||||
- Clearly define the desired behavior and requirements.
|
||||
- Point to similar implementations that can serve as reference.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
In this project, let's add a new page for users to submit feedback.
|
||||
The current implementation is in Vue and routes are served from a fastify HTTP server,
|
||||
located at path/to/fastify/server.ts. The new route should be `/feedback` and serve
|
||||
a new vue component called `feedback.vue`.
|
||||
|
||||
The feedback vue component should have 3 fields:
|
||||
|
||||
- User email as an input field
|
||||
- A dropdown with 5 values to ask how they heard about us
|
||||
- One textarea for the actual feedback
|
||||
|
||||
The dropdown field is optional. There should also be a submit button.
|
||||
When the button is clicked, show a banner to tell users their feedback was sent.
|
||||
```
|
||||
|
||||
### Request implementation
|
||||
|
||||
Now, ask for all necessary component parts (UI, logic, data models).
|
||||
|
||||
- Request test files for the new functionality.
|
||||
- Specify expected output formats and integration points.
|
||||
|
||||
Sample prompt:
|
||||
|
||||
```plaintext
|
||||
Please implement:
|
||||
|
||||
1. The new Vue component at src/components/feedback.vue
|
||||
2. The route handling in the fastify server at path/to/fastify/server.ts
|
||||
3. Any necessary backend API endpoints to handle the form submission
|
||||
4. Unit tests for the Vue component and API endpoints
|
||||
|
||||
The implementation should follow our existing patterns for
|
||||
form validation and API responses. Reference the contact form at
|
||||
src/components/contact.vue for styling and error handling approaches.
|
||||
```
|
||||
|
||||
### Review and refine
|
||||
|
||||
Finally, verify the implementation meets requirements.
|
||||
|
||||
- Check for adherence to code standards.
|
||||
- Test the feature thoroughly.
|
||||
<!-- This redirect file can be deleted after <2025-06-05>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ After you're comfortable with the basics, try these more advanced features:
|
|||
When you're ready to maximize your productivity with GitLab Duo:
|
||||
|
||||
- **[GitLab Duo Self-Hosted](../../administration/gitlab_duo_self_hosted/_index.md)** - Host LLMs on your own infrastructure
|
||||
- **[GitLab Duo Workflow](../duo_workflow/_index.md)** - Automate tasks in your development workflow
|
||||
- **[GitLab Duo Agent Platform](../duo_agent_platform/_index.md)** - Automate tasks in your development workflow
|
||||
- **[Vulnerability Resolution](../application_security/vulnerabilities/_index.md#vulnerability-resolution)** - Automatically generate merge requests to fix security issues
|
||||
|
||||
## Best practices
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Excluding [Fireworks AI prompt caching](../project/repository/code_suggestions/_
|
|||
|
||||
All of these AI providers are under data protection agreements with GitLab that prohibit the use of Customer Content for their own purposes, except to perform their independent legal obligations.
|
||||
|
||||
GitLab Duo Chat and GitLab Duo Workflow retain chat history and workflow history, respectively, to help you return quickly to previously discussed topics. You can delete chats in the GitLab Duo Chat interface. GitLab does not otherwise retain input and output data unless customers provide consent through a GitLab [Support Ticket](https://about.gitlab.com/support/portal/). Learn more about [AI feature logging](../../administration/logs/_index.md).
|
||||
GitLab Duo Chat and GitLab Duo Agent Platform retain chat history and workflow history, respectively, to help you return quickly to previously discussed topics. You can delete chats in the GitLab Duo Chat interface. GitLab does not otherwise retain input and output data unless customers provide consent through a GitLab [Support Ticket](https://about.gitlab.com/support/portal/). Learn more about [AI feature logging](../../administration/logs/_index.md).
|
||||
|
||||
Fireworks AI prompt caching is enabled by default to improve Code Suggestions latency. For more information and how to opt out of prompt caching, see the [Code Suggestions prompt caching documentation](../project/repository/code_suggestions/_index.md#prompt-caching).
|
||||
|
||||
|
|
|
|||
|
|
@ -55,4 +55,4 @@ They require a Premium or Ultimate subscription and one of the available add-ons
|
|||
| [Issue Description Generation](../project/issues/managing_issues.md#populate-an-issue-with-issue-description-generation) | {{< icon name="dash-circle" >}} No | {{< icon name="dash-circle" >}} No | {{< icon name="check-circle-filled" >}} Yes | {{< icon name="dash-circle" >}} No | Experiment | {{< icon name="dash-circle" >}} No | {{< icon name="dash-circle" >}} No | N/A |
|
||||
| [Merge Request Summary](../project/merge_requests/duo_in_merge_requests.md#generate-a-description-by-summarizing-code-changes) | {{< icon name="dash-circle" >}} No | {{< icon name="dash-circle" >}} No | {{< icon name="check-circle-filled" >}} Yes | {{< icon name="dash-circle" >}} No | Beta | Beta | {{< icon name="dash-circle" >}} No | Beta |
|
||||
|
||||
[GitLab Duo Workflow](../duo_workflow/_index.md) is in private beta, does not require an add-on, and is not supported for GitLab Duo Self-Hosted.
|
||||
[GitLab Duo Agent Platform](../duo_agent_platform/_index.md) is in private beta, does not require an add-on, and is not supported for GitLab Duo Self-Hosted.
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ Because Agentic Chat requires network access to retrieve resources, network rest
|
|||
might impact its functionality.
|
||||
|
||||
To help resolve Agentic Chat networking issues, see the
|
||||
[GitLab Duo Workflow network issue troubleshooting documentation](../duo_workflow/troubleshooting.md#network-issues).
|
||||
[GitLab Duo Agent Platform network issue troubleshooting documentation](../duo_agent_platform/troubleshooting.md#network-issues).
|
||||
|
||||
### Slow response times
|
||||
|
||||
|
|
|
|||
|
|
@ -11384,6 +11384,9 @@ msgstr ""
|
|||
msgid "Browse files"
|
||||
msgstr ""
|
||||
|
||||
msgid "Build a new repository or import existing work."
|
||||
msgstr ""
|
||||
|
||||
msgid "Build cannot be erased"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -17202,6 +17205,9 @@ msgstr ""
|
|||
msgid "Connect repositories from GitHub"
|
||||
msgstr ""
|
||||
|
||||
msgid "Connect with your team and collaborate on a project."
|
||||
msgstr ""
|
||||
|
||||
msgid "Connect your external repositories, and CI/CD pipelines will run for new commits. A GitLab project will be created with only CI/CD features enabled."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -18702,9 +18708,6 @@ msgstr ""
|
|||
msgid "Create a new project"
|
||||
msgstr ""
|
||||
|
||||
msgid "Create a new project on GitLab. Store your files, plan your work, and collaborate on code."
|
||||
msgstr ""
|
||||
|
||||
msgid "Create a new release"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -35527,10 +35530,7 @@ msgstr ""
|
|||
msgid "Join Zoom meeting"
|
||||
msgstr ""
|
||||
|
||||
msgid "Join a project"
|
||||
msgstr ""
|
||||
|
||||
msgid "Join your team on GitLab and contribute to an existing project."
|
||||
msgid "Join an existing project"
|
||||
msgstr ""
|
||||
|
||||
msgid "Joined %{user_created_time}"
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module QA
|
||||
RSpec.describe 'Monitor', :smoke, product_group: :respond, feature_flag: {
|
||||
RSpec.describe 'Monitor', :smoke, product_group: :platform_insights, feature_flag: {
|
||||
name: :hide_incident_management_features
|
||||
} do
|
||||
describe 'Alert Management' do
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module QA
|
||||
RSpec.describe 'Monitor', :orchestrated, :smtp, :requires_admin, product_group: :respond, feature_flag: {
|
||||
RSpec.describe 'Monitor', :orchestrated, :smtp, :requires_admin, product_group: :platform_insights, feature_flag: {
|
||||
name: :hide_incident_management_features
|
||||
} do
|
||||
describe 'Alert' do
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module QA
|
||||
RSpec.describe 'Monitor', product_group: :respond, quarantine: {
|
||||
RSpec.describe 'Monitor', product_group: :platform_insights, quarantine: {
|
||||
type: :bug,
|
||||
issue: 'https://gitlab.com/gitlab-org/gitlab/-/issues/395512'
|
||||
} do
|
||||
|
|
|
|||
|
|
@ -71,6 +71,7 @@ describe('WorkItemParent component', () => {
|
|||
workItemType = 'Objective',
|
||||
canUpdate = true,
|
||||
parent = null,
|
||||
allowedParentTypesForNewWorkItem = [],
|
||||
searchQueryHandler = availableWorkItemsSuccessHandler,
|
||||
mutationHandler = successUpdateWorkItemMutationHandler,
|
||||
hasParent = true,
|
||||
|
|
@ -92,6 +93,7 @@ describe('WorkItemParent component', () => {
|
|||
workItemType,
|
||||
hasParent,
|
||||
isGroup,
|
||||
allowedParentTypesForNewWorkItem,
|
||||
},
|
||||
stubs: {
|
||||
IssuePopover: true,
|
||||
|
|
@ -133,12 +135,28 @@ describe('WorkItemParent component', () => {
|
|||
});
|
||||
|
||||
it('fetches the work items on edit click', async () => {
|
||||
createComponent();
|
||||
createComponent({
|
||||
allowedParentTypesForNewWorkItem: [
|
||||
{ __typename: 'WorkItemType', id: 'gid://gitlab/WorkItems::Type/1', name: 'Issue' },
|
||||
{ __typename: 'WorkItemType', id: 'gid://gitlab/WorkItems::Type/2', name: 'Incident' },
|
||||
{ __typename: 'WorkItemType', id: 'gid://gitlab/WorkItems::Type/9', name: 'Ticket' },
|
||||
],
|
||||
});
|
||||
|
||||
showDropdown();
|
||||
await nextTick();
|
||||
|
||||
expect(availableWorkItemsSuccessHandler).toHaveBeenCalled();
|
||||
expect(availableWorkItemsSuccessHandler).toHaveBeenCalledWith({
|
||||
fullPath: 'full-path',
|
||||
iid: null,
|
||||
in: undefined,
|
||||
includeAncestors: true,
|
||||
isNumber: false,
|
||||
searchByIid: false,
|
||||
searchByText: true,
|
||||
searchTerm: '',
|
||||
types: ['ISSUE', 'INCIDENT', 'TICKET'],
|
||||
});
|
||||
});
|
||||
});
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue