root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2024-10-25 09:23:00 +00:00
parent 8c1d757d3f
commit f9c8596e3f
28 changed files with 420 additions and 227 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
app/assets/javascripts/ml/model_registry/components/delete_model_version_disclosure_dropdown_item.vue
View File

@ -17,13 +17,10 @@ export default {
};
},
computed: {
deleteConfirmationText() {
return sprintf(
s__('MlModelRegistry|Are you sure you want to delete model version %{versionName}?'),
{
versionName: this.versionName,
},
);
modalTitle() {
return sprintf(s__('MlModelRegistry|Delete version %{versionName}'), {
versionName: this.versionName,
});
},
},
methods: {
@ -34,7 +31,7 @@ export default {
modal: {
id: 'ml-model-version-delete-modal',
actionPrimary: {
text: s__('MlModelRegistry|Delete model version'),
text: s__('MlModelRegistry|Delete version'),
attributes: { variant: 'danger' },
},
actionCancel: {
@ -42,7 +39,12 @@ export default {
},
},
i18n: {
modalTitle: s__('MlModelRegistry|Delete model version?'),
deleteConfirmationText: s__(
'MlModelRegistry|Are you sure you want to delete this model version?',
),
deleteConfirmationNote: s__(
'MlModelRegistry|Deleting this version also deletes all of its imported or uploaded artifacts and its settings.',
),
},
};
</script>
@ -60,13 +62,17 @@ export default {
<gl-modal
:modal-id="$options.modal.id"
:title="$options.i18n.modalTitle"
:title="modalTitle"
:action-primary="$options.modal.actionPrimary"
:action-cancel="$options.modal.actionCancel"
@primary="deleteModelVersion"
>
<p>
{{ deleteConfirmationText }}
{{ $options.i18n.deleteConfirmationText }}
</p>
<p>
<b>{{ __('Note:') }}</b>
{{ $options.i18n.deleteConfirmationNote }}
</p>
</gl-modal>
</template>

2
db/docs/batched_background_migrations/backfill_root_namespace_cluster_agent_mappings.yml
View File

@ -7,4 +7,4 @@ introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/159051
milestone: '17.2'
queued_migration_version: 20240711035245
# Replace with the approximate date you think it's best to ensure the completion of this BBM.
finalized_by: # version of the migration that finalized this BBM
finalized_by: 20241023210409

20
db/post_migrate/20241021221146_prepare_async_index_on_issues_by_project_correct_type_where_closed.rb Normal file
View File

@ -0,0 +1,20 @@
# frozen_string_literal: true
class PrepareAsyncIndexOnIssuesByProjectCorrectTypeWhereClosed < Gitlab::Database::Migration[2.2]
milestone '17.6'
INDEX_NAME = 'tmp_idx_issues_on_project_correct_type_closed_at_where_closed'
def up
# Temporary index to be removed with https://gitlab.com/gitlab-org/gitlab/-/issues/500165
# TODO: Index to be created synchronously in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170005
prepare_async_index :issues, # rubocop:disable Migration/PreventIndexCreation -- Tmp index needed to fix work item type ids
[:project_id, :correct_work_item_type_id, :closed_at],
where: 'state_id = 2',
name: INDEX_NAME
end
def down
unprepare_async_index_by_name :issues, INDEX_NAME
end
end

21
db/post_migrate/20241021221626_prepare_async_index_on_issues_project_health_id_desc_state_correct_type.rb Normal file
View File

@ -0,0 +1,21 @@
# frozen_string_literal: true
class PrepareAsyncIndexOnIssuesProjectHealthIdDescStateCorrectType < Gitlab::Database::Migration[2.2]
milestone '17.6'
disable_ddl_transaction!
INDEX_NAME = 'tmp_idx_issues_on_project_health_id_desc_state_correct_type'
def up
# Temporary index to be removed with https://gitlab.com/gitlab-org/gitlab/-/issues/500165
# TODO: Index to be created synchronously in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170005
prepare_async_index :issues, # rubocop:disable Migration/PreventIndexCreation -- Tmp index needed to fix work item type ids
[:project_id, :health_status, :id, :state_id, :correct_work_item_type_id],
order: { health_status: 'DESC NULLS LAST', id: :desc },
name: INDEX_NAME
end
def down
unprepare_async_index_by_name :issues, INDEX_NAME
end
end

21
db/post_migrate/20241021221755_prepare_async_index_on_issues_project_health_id_asc_state_correct_type.rb Normal file
View File

@ -0,0 +1,21 @@
# frozen_string_literal: true
class PrepareAsyncIndexOnIssuesProjectHealthIdAscStateCorrectType < Gitlab::Database::Migration[2.2]
milestone '17.6'
disable_ddl_transaction!
INDEX_NAME = 'tmp_idx_issues_on_project_health_id_asc_state_correct_type'
def up
# Temporary index to be removed with https://gitlab.com/gitlab-org/gitlab/-/issues/500165
# TODO: Index to be created synchronously in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170005
prepare_async_index :issues, # rubocop:disable Migration/PreventIndexCreation -- Tmp index needed to fix work item type ids
[:project_id, :health_status, :id, :state_id, :correct_work_item_type_id],
order: { health_status: 'ASC NULLS LAST', id: :desc },
name: INDEX_NAME
end
def down
unprepare_async_index_by_name :issues, INDEX_NAME
end
end

20
db/post_migrate/20241021221938_prepare_async_index_on_issues_correct_type_project_created_at_state.rb Normal file
View File

@ -0,0 +1,20 @@
# frozen_string_literal: true
class PrepareAsyncIndexOnIssuesCorrectTypeProjectCreatedAtState < Gitlab::Database::Migration[2.2]
milestone '17.6'
disable_ddl_transaction!
INDEX_NAME = 'tmp_idx_issues_on_correct_type_project_created_at_state'
def up
# Temporary index to be removed with https://gitlab.com/gitlab-org/gitlab/-/issues/500165
# TODO: Index to be created synchronously in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170005
prepare_async_index :issues, # rubocop:disable Migration/PreventIndexCreation -- Tmp index needed to fix work item type ids
[:correct_work_item_type_id, :project_id, :created_at, :state_id],
name: INDEX_NAME
end
def down
unprepare_async_index_by_name :issues, INDEX_NAME
end
end

23
db/post_migrate/20241023210409_finalize_backfill_root_namespace_cluster_agent_mappings.rb Normal file
View File

@ -0,0 +1,23 @@
# frozen_string_literal: true
class FinalizeBackfillRootNamespaceClusterAgentMappings < Gitlab::Database::Migration[2.2]
milestone '17.6'
MIGRATION = 'BackfillRootNamespaceClusterAgentMappings'
disable_ddl_transaction!
restrict_gitlab_migration gitlab_schema: :gitlab_main_cell
def up
ensure_batched_background_migration_is_finished(
job_class_name: MIGRATION,
table_name: :remote_development_agent_configs,
column_name: :id,
job_arguments: [],
finalize: true
)
end
def down
# no-op
end
end

1
db/schema_migrations/20241021221146 Normal file
View File

@ -0,0 +1 @@
4676d9a1135d4ac9a39ce45cdcf9e3b78168568c5bc8a19b7e669c26327b9fd4

1
db/schema_migrations/20241021221626 Normal file
View File

@ -0,0 +1 @@
d4187222c9f3d30105ae6e3c33fe099c3b2ee1ebc0504dd25d7bd74a572ad4d8

1
db/schema_migrations/20241021221755 Normal file
View File

@ -0,0 +1 @@
0f60086429108b26ad10810807cda67abc4d07127f0dbf4dc0fb9eedbad159ea

1
db/schema_migrations/20241021221938 Normal file
View File

@ -0,0 +1 @@
4bd39fae4c2eccbbde95b75e41ce9a6e99e48b2637163940a99d69427c0f1b21

1
db/schema_migrations/20241023210409 Normal file
View File

@ -0,0 +1 @@
2f1567d2e69137fd8569367e58e61f0e4b81daa0baa131d2bbea3fbdc2f501eb

0
doc/ci/yaml/img/ci_log_timestamp_v17_1.png → doc/ci/jobs/img/ci_log_timestamp_v17_1.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 52 KiB

0
doc/ci/yaml/img/collapsible_job_v16_10.png → doc/ci/jobs/img/collapsible_job_v16_10.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 33 KiB

After

Width:  |  Height:  |  Size: 33 KiB

0
doc/ci/yaml/img/collapsible_log_v13_10.png → doc/ci/jobs/img/collapsible_log_v13_10.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 47 KiB

18
doc/ci/jobs/index.md
View File

@ -42,7 +42,7 @@ independently from each other.
When you access a pipeline, you can see the related jobs for that pipeline.
Selecting an individual job shows you its job log, and allows you to:
Selecting an individual job shows you its [job log](job_logs.md), and allows you to:
- Cancel the job.
- Retry the job, if it failed.
@ -302,16 +302,6 @@ For example, if you start rolling out new code and:
![Pipelines example](img/pipeline_delayed_job_v14_2.png)
## View job logs in full screen mode
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363617) in GitLab 16.7.
You can view the contents of a job log in full screen mode by clicking **Show full screen**.
To use full screen mode, your web browser must also support it. If your web browser does not support full screen mode, then the option is not available.
Job logs divided into sections can be collapsed or expanded. For more details, see [Expand and collapse job log sections](../yaml/script.md#expand-and-collapse-job-log-sections).
## Deployment jobs
Deployment jobs are a specific kind of CI job in that they deploy code to
@ -338,12 +328,6 @@ and [ensuring only one deployment job runs at a time](../environments/deployment
## Troubleshooting
### Job log slow to update
When you visit the job log page for a running job, there could be a delay of up to
60 seconds before a log update. The default refresh time is 60 seconds, but after
the log is viewed in the UI one time, log updates should occur every 3 seconds.
### `get_sources` job section fails because of an HTTP/2 problem
Sometimes, jobs fail with the following cURL error:

208
doc/ci/jobs/job_logs.md Normal file
View File

@ -0,0 +1,208 @@
---
stage: Verify
group: Pipeline Execution
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
---
# CI/CD job logs
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
A job log displays the full execution history of a [CI/CD job](index.md).
## View job logs
To view job logs:
1. Select the project for which you want to view job logs.
1. On the left sidebar, select **CI/CD > Pipelines**.
1. Select the pipeline you want to inspect.
1. In the pipeline view, in the list of jobs, select a job to view the job logs page.
To view detailed information about the job and its log output, scroll through the job logs page.
## View job logs in full screen mode
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363617) in GitLab 16.7.
You can view the contents of a job log in full screen mode by clicking **Show full screen**.
To use full screen mode, your web browser must also support it. If your web browser does not support full screen mode, then the option is not available.
## Expand and collapse job log sections
> - Support for output of multi-line command bash shell output [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3486) in GitLab 16.5 behind the [GitLab Runner feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html), `FF_SCRIPT_SECTIONS`.
Job logs are divided into sections that can be collapsed or expanded. Each section displays
the duration.
In the following example:
- Three sections have been collapsed and can be expanded.
- Three sections are expanded and can be collapsed.
![Collapsible sections](img/collapsible_log_v13_10.png)
### Custom collapsible sections
You can create [collapsible sections in job logs](#expand-and-collapse-job-log-sections)
by manually outputting special codes
that GitLab uses to delimit collapsible sections:
- Section start marker: `\e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K` + `TEXT_OF_SECTION_HEADER`
- Section end marker: `\e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K`
You must add these codes to the script section of the CI configuration.
For example, using `echo`:
```yaml
job1:
script:
- echo -e "\e[0Ksection_start:`date +%s`:my_first_section\r\e[0KHeader of the 1st collapsible section"
- echo 'this line should be hidden when collapsed'
- echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"
```
The escape syntax may differ depending on the shell that your runner uses.
For example if it is using Zsh, you may need to escape the special characters
with `\\e` or `\\r`.
In the example above:
- `date +%s`: Command that produces the Unix timestamp (for example `1560896352`).
- `my_first_section`: The name given to the section. The name can only be composed
of letters, numbers, and the `_`, `.`, or `-` characters.
- `\r\e[0K`: Escape sequence that prevents the section markers from displaying in the
rendered (colored) job log. They are displayed when viewing the raw job log, accessed
in the upper-right corner of the job log by selecting **Show complete raw** (**{doc-text}**).
- `\r`: carriage return (returns the cursor to the start of the line).
- `\e[0K`: ANSI escape code to clear the line from the cursor position to the end of the line.
(`\e[K` alone does not work; the `0` must be included).
Sample raw job log:
```plaintext
\e[0Ksection_start:1560896352:my_first_section\r\e[0KHeader of the 1st collapsible section
this line should be hidden when collapsed
\e[0Ksection_end:1560896353:my_first_section\r\e[0K
```
Sample job console log:
![Custom collapsible sections](img/collapsible_job_v16_10.png)
#### Use a script to improve display of collapsible sections
To remove the `echo` statements that create the section markers from the job output,
you can move the job contents to a script file and invoke it from the job:
1. Create a script that can handle the section headers. For example:
```shell
# function for starting the section
function section_start () {
local section_title="${1}"
local section_description="${2:-$section_title}"
echo -e "section_start:`date +%s`:${section_title}[collapsed=true]\r\e[0K${section_description}"
}
# Function for ending the section
function section_end () {
local section_title="${1}"
echo -e "section_end:`date +%s`:${section_title}\r\e[0K"
}
# Create sections
section_start "my_first_section" "Header of the 1st collapsible section"
echo "this line should be hidden when collapsed"
section_end "my_first_section"
# Repeat as required
```
1. Add the script to the `.gitlab-ci.yml` file:
```yaml
job:
script:
- source script.sh
```
### Pre-collapse sections
You can make the job log automatically collapse collapsible sections by adding the `collapsed` option to the section start.
Add `[collapsed=true]` after the section name and before the `\r`. The section end marker
remains unchanged:
- Section start marker with `[collapsed=true]`: `\e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME[collapsed=true]\r\e[0K` + `TEXT_OF_SECTION_HEADER`
- Section end marker (unchanged): `\e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K`
Add the updated section start text to the CI configuration. For example,
using `echo`:
```yaml
job1:
script:
- echo -e "\e[0Ksection_start:`date +%s`:my_first_section[collapsed=true]\r\e[0KHeader of the 1st collapsible section"
- echo 'this line should be hidden automatically after loading the job log'
- echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"
```
## Delete job logs
When you delete a job log you also [erase the entire job](../../api/jobs.md#erase-a-job).
For more details, see [Delete job logs](../../user/storage_management_automation.md#delete-job-logs).
## Job log timestamps
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/455582) in GitLab 17.1 [with a flag](../../administration/feature_flags.md) named `parse_ci_job_timestamps`. Disabled by default.
> - Feature flag `parse_ci_job_timestamps` [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/464785) in GitLab 17.2.
You can generate a timestamp in the [ISO 8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
for each line in a CI/CD job log. With job log timestamps, you can identify the duration
of a specific section in the job. By default, job logs do not include a timestamp for each log line.
When timestamps are enabled, the job log uses approximately 10% more storage space.
Prerequisites:
- You must be on GitLab Runner 17.0 or later.
To enable timestamps in job logs, add a `FF_TIMESTAMPS` [CI/CD variable](../runners/configure_runners.md#configure-runner-behavior-with-variables)
to your pipeline and set it to `true`.
For example, [add the variable to your `.gitlab-ci.yml` file](../variables/index.md#define-a-cicd-variable-in-the-gitlab-ciyml-file):
```yaml
variables:
FF_TIMESTAMPS: true
job:
script:
- echo "This job's log has ISO 8601 timestamps!"
```
Here's an example log output with `FF_TIMESTAMPS` enabled:
![Timestamps for each log line](img/ci_log_timestamp_v17_1.png)
To provide feedback on this feature, leave a comment on [issue 463391](https://gitlab.com/gitlab-org/gitlab/-/issues/463391).
## Troubleshooting
### Job log slow to update
When you visit the job log page for a running job, there could be a delay of up to
60 seconds before a log update. The default refresh time is 60 seconds, but after
the log is viewed in the UI one time, log updates should occur every 3 seconds.

47
doc/ci/yaml/ci_job_log_timestamps.md
View File

@ -1,44 +1,13 @@
---
stage: Verify
group: Runner
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
redirect_to: '../jobs/job_logs.md#job_log_timestamps'
remove_date: '2025-01-24'
---
# CI/CD job log timestamps
<!-- markdownlint-disable -->
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
This document was moved to [another location](../jobs/job_logs.md#job-log-timestamps).
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/455582) in GitLab 17.1 [with a flag](../../administration/feature_flags.md) named `parse_ci_job_timestamps`. Disabled by default.
> - Feature flag `parse_ci_job_timestamps` [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/464785) in GitLab 17.2.
You can generate a timestamp in the [ISO 8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
for each line in a CI/CD job log. With job log timestamps, you can identify the duration
of a specific section in the job. By default, job logs do not include a timestamp for each log line.
When timestamps are enabled, the job log uses approximately 10% more storage space.
Prerequisites:
- You must be on GitLab Runner 17.0 or later.
To enable timestamps in job logs, add a `FF_TIMESTAMPS` [CI/CD variable](../runners/configure_runners.md#configure-runner-behavior-with-variables)
to your pipeline and set it to `true`.
For example, [add the variable to your `.gitlab-ci.yml` file](../variables/index.md#define-a-cicd-variable-in-the-gitlab-ciyml-file):
```yaml
variables:
FF_TIMESTAMPS: true
job:
script:
- echo "This job's log has ISO 8601 timestamps!"
```
Here's an example log output with `FF_TIMESTAMPS` enabled:
![Timestamps for each log line](img/ci_log_timestamp_v17_1.png)
To provide feedback on this feature, leave a comment on [issue 463391](https://gitlab.com/gitlab-org/gitlab/-/issues/463391).
<!-- This redirect file can be deleted after <2025-01-24>. -->
<!-- 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 -->

6
doc/ci/yaml/index.md
View File

@ -1128,7 +1128,7 @@ If a job times out, the `after_script` commands do not execute.
- You can [ignore non-zero exit codes](script.md#ignore-non-zero-exit-codes).
- [Use color codes with `after_script`](script.md#add-color-codes-to-script-output)
to make job logs easier to review.
- [Create custom collapsible sections](script.md#custom-collapsible-sections)
- [Create custom collapsible sections](../jobs/job_logs.md#custom-collapsible-sections)
to simplify job log output.
### `allow_failure`
@ -1643,7 +1643,7 @@ job:
- You can [ignore non-zero exit codes](script.md#ignore-non-zero-exit-codes).
- [Use color codes with `before_script`](script.md#add-color-codes-to-script-output)
to make job logs easier to review.
- [Create custom collapsible sections](script.md#custom-collapsible-sections)
- [Create custom collapsible sections](../jobs/job_logs.md#custom-collapsible-sections)
to simplify job log output.
### `cache`
@ -4761,7 +4761,7 @@ job2:
- You can [ignore non-zero exit codes](script.md#ignore-non-zero-exit-codes).
- [Use color codes with `script`](script.md#add-color-codes-to-script-output)
to make job logs easier to review.
- [Create custom collapsible sections](script.md#custom-collapsible-sections)
- [Create custom collapsible sections](../jobs/job_logs.md#custom-collapsible-sections)
to simplify job log output.
### `secrets`

125
doc/ci/yaml/script.md
View File

@ -14,7 +14,7 @@ You can use special syntax in [`script`](index.md#script) sections to:
- [Split long commands](#split-long-commands) into multiline commands.
- [Use color codes](#add-color-codes-to-script-output) to make job logs easier to review.
- [Create custom collapsible sections](#custom-collapsible-sections)
- [Create custom collapsible sections](../jobs/job_logs.md#custom-collapsible-sections)
to simplify job log output.
## Use special characters with `script`
@ -261,129 +261,6 @@ job:
- Write-Host "This text is not colored"
```
## Expand and collapse job log sections
> - Support for output of multi-line command bash shell output [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3486) in GitLab 16.5 behind the [GitLab Runner feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html), `FF_SCRIPT_SECTIONS`.
Job logs are divided into sections that can be collapsed or expanded. Each section displays
the duration.
In the following example:
- Three sections have been collapsed and can be expanded.
- Three sections are expanded and can be collapsed.
![Collapsible sections](img/collapsible_log_v13_10.png)
### Custom collapsible sections
You can create [collapsible sections in job logs](#expand-and-collapse-job-log-sections)
by manually outputting special codes
that GitLab uses to delimit collapsible sections:
- Section start marker: `\e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K` + `TEXT_OF_SECTION_HEADER`
- Section end marker: `\e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K`
You must add these codes to the script section of the CI configuration.
For example, using `echo`:
```yaml
job1:
script:
- echo -e "\e[0Ksection_start:`date +%s`:my_first_section\r\e[0KHeader of the 1st collapsible section"
- echo 'this line should be hidden when collapsed'
- echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"
```
The escape syntax may differ depending on the shell that your runner uses.
For example if it is using Zsh, you may need to escape the special characters
with `\\e` or `\\r`.
In the example above:
- `date +%s`: Command that produces the Unix timestamp (for example `1560896352`).
- `my_first_section`: The name given to the section. The name can only be composed
of letters, numbers, and the `_`, `.`, or `-` characters.
- `\r\e[0K`: Escape sequence that prevents the section markers from displaying in the
rendered (colored) job log. They are displayed when viewing the raw job log, accessed
in the upper-right corner of the job log by selecting **Show complete raw** (**{doc-text}**).
- `\r`: carriage return (returns the cursor to the start of the line).
- `\e[0K`: ANSI escape code to clear the line from the cursor position to the end of the line.
(`\e[K` alone does not work; the `0` must be included).
Sample raw job log:
```plaintext
\e[0Ksection_start:1560896352:my_first_section\r\e[0KHeader of the 1st collapsible section
this line should be hidden when collapsed
\e[0Ksection_end:1560896353:my_first_section\r\e[0K
```
Sample job console log:
![Custom collapsible sections](img/collapsible_job_v16_10.png)
#### Use a script to improve display of collapsible sections
To remove the `echo` statements that create the section markers from the job output,
you can move the job contents to a script file and invoke it from the job:
1. Create a script that can handle the section headers. For example:
```shell
# function for starting the section
function section_start () {
local section_title="${1}"
local section_description="${2:-$section_title}"
echo -e "section_start:`date +%s`:${section_title}[collapsed=true]\r\e[0K${section_description}"
}
# Function for ending the section
function section_end () {
local section_title="${1}"
echo -e "section_end:`date +%s`:${section_title}\r\e[0K"
}
# Create sections
section_start "my_first_section" "Header of the 1st collapsible section"
echo "this line should be hidden when collapsed"
section_end "my_first_section"
# Repeat as required
```
1. Add the script to the `.gitlab-ci.yml` file:
```yaml
job:
script:
- source script.sh
```
### Pre-collapse sections
You can make the job log automatically collapse collapsible sections by adding the `collapsed` option to the section start.
Add `[collapsed=true]` after the section name and before the `\r`. The section end marker
remains unchanged:
- Section start marker with `[collapsed=true]`: `\e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME[collapsed=true]\r\e[0K` + `TEXT_OF_SECTION_HEADER`
- Section end marker (unchanged): `\e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K`
Add the updated section start text to the CI configuration. For example,
using `echo`:
```yaml
job1:
script:
- echo -e "\e[0Ksection_start:`date +%s`:my_first_section[collapsed=true]\r\e[0KHeader of the 1st collapsible section"
- echo 'this line should be hidden automatically after loading the job log'
- echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"
```
## Troubleshooting
### `Syntax is incorrect` in scripts that use `:`

2
doc/security/responding_to_security_incidents.md
View File

@ -188,7 +188,7 @@ Before you ask GitLab for help, search the [GitLab documentation](https://docs.g
### Security best practices
Review the [GitLab Security documentation](../security/index.md) for what suggestions will work best for your environment and needs. If you are running a self-managed GitLab instance, consider reviewing our [diagram of GitLab components](../development/architecture.md#simplified-component-overview) to familiarise yourself with the various parts of a GitLab installation.
Review the [GitLab Security documentation](../security/index.md) for what suggestions will work best for your environment and needs. If you are running a self-managed GitLab instance, consider reviewing our [diagram of GitLab components](../development/architecture.md#simplified-component-overview) to familiarize yourself with the various parts of a GitLab installation.
#### Hardening Recommendations

2
doc/user/application_security/troubleshooting_application_security.md
View File

@ -198,7 +198,7 @@ Instructions are available in the [legacy template project](https://gitlab.com/g
In these circumstances, that the job succeeds is the default behavior. The job's status indicates
success or failure of the analyzer itself. Analyzer results are displayed in the
[job logs](../../ci/yaml/script.md#expand-and-collapse-job-log-sections),
[job logs](../../ci/jobs/job_logs.md#expand-and-collapse-job-log-sections),
[merge request widget](index.md#merge-request), or
[security dashboard](security_dashboard/index.md).

41
doc/user/project/badges.md
View File

@ -76,28 +76,41 @@ For example, you can use code similar to the following to add the test coverage
![coverage](https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?job=coverage)
```
### Test coverage report badge colors and limits
### Test coverage limits and badge colors
The default colors and limits for the badge are as follows:
The following table shows the default test coverage limits and badge colors:
- 95 up to and including 100% - good (`#4c1`)
- 90 up to 95% - acceptable (`#a3c51c`)
- 75 up to 90% - medium (`#dfb317`)
- 0 up to 75% - low (`#e05d44`)
- no coverage - unknown (`#9f9f9f`)
| Test coverage | Percentage limits | Badge color |
|---|---|---|
| Good | 95 up to and including 100% | <span style="color: #4c1">■</span> `#4c1` |
| Acceptable | 90 up to 95% | <span style="color:#a3c51c"> ■</span> `#a3c51c` |
| Medium | 75 up to 90% | <span style="color: #dfb317">■</span> `#dfb317` |
| Low | 0 up to 75% | <span style="color: #e05d44">■</span> `#e05d44` |
| Unknown | No coverage | <span style="color: #9f9f9f">■</span> `#9f9f9f` |
NOTE:
*Up to* means up to, but not including, the upper bound.
You can overwrite the limits by using the following additional parameters:
### Change the default limits
- `min_good` (default 95, can use any value between 3 and 100)
- `min_acceptable` (default 90, can use any value between 2 and min_good-1)
- `min_medium` (default 75, can use any value between 1 and min_acceptable-1)
You can override the default limits by passing the following query parameters in the coverage report badge URL:
If an invalid boundary is set, GitLab automatically adjusts it to be valid. For example,
if `min_good` is set `80`, and `min_acceptable` is set to `85` (too high), GitLab automatically
sets `min_acceptable` to `79` (`min_good` - `1`).
| Query parameter | Acceptable values | Default |
|---|---|---|
| `min_good` | Any value between 3 and 100 | 95 |
| `min_acceptable` | Any value between 2 and `min_good`−1 | 90 |
| `min_medium` | Any value between 1 and `min_acceptable`−1 | 75 |
For example:
```plaintext
https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?min_good=98&min_acceptable=75
```
If you set an invalid boundary, GitLab automatically adjusts it to be valid. For example,
if you set `min_good` to `80` and `min_acceptable` to `85`, GitLab sets `min_acceptable`
to `79` (`min_good - 1`) because the minimum acceptable value cannot be higher than
the minimum good value.
## Latest release badges

10
doc/user/project/working_with_projects.md
View File

@ -211,16 +211,16 @@ DETAILS:
> - Option to delete projects immediately from the **Admin** area and as a group setting removed [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
Prerequisites:
- You must have the Owner role for the project.
- The project must be [marked for deletion](#delete-a-project).
If you don't want to wait for delayed deletion, you can delete a project immediately. To do this, perform the steps for [deleting a projects](#delete-a-project) again.
In the first cycle of deleting a project, the project is moved to the delayed deletion queue and automatically deleted after the retention period has passed.
If during this delayed deletion time you run a second deletion cycle, the project is deleted immediately.
Prerequisites:
- You must have the Owner role for the project.
- The project must be [marked for deletion](#delete-a-project).
To immediately delete a project marked for deletion:
1. On the left sidebar, select **Search or go to** and find your project.

4
doc/user/public_access.md
View File

@ -41,7 +41,7 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
For internal projects, **any authenticated user**, including users with the Guest role, can:
For internal projects, any authenticated user, including users with the Guest role, can:
- Clone the project.
- View the public access directory (`/public`).
@ -54,7 +54,7 @@ Internal groups can have internal or private subgroups and projects.
## Public projects and groups
For public projects, **unauthenticated users**, including users with the Guest role, can:
For public projects, any user, including unauthenticated users, can:
- Clone the project.
- View the public access directory (`/public`).

12
lib/gitlab/ci/templates/Terraform/Module-Base.gitlab-ci.yml
View File

@ -18,13 +18,17 @@ variables:
.terraform-module:deploy:
stage: deploy
image: $CI_TEMPLATE_REGISTRY_HOST/gitlab-org/terraform-images/stable:latest
image: curlimages/curl:8.10.1
variables:
TAR_FILENAME: /tmp/${TERRAFORM_MODULE_NAME}-${TERRAFORM_MODULE_SYSTEM}-${TERRAFORM_MODULE_VERSION}.tgz
UPLOAD_URL: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/terraform/modules/${TERRAFORM_MODULE_NAME}/${TERRAFORM_MODULE_SYSTEM}/${TERRAFORM_MODULE_VERSION}/file'
script:
- TERRAFORM_MODULE_NAME=$(echo "${TERRAFORM_MODULE_NAME}" | tr " _" -) # module-name must not have spaces or underscores, so translate them to hyphens
# Builds the Terraform module artifact: a gzipped tar archive with the contents from `$TERRAFORM_MODULE_DIR` without a `.git` directory.
- tar -vczf /tmp/${TERRAFORM_MODULE_NAME}-${TERRAFORM_MODULE_SYSTEM}-${TERRAFORM_MODULE_VERSION}.tgz -C ${TERRAFORM_MODULE_DIR} --exclude=./.git .
- tar -vczf "${TAR_FILENAME}" -C "${TERRAFORM_MODULE_DIR}" --exclude=./.git .
# Uploads the Terraform module artifact to the GitLab Terraform Module Registry, see
# docs/user/packages/terraform_module_registry/index.html#publish-a-terraform-module
- 'curl --fail-with-body --location --header "JOB-TOKEN: ${CI_JOB_TOKEN}"
--upload-file /tmp/${TERRAFORM_MODULE_NAME}-${TERRAFORM_MODULE_SYSTEM}-${TERRAFORM_MODULE_VERSION}.tgz
${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/terraform/modules/${TERRAFORM_MODULE_NAME}/${TERRAFORM_MODULE_SYSTEM}/${TERRAFORM_MODULE_VERSION}/file'
--upload-file "$TAR_FILENAME"
--upload-file "${TAR_FILENAME}"
"${UPLOAD_URL}"'

11
locale/gitlab.pot
View File

@ -34775,7 +34775,7 @@ msgstr ""
msgid "MlModelRegistry|An error has occurred when saving the model."
msgstr ""
msgid "MlModelRegistry|Are you sure you want to delete model version %{versionName}?"
msgid "MlModelRegistry|Are you sure you want to delete this model version?"
msgstr ""
msgid "MlModelRegistry|Artifact file creation failed"
@ -34844,9 +34844,18 @@ msgstr ""
msgid "MlModelRegistry|Delete model version?"
msgstr ""
msgid "MlModelRegistry|Delete version"
msgstr ""
msgid "MlModelRegistry|Delete version %{versionName}"
msgstr ""
msgid "MlModelRegistry|Deleting this model version will delete the associated artifacts."
msgstr ""
msgid "MlModelRegistry|Deleting this version also deletes all of its imported or uploaded artifacts and its settings."
msgstr ""
msgid "MlModelRegistry|Description"
msgstr ""

21
spec/frontend/ml/model_registry/components/delete_model_version_disclosure_dropdown_item_spec.js
View File

@ -2,11 +2,14 @@ import { GlModal, GlDisclosureDropdownItem } from '@gitlab/ui';
import { shallowMountExtended } from 'helpers/vue_test_utils_helper';
import DeleteModelVersionDisclosureDropdownItem from '~/ml/model_registry/components/delete_model_version_disclosure_dropdown_item.vue';
const MODAL_BODY = 'Are you sure you want to delete model version foo?';
const MODAL_TITLE = 'Delete model version?';
const MODAL_BODY = 'Are you sure you want to delete this model version?';
const MODAL_NOTE =
'Deleting this version also deletes all of its imported or uploaded artifacts and its settings.';
const MODAL_NOTE_TITLE = 'Note:';
const MODAL_TITLE = 'Delete version 1.0.0';
const MODAL_CANCEL = 'Cancel';
const MENU_ITEM_TEXT = 'Delete model version';
const VERSION_NAME = 'foo';
const MENU_ITEM_TEXT = 'Delete version';
const VERSION_NAME = '1.0.0';
describe('DeleteModelVersionDisclosureDropdownItem', () => {
let wrapper;
@ -14,6 +17,8 @@ describe('DeleteModelVersionDisclosureDropdownItem', () => {
const findModal = () => wrapper.findComponent(GlModal);
const findDeleteButton = () => wrapper.findComponent(GlDisclosureDropdownItem);
const findModalText = () => wrapper.findByText(MODAL_BODY);
const findModalNote = () => wrapper.findByText(MODAL_NOTE);
const findModalNoteTitle = () => wrapper.findByText(MODAL_NOTE_TITLE);
beforeEach(() => {
wrapper = shallowMountExtended(DeleteModelVersionDisclosureDropdownItem, {
@ -54,6 +59,14 @@ describe('DeleteModelVersionDisclosureDropdownItem', () => {
expect(findModalText().exists()).toBe(true);
});
it('displays modal note', () => {
expect(findModalNote().exists()).toBe(true);
});
it('displays modal note title', () => {
expect(findModalNoteTitle().exists()).toBe(true);
});
it('emits delete-model-version event when primary action is clicked', () => {
findModal().vm.$emit('primary');