Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
b4cd90480a
commit
afda3f00de
|
|
@ -12,7 +12,7 @@ DETAILS:
|
|||
|
||||
You can set up a container registry on your **secondary** Geo site that mirrors the one on the **primary** Geo site. This container registry replication is used only for disaster recovery purposes.
|
||||
|
||||
Do not push to the container registry on the **secondary** Geo site, because the data is not be propagated to the **primary** site.
|
||||
Do not push to the container registry on the **secondary** Geo site, because the data is not propagated to the **primary** site.
|
||||
|
||||
We do not recommend pulling container registry data from the **secondary** site because it may be stale. The feature request [issue 365864](https://gitlab.com/gitlab-org/gitlab/-/issues/365864) would solve this problem. You are encouraged to upvote the issue to register your interest.
|
||||
|
||||
|
|
|
|||
|
|
@ -180,7 +180,7 @@ For example, if you have 3,000 users but also know that there's automation at pl
|
|||
|
||||
### Standalone (non-HA)
|
||||
|
||||
For environments serving 2,000 or fewer users, we recommend a standalone approach by deploying a non-HA, single or multi-node environment. With this approach, you can employ strategies such as [automated backups](../../administration/backup_restore/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery. These strategies provide a good level of recovery time objective (RPO) or recovery point objective (RTO) while avoiding the complexities that come with HA.
|
||||
For environments serving 2,000 or fewer users, we recommend a standalone approach by deploying a non-HA, single or multi-node environment. With this approach, you can employ strategies such as [automated backups](../../administration/backup_restore/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery. These strategies provide a good level of recovery time objective (RTO) or recovery point objective (RPO) while avoiding the complexities that come with HA.
|
||||
|
||||
With standalone setups, especially single node environments, various options are available for [installation](../../install/index.md) and management. The options include [the ability to deploy directly by using select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ In the following example:
|
|||
- Three sections have been collapsed and can be expanded.
|
||||
- Three sections are expanded and can be collapsed.
|
||||
|
||||
|
||||
|
||||
|
||||
### Custom collapsible sections
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ this line should be hidden when collapsed
|
|||
|
||||
Sample job console log:
|
||||
|
||||
|
||||
|
||||
|
||||
#### Use a script to improve display of collapsible sections
|
||||
|
||||
|
|
@ -195,7 +195,7 @@ job:
|
|||
|
||||
Here's an example log output with `FF_TIMESTAMPS` enabled:
|
||||
|
||||
|
||||
|
||||
|
||||
To provide feedback on this feature, leave a comment on [issue 463391](https://gitlab.com/gitlab-org/gitlab/-/issues/463391).
|
||||
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ When uploading screenshot artifacts:
|
|||
After the attachment is uploaded, [the pipeline test report](#view-unit-test-reports-on-gitlab)
|
||||
contains a link to the screenshot, for example:
|
||||
|
||||
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ The `__elasticsearch__` methods would return a proxy object, for example:
|
|||
|
||||
These proxy objects would talk to Elasticsearch server directly (see top half of the diagram).
|
||||
|
||||
|
||||
|
||||
|
||||
In the planned new design, each model would have a pair of corresponding sub-classed proxy objects, in which
|
||||
model-specific logic is located. For example, `Snippet` would have `SnippetClassProxy` being a subclass
|
||||
|
|
|
|||
|
|
@ -9,10 +9,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
Use CI/CD to generate your application.
|
||||
|
||||
| | | |
|
||||
|--|--|--|
|
||||
| [**Getting started**](../ci/index.md)<br>Overview of how CI/CD features fit together. | [**CI/CD YAML syntax reference**](../ci/yaml/index.md)<br>Pipeline configuration keywords, syntax, examples, inputs. | [**GitLab-hosted runners**](../ci/runners/index.md)<br>Configuration, job execution. |
|
||||
| [**Pipelines**](../ci/pipelines/index.md)<br>Configuration, automation, stages, schedules, efficiency. | [**Jobs**](../ci/jobs/index.md)<br>Configuration, rules, caching, artifacts, logs. | [**CI/CD components**](../ci/components/index.md)<br>Reusable, versioned CI/CD components for pipelines. |
|
||||
| [**CI/CD variables**](../ci/variables/index.md)<br>Configuration, usage, security. | [**Pipeline security**](../ci/pipelines/pipeline_security.md)<br>Secrets management, job tokens, secure files, cloud security. | [**Debugging**](../ci/debugging.md)<br>Configuration validation, warnings, errors, troubleshooting. |
|
||||
| [**Auto DevOps**](autodevops/index.md)<br>Automated DevOps, language detection, deployment, customization. | [**Testing**](../ci/testing/index.md)<br>Unit tests, integration tests, test reports, coverage, quality assurance. | [**Google cloud integration**](../ci/gitlab_google_cloud_integration/index.md)<br>Cloud services, Kubernetes deployments. |
|
||||
| [**Migrate to GitLab CI/CD**](../ci/migration/plan_a_migration.md)<br> Migrate from Jenkins, GitHub Actions, others. | [**External repository integrations**](../ci/ci_cd_for_external_repos/index.md)<br>GitHub, Bitbucket, external sources, mirroring, cross-platform. | |
|
||||
| | | |
|
||||
|----------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------|
|
||||
| [**Getting started**](../ci/index.md)<br>Overview of how CI/CD features fit together. | [**CI/CD YAML syntax reference**](../ci/yaml/index.md)<br>Pipeline configuration keywords, syntax, examples, inputs. | [**Runners**](../ci/runners/index.md)<br>Configuration, job execution. |
|
||||
| [**Pipelines**](../ci/pipelines/index.md)<br>Configuration, automation, stages, schedules, efficiency. | [**Jobs**](../ci/jobs/index.md)<br>Configuration, rules, caching, artifacts, logs. | [**CI/CD components**](../ci/components/index.md)<br>Reusable, versioned CI/CD components for pipelines. |
|
||||
| [**CI/CD variables**](../ci/variables/index.md)<br>Configuration, usage, security. | [**Pipeline security**](../ci/pipelines/pipeline_security.md)<br>Secrets management, job tokens, secure files, cloud security. | [**Debugging**](../ci/debugging.md)<br>Configuration validation, warnings, errors, troubleshooting. |
|
||||
| [**Auto DevOps**](autodevops/index.md)<br>Automated DevOps, language detection, deployment, customization. | [**Testing**](../ci/testing/index.md)<br>Unit tests, integration tests, test reports, coverage, quality assurance. | [**Google cloud integration**](../ci/gitlab_google_cloud_integration/index.md)<br>Cloud services, Kubernetes deployments. |
|
||||
| [**Migrate to GitLab CI/CD**](../ci/migration/plan_a_migration.md)<br> Migrate from Jenkins, GitHub Actions, others. | [**External repository integrations**](../ci/ci_cd_for_external_repos/index.md)<br>GitHub, Bitbucket, external sources, mirroring, cross-platform. | |
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ To delete the active epic board:
|
|||
- [Create a new list](#create-a-new-list).
|
||||
- [Remove an existing list](#remove-a-list).
|
||||
- [Filter epics](#filter-epics).
|
||||
- Create workflows, like when using [issue boards](../../project/issue_board.md#issue-board-workflow-between-teams).
|
||||
- Create workflows, like when using [issue boards](../../../tutorials/plan_and_track.md).
|
||||
- [Move epics and lists](#move-epics-and-lists).
|
||||
- Change epic labels (by dragging an epic between lists).
|
||||
- Close an epic (by dragging it to the **Closed** list).
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
|
|
@ -14,28 +14,26 @@ DETAILS:
|
|||
> - Ability to delete the last board in a group or project [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/499579) in GitLab 17.6.
|
||||
> - Minimum role to manage issue boards [changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169256) from Reporter to Planner in GitLab 17.7.
|
||||
|
||||
The issue board is a software project management tool used to plan,
|
||||
organize, and visualize a workflow for a feature or product release.
|
||||
|
||||
You can use it as a [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)) or a
|
||||
[Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)) board.
|
||||
The issue board is a tool used to plan, organize, and visualize workflows for a product release, a team, or a project.
|
||||
|
||||
Issue boards pair issue tracking and project management, keeping everything together,
|
||||
so you can organize your workflow on a single platform.
|
||||
|
||||
Issue boards use [issues](issues/index.md) and [labels](labels.md).
|
||||
Your issues appear as cards in vertical lists, organized by their assigned
|
||||
labels, [milestones](#milestone-lists), or [assignees](#assignee-lists).
|
||||
[labels](labels.md), [milestones](#milestone-lists), [iterations](#iteration-lists), or [assignees](#assignee-lists).
|
||||
|
||||
Issue boards help you to visualize and manage your entire process in GitLab.
|
||||
You add your labels, and then create the corresponding list for your existing issues.
|
||||
When you're ready, you can drag your issue cards from one step to another one.
|
||||
Add metadata to your issues, then create the corresponding list for your existing issues.
|
||||
When you're ready, you can drag your issue cards from one list to another.
|
||||
|
||||
An issue board can show you the issues your team is working on, who is assigned to each,
|
||||
and where the issues are in the workflow.
|
||||
|
||||
Issue boards can power common frameworks like [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)) and
|
||||
[Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)).
|
||||
|
||||
To let your team members organize their own workflows, use
|
||||
[multiple issue boards](#use-cases-for-multiple-issue-boards). This allows creating multiple issue
|
||||
[multiple issue boards](#multiple-issue-boards). This allows creating multiple issue
|
||||
boards in the same project.
|
||||
|
||||
|
||||
|
|
@ -63,7 +61,9 @@ Multiple issue boards allow for more than one issue board for:
|
|||
- A project in all tiers
|
||||
- A group in the Premium and Ultimate tier
|
||||
|
||||
This is great for large projects with more than one team or when a repository hosts the code of multiple products.
|
||||
Multiple issue boards are great for large projects with more than one team, in which a repository hosts
|
||||
the code of multiple products and when you want to create boards to power different workflows across
|
||||
the software development lifecycle.
|
||||
|
||||
Using the search box at the top of the menu, you can filter the listed boards.
|
||||
|
||||
|
|
@ -85,13 +85,14 @@ To create a new issue board:
|
|||
|
||||
1. In the upper-left corner of the issue board page, select the dropdown list with the current board name.
|
||||
1. Select **Create new board**.
|
||||
1. Enter the new board's name and select its scope: milestone, labels, assignee, or weight.
|
||||
1. Enter the new board's name and select its scope: milestone, iteration, labels, assignee, or weight.
|
||||
1. Select **Create board**
|
||||
|
||||
### Delete an issue board
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Planner role for the project.
|
||||
- You must have at least the Planner role for the project or group where the board is saved.
|
||||
|
||||
To delete the open issue board:
|
||||
|
||||
|
|
@ -104,15 +105,7 @@ If the board you've deleted was the last one, a new `Development` board is creat
|
|||
## Issue boards use cases
|
||||
|
||||
You can tailor GitLab issue boards to your own preferred workflow.
|
||||
Here are some common use cases for issue boards.
|
||||
|
||||
For examples of using issue boards along with [epics](../group/epics/index.md),
|
||||
[issue health status](issues/managing_issues.md#health-status), and
|
||||
[scoped labels](labels.md#scoped-labels) for various Agile frameworks, see:
|
||||
|
||||
- [How to use GitLab for Agile portfolio planning and project management](https://about.gitlab.com/blog/2020/11/11/gitlab-for-agile-portfolio-planning-project-management/) blog post (November 2020)
|
||||
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
[Cross-project Agile work management with GitLab](https://www.youtube.com/watch?v=5J0bonGoECs) (15 min, July 2020)
|
||||
For workflow-based documentation, see [Tutorials: Plan and track your work](../../tutorials/plan_and_track.md).
|
||||
|
||||
### Use cases for a single issue board
|
||||
|
||||
|
|
@ -138,57 +131,13 @@ If you have the labels **Backend**, **Frontend**, **Staging**, and
|
|||
|
||||
|
||||
|
||||
### Use cases for multiple issue boards
|
||||
### Scrum team
|
||||
|
||||
With [multiple issue boards](#multiple-issue-boards),
|
||||
each team can have their own board to organize their workflow individually.
|
||||
|
||||
<div class="video-fallback">
|
||||
See the video: <a href="https://www.youtube.com/watch?v=d9scVJUIF4c">Portfolio Planning - Portfolio Management</a>.
|
||||
</div>
|
||||
<figure class="video-container">
|
||||
<iframe src="https://www.youtube-nocookie.com/embed/d9scVJUIF4c" frameborder="0" allowfullscreen> </iframe>
|
||||
</figure>
|
||||
|
||||
#### Scrum team
|
||||
|
||||
With multiple issue boards, each team has one board. Now you can move issues through each
|
||||
In a Scrum team, use [multiple issue boards](#multiple-issue-boards) so that each scrum team has their own board.
|
||||
On the Scrum board, you can easily move issues through each
|
||||
part of the process. For example: **To Do**, **Doing**, and **Done**.
|
||||
|
||||
#### Organization of topics
|
||||
|
||||
Create lists to order issues by topic and quickly change them between topics or groups,
|
||||
such as between **UX**, **Frontend**, and **Backend**. The changes are reflected across boards,
|
||||
as changing lists updates the labels on each issue accordingly.
|
||||
|
||||
#### Issue board workflow between teams
|
||||
|
||||
For example, suppose we have a UX team with an issue board that contains:
|
||||
|
||||
- **To Do**
|
||||
- **Doing**
|
||||
- **Frontend**
|
||||
|
||||
When finished with something, they move the card to **Frontend**. The Frontend team's board looks like:
|
||||
|
||||
- **Frontend**
|
||||
- **Doing**
|
||||
- **Done**
|
||||
|
||||
Cards finished by the UX team automatically appear in the **Frontend** column when they are ready
|
||||
for them.
|
||||
|
||||
For a tutorial how to set up your boards in a similar way with [scoped labels](labels.md#scoped-labels), see
|
||||
[Tutorial: Set up issue boards for team hand-off](../../tutorials/boards_for_teams/index.md).
|
||||
|
||||
NOTE:
|
||||
For a broader use case, see the blog post
|
||||
[What is GitLab Flow?](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/).
|
||||
For a real use case example, you can read why
|
||||
[Codepen decided to adopt issue boards](https://about.gitlab.com/blog/2017/01/27/codepen-welcome-to-gitlab/#project-management-everything-in-one-place)
|
||||
to improve their workflow with multiple boards.
|
||||
|
||||
#### Quick assignments
|
||||
### Quick assignments
|
||||
|
||||
To quickly assign issues to your team members:
|
||||
|
||||
|
|
@ -211,6 +160,7 @@ that belong to it. Types of lists include:
|
|||
- **Label list**: all open issues for a label.
|
||||
- [**Assignee list**](#assignee-lists): all open issues assigned to a user.
|
||||
- [**Milestone list**](#milestone-lists): all open issues for a milestone.
|
||||
- [**Iteration list**](#iteration-lists): all open issues for an iteration.
|
||||
|
||||
A **Card** is a box on a list, and it represents an issue. You can drag cards from one list to
|
||||
another to change their label, assignee, or milestone. The information you can see on a
|
||||
|
|
@ -227,6 +177,8 @@ card includes:
|
|||
- Time tracking estimate
|
||||
- Health status
|
||||
|
||||
A **swimlane** is a horizontal grouping of issues on the issue board, for example by parent epic.
|
||||
|
||||
## Ordering issues in a list
|
||||
|
||||
Prerequisites:
|
||||
|
|
@ -255,8 +207,8 @@ and vice versa.
|
|||
|
||||
## Focus mode
|
||||
|
||||
To enable or disable focus mode, in the upper-right corner, select **Toggle focus mode** (**{maximize}**).
|
||||
In focus mode, the navigation UI is hidden, allowing you to focus on issues in the board.
|
||||
To enable or disable focus mode, in the upper-right corner, select **Toggle focus mode** (**{maximize}**).
|
||||
|
||||
## Group issue boards
|
||||
|
||||
|
|
@ -291,22 +243,6 @@ filter through these in the search bar. To do that, you need to remove the desir
|
|||
If you don't have editing permission in a board, you're still able to see the configuration by
|
||||
selecting **Board configuration** (**{settings}**).
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
Watch a [video presentation](https://youtu.be/m5UTNCSqaDk) of
|
||||
the configurable issue board feature.
|
||||
|
||||
### Sum of issue weights
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Premium, Ultimate
|
||||
**Offering:** GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
The top of each list indicates the sum of issue weights for the issues that
|
||||
belong to that list. This is useful when using boards for capacity allocation,
|
||||
especially in combination with [assignee lists](#assignee-lists).
|
||||
|
||||
|
||||
|
||||
### Assignee lists
|
||||
|
||||
DETAILS:
|
||||
|
|
@ -394,9 +330,6 @@ With swimlanes you can visualize issues grouped by epic.
|
|||
Your issue board keeps all the other features, but with a different visual organization of issues.
|
||||
This feature is available both at the project and group level.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For a video overview, see [Epics Swimlanes Walkthrough - 13.6](https://www.youtube.com/watch?v=nHC7-kz5P2g) (November 2020).
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Planner role for the project.
|
||||
|
|
@ -418,7 +351,19 @@ them to change their position and epic assignment:
|
|||
|
||||
|
||||
|
||||
## Work in progress limits
|
||||
### Sum of issue weights
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Premium, Ultimate
|
||||
**Offering:** GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
The top of each list indicates the sum of issue weights for the issues that
|
||||
belong to that list. This is useful when using boards for capacity allocation,
|
||||
especially in combination with [assignee lists](#assignee-lists).
|
||||
|
||||
|
||||
|
||||
### Work in progress limits
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Premium, Ultimate
|
||||
|
|
@ -435,6 +380,8 @@ Examples:
|
|||
- You have a list with five issues with a limit of five. When you move another issue to that list,
|
||||
the list's header displays **6/5**, with the six shown in red. The work in progress line is shown before the sixth issue.
|
||||
|
||||
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Planner role for the project.
|
||||
|
|
@ -447,7 +394,7 @@ To set a WIP limit for a list, in an issue board:
|
|||
1. Enter the maximum number of issues.
|
||||
1. Press <kbd>Enter</kbd> to save.
|
||||
|
||||
## Blocked issues
|
||||
### Blocked issues
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Premium, Ultimate
|
||||
|
|
@ -458,7 +405,7 @@ status.
|
|||
|
||||
When you hover over the blocked icon (**{entity-blocked}**), a detailed information popover is displayed.
|
||||
|
||||
|
||||
|
||||
|
||||
## Actions you can take on an issue board
|
||||
|
||||
|
|
@ -468,7 +415,6 @@ When you hover over the blocked icon (**{entity-blocked}**), a detailed informat
|
|||
- [Remove an issue from a list](#remove-an-issue-from-a-list).
|
||||
- [Filter issues](#filter-issues) that appear across your issue board.
|
||||
- [Move issues and lists](#move-issues-and-lists).
|
||||
- [Multi-select issue cards](#multi-select-issue-cards).
|
||||
- Drag and reorder the lists.
|
||||
- Change issue labels (by dragging an issue between lists).
|
||||
- Close an issue (by dragging it to the **Closed** list).
|
||||
|
|
@ -495,8 +441,7 @@ You can edit the following issue attributes in the right sidebar:
|
|||
- Notifications setting
|
||||
- Title
|
||||
- [Weight](issues/issue_weight.md)
|
||||
|
||||
Additionally, you can also see the time tracking value.
|
||||
- Time tracking
|
||||
|
||||
<!-- When issues_list_drawer feature flag is removed, use the info below
|
||||
and in issues/managing_issues.md#open-issues-in-a-drawer to update the main topic above -->
|
||||
|
|
@ -671,30 +616,6 @@ and the target list.
|
|||
| **From label A list** | Remove label A | Close issue | Remove label A and add label B | Assign Bob |
|
||||
| **From assignee Alice list** | Unassign Alice | Close issue | Add label B | Unassign Alice and assign Bob |
|
||||
|
||||
### Multi-select issue cards
|
||||
|
||||
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61955) behind a [feature flag](../feature_flags.md) named `board_multi_select` in GitLab 14.0. Disabled by default.
|
||||
|
||||
FLAG:
|
||||
On GitLab Self-Managed, by default this feature is not available. To make it available, ask an
|
||||
administrator to [enable the feature flag](../../administration/feature_flags.md) named `board_multi_select`.
|
||||
On GitLab.com and GitLab Dedicated, this feature is not available.
|
||||
This feature is not ready for production use.
|
||||
|
||||
You can select multiple issue cards, then drag the group to another position within the list, or to
|
||||
another list. This makes it faster to reorder many issues at once.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Planner role for the project.
|
||||
|
||||
To select and move multiple cards:
|
||||
|
||||
1. Select each card with <kbd>Control</kbd>+`Click` on Windows or Linux, or <kbd>Command</kbd>+`Click` on MacOS.
|
||||
1. Drag one of the selected cards to another position or list and all selected cards are moved.
|
||||
|
||||
|
||||
|
||||
## Tips
|
||||
|
||||
A few things to remember:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
stage: ModelOps
|
||||
group: MLOps
|
||||
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
|
||||
---
|
||||
|
||||
# MLOps
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
## Model registry
|
||||
|
||||
If you're a data scientist or developer, you can use the model registry to manage your machine learning
|
||||
models, along with all metadata associated with their creation: parameters, performance
|
||||
metrics, artifacts, logs, and more. For more information, see the [model registry documentation](model_registry/index.md).
|
||||
|
||||
## Model experiments
|
||||
|
||||
As a data scientist, when you create machine learning models, you often experiment with different parameters, configurations, and feature
|
||||
engineering to improve the performance of the model. Keeping track of all this metadata and the associated
|
||||
artifacts so that you can later replicate the experiment is not trivial. With machine learning experiment
|
||||
tracking, you can log parameters, metrics, and artifacts directly into GitLab, which provides easy access to these things later on.
|
||||
|
||||
For details, see the [model experiments documentation](experiment_tracking/index.md).
|
||||
|
||||
## GitLab MLOps Python client
|
||||
|
||||
GitLab offers a Python client to interact with the GitLab MLOps features.
|
||||
|
||||
For details, see the [GitLab MLOps Python client documentation](https://gitlab.com/gitlab-org/modelops/mlops/gitlab-mlops).
|
||||
|
|
@ -170,9 +170,6 @@ open in tabs in your IDE as context.
|
|||
These files give GitLab Duo more information about the standards and practices
|
||||
in your code project.
|
||||
|
||||
For more information on possible future context expansion to improve the quality
|
||||
of suggestions, see [epic 11669](https://gitlab.com/groups/gitlab-org/-/epics/11669).
|
||||
|
||||
#### Turn on open files as context
|
||||
|
||||
By default, Code Suggestions uses the open files in your IDE for context when making suggestions.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,10 @@
|
|||
module QA
|
||||
RSpec.describe 'Govern', :skip_live_env, requires_admin: 'creates users and instance OAuth application',
|
||||
only: { condition: -> { Runtime::Env.release } },
|
||||
product_group: :authentication do
|
||||
product_group: :authentication, quarantine: {
|
||||
type: :investigating,
|
||||
issue: 'https://gitlab.com/gitlab-org/gitlab/-/issues/515686'
|
||||
} do
|
||||
let!(:user) { Runtime::User::Store.test_user }
|
||||
let(:consumer_host) { "http://#{consumer_name}.#{Runtime::Env.running_in_ci? ? 'test' : 'bridge'}" }
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue