diff --git a/.gitlab/ci/database.gitlab-ci.yml b/.gitlab/ci/database.gitlab-ci.yml index 39065d1c9db..7806cc15b18 100644 --- a/.gitlab/ci/database.gitlab-ci.yml +++ b/.gitlab/ci/database.gitlab-ci.yml @@ -1,6 +1,21 @@ include: - local: .gitlab/ci/rails/shared.gitlab-ci.yml +db:setup pg14: + stage: prepare + needs: [] + extends: + - .use-pg14 + - .default-before_script + - .ruby-cache + - .rails:rules:setup-test-env + script: + - source scripts/utils.sh + - run_timed_command "pg_dumpall -h postgres -U postgres > pg_dumpall.sql" + artifacts: + paths: + - pg_dumpall.sql + db:rollback single-db-ci-connection: extends: - db:rollback diff --git a/.gitlab/ci/rails/shared.gitlab-ci.yml b/.gitlab/ci/rails/shared.gitlab-ci.yml index b7cb464675f..ddbbbac9b00 100644 --- a/.gitlab/ci/rails/shared.gitlab-ci.yml +++ b/.gitlab/ci/rails/shared.gitlab-ci.yml @@ -210,6 +210,10 @@ include: - !reference [.rspec-base, after_script] .rspec-base-pg14: + needs: + - !reference [.rspec-base, needs] + - job: "db:setup pg14" + optional: true extends: - .rspec-base - .use-pg14 diff --git a/app/assets/javascripts/vue_shared/new_namespace/components/welcome.vue b/app/assets/javascripts/vue_shared/new_namespace/components/welcome.vue index b961ae87e0c..031e1d8b8b4 100644 --- a/app/assets/javascripts/vue_shared/new_namespace/components/welcome.vue +++ b/app/assets/javascripts/vue_shared/new_namespace/components/welcome.vue @@ -38,7 +38,7 @@ export default {
-

+

{{ panel.title }}

diff --git a/doc/administration/self_hosted_models/configure_duo_features.md b/doc/administration/self_hosted_models/configure_duo_features.md index 1222ab30396..de83f1139d2 100644 --- a/doc/administration/self_hosted_models/configure_duo_features.md +++ b/doc/administration/self_hosted_models/configure_duo_features.md @@ -88,7 +88,6 @@ Prerequisites: To configure a self-hosted model: -1. On the left sidebar, at the bottom, select **Admin**. 1. On the left sidebar, at the bottom, select **Admin**. 1. Select **GitLab Duo**. 1. In the **GitLab Duo** section, select **Change configuration**. @@ -124,6 +123,7 @@ To configure a self-hosted model: Prerequisites: - You must be an administrator. +- You must have a Duo Enterprise license add-on. ### View configured features diff --git a/doc/administration/self_hosted_models/troubleshooting.md b/doc/administration/self_hosted_models/troubleshooting.md index 32020ead1ee..17718ed8a20 100644 --- a/doc/administration/self_hosted_models/troubleshooting.md +++ b/doc/administration/self_hosted_models/troubleshooting.md @@ -117,7 +117,7 @@ This missing configuration might be because of either of the following: To check if GitLab Duo was configured correctly: 1. On the left sidebar, at the bottom, select **Admin**. -1. Select **Settings > General**. +1. Select **Self-hosted models** 1. Expand **AI-powered features**. 1. Under **Features**, check that **Code Suggestions** and **Code generation** are set to **Self-hosted model**. diff --git a/doc/ci/runners/hosted_runners/index.md b/doc/ci/runners/hosted_runners/index.md new file mode 100644 index 00000000000..a2194e26a1c --- /dev/null +++ b/doc/ci/runners/hosted_runners/index.md @@ -0,0 +1,151 @@ +--- +stage: Verify +group: Hosted Runners +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 +--- + +# GitLab-hosted runners + +DETAILS: +**Tier:** Free, Premium, Ultimate +**Offering:** GitLab.com, GitLab Dedicated + +Use GitLab-hosted runners to run your CI/CD jobs on GitLab.com and GitLab Dedicated. +These runners can build, test, and deploy applications on different environments. + +To create and register your own runners, see [self-managed runners](https://docs.gitlab.com/runner/). + +## Hosted runners for GitLab.com + +DETAILS: +**Offering:** GitLab.com + +These runners are fully integrated with GitLab.com and are enabled by default for all projects, with no configuration required. +Your jobs can run on: + +- [Hosted runners on Linux](linux.md). +- [GPU-enabled hosted runners](gpu_enabled.md). +- [Hosted runners on Windows](windows.md) ([beta](../../../policy/development_stages_support.md#beta)). +- [Hosted runners on macOS](macos.md) ([beta](../../../policy/development_stages_support.md#beta)). + +### GitLab.com hosted runner workflow + +When you use hosted runners: + +- Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job. +- The virtual machine where your job runs has `sudo` access with no password. +- The storage is shared by the operating system, the container image with pre-installed software, and a copy of your cloned repository. + This means that the available free disk space for your jobs to use is reduced. +- [Untagged](../../yaml/index.md#tags) jobs run on the `small` Linux x86-64 runner. + +NOTE: +Jobs handled by hosted runners on GitLab.com time out after 3 hours, regardless of the timeout configured in a project. + +### Security of hosted runners for GitLab.com + +The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner build environment. + +Hosted runners for GitLab.com are configured as such: + +- Firewall rules only allow outbound communication from the ephemeral VM to the public internet. +- Inbound communication from the public internet to the ephemeral VM is not allowed. +- Firewall rules do not permit communication between VMs. +- The only internal communication allowed to the ephemeral VMs is from the runner manager. +- Ephemeral runner VMs serve a single job and are deleted right after the job execution. + +#### Architecture diagram of hosted runners for GitLab.com + +The following graphic shows the architecture diagram of hosted runners for GitLab.com + +![Hosted runners for GitLab.com architecture](../img/gitlab-hosted_runners_architecture_v17_0.png) + +For more information on how runners are authenticating and executing the job payload, see [Runner Execution Flow](https://docs.gitlab.com/runner#runner-execution-flow). + +#### Job isolation of hosted runners for GitLab.com + +In addition to isolating runners on the network, each ephemeral runner VM only serves a single job and is deleted straight after the job execution. +In the following example, three jobs are executed in a project's pipeline. Each of these jobs runs in a dedicated ephemeral VM. + +![Job isolation](../img/build_isolation_v17_9.png) + +The build job ran on `runner-ns46nmmj-project-43717858`, test job on `f131a6a2runner-new2m-od-project-43717858` and deploy job on `runner-tmand5m-project-43717858`. + +GitLab sends the command to remove the ephemeral runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext) +takes over the task of securely deleting the virtual machine and associated data. + +For more information about the security of hosted runners for GitLab.com, see: + +- [Google Cloud Infrastructure Security Design Overview whitepaper](https://cloud.google.com/docs/security/infrastructure/design/resources/google_infrastructure_whitepaper_fa.pdf) +- [GitLab Trust Center](https://about.gitlab.com/security/) +- [GitLab Security Compliance Controls](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/sec-controls/) + +### Caching on hosted runners for GitLab.com + +The hosted runners share a [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) +stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in the last 14 days are automatically +removed, based on the [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle). +The maximum size of an uploaded cache artifact can be 5 GB after the cache becomes a compressed archive. + +For more information about how caching works, see [Architecture diagram of hosted runners for GitLab.com](#architecture-diagram-of-hosted-runners-for-gitlabcom), and [Caching in GitLab CI/CD](../../caching/index.md). + +### Pricing of hosted runners for GitLab.com + +Jobs that run on hosted runners for GitLab.com consume [compute minutes](../../pipelines/compute_minutes.md) allocated to your namespace. +The number of minutes you can use on these runners depends on the included compute minutes in your [subscription plan](https://about.gitlab.com/pricing/) or [additionally purchased compute minutes](../../../subscriptions/gitlab_com/compute_minutes.md#purchase-additional-compute-minutes). + +For more information about the cost factor applied to the machine type based on size, see [cost factor](../../../ci/pipelines/compute_minutes.md#gitlab-hosted-runner-cost-factors). + +### SLO & Release cycle for hosted runners for GitLab.com + +Our SLO objective is to make 90% of CI/CD jobs start executing in 120 seconds or less. The error rate should be less than 0.5%. + +We aim to update to the latest version of [GitLab Runner](https://docs.gitlab.com/runner/#gitlab-runner-versions) within a week of its release. +You can find all GitLab Runner breaking changes under [Deprecations and removals](../../../update/deprecations.md). + +## Hosted runners for GitLab community contributions + +DETAILS: +**Offering:** GitLab.com + +If you want to [contribute to GitLab](https://about.gitlab.com/community/contribute/), jobs are picked up by the +`gitlab-shared-runners-manager-X.gitlab.com` fleet of runners, dedicated for GitLab projects and related community forks. + +These runners are backed by the same machine type as our `small` Linux x86-64 runners. +Unlike hosted runners for GitLab.com, hosted runners for GitLab community contributions are re-used up to 40 times. + +As we want to encourage people to contribute, these runners are free of charge. + +## Hosted runners for GitLab Dedicated + +DETAILS: +**Offering:** GitLab Dedicated + +Hosted runners for GitLab Dedicated are created on demand and are fully integrated with your GitLab Dedicated instance. +For more information, see [hosted runners for GitLab Dedicated](../../../administration/dedicated/hosted_runners.md). + +## Supported image lifecycle + +Hosted runners on macOS and Windows can only run jobs on supported images. You cannot bring your own image. +Supported images have the following lifecycle: + +### Beta + +New images are released as beta. This allows us to gather feedback and address potential issues before general availability. +Any jobs running on beta images are not covered by the service-level agreement. +If you use beta images, you can provide feedback by creating an issue. + +### General availability + +A image becomes generally available after it completes the beta phase and is considered stable. +To become generally available, the image must fulfill the following requirements: + +- Successful completion of a beta phase by resolving all reported significant bugs +- Compatibility of installed software with the underlying OS + +Jobs that run on generally available images are covered by the defined service-level agreement. + +### Deprecated + +A maximum of two generally available images are supported at a time. After a new generally available image is released, +the oldest generally available image becomes deprecated. A deprecated image is no longer updated and is deleted after 3 months +in accordance with the [deprecation guidelines](../../../development/deprecation_guidelines/index.md). diff --git a/doc/ci/runners/hosted_runners/macos.md b/doc/ci/runners/hosted_runners/macos.md index 3d881040710..9c1af9f9fd3 100644 --- a/doc/ci/runners/hosted_runners/macos.md +++ b/doc/ci/runners/hosted_runners/macos.md @@ -50,7 +50,7 @@ The images and installed components are updated with each GitLab release, to kee Major and minor releases of macOS and Xcode are made available in the milestone subsequent to the Apple release. A new major release image is initially made available as beta, and becomes generally available with the release of the first minor release. -Because only two generally available images are supported at a time, the oldest image becomes deprecated and will be removed after three months according to the [supported image lifecycle](../index.md#supported-image-lifecycle). +Because only two generally available images are supported at a time, the oldest image becomes deprecated and will be removed after three months according to the [supported image lifecycle](index.md#supported-image-lifecycle). When a new major release is generally available, it becomes the default image for all macOS jobs. diff --git a/doc/ci/runners/index.md b/doc/ci/runners/index.md index 9042813bfc1..78cb447b9bd 100644 --- a/doc/ci/runners/index.md +++ b/doc/ci/runners/index.md @@ -1,151 +1,95 @@ --- stage: Verify -group: Hosted Runners +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 --- -# GitLab-hosted runners +# Runners + +Runners are the agents that run the [GitLab Runner](https://docs.gitlab.com/runner/) application, to execute GitLab CI/CD jobs in a pipeline. +They are responsible for running your builds, tests, deployments, and other CI/CD tasks defined in `.gitlab-ci.yml` files. + +## Runner execution flow + +The following is a basic workflow of how runners work: + +1. A runner must first be [registered](https://docs.gitlab.com/runner/register/) with GitLab, + which establishes a persistent connection between the runner and GitLab. +1. When a pipeline is triggered, GitLab makes the jobs available to the registered runners. +1. Matching runners pick up jobs, one job per runner, and execute them. +1. Results are reported back to GitLab in real-time. + +For more information, see [Runner execution flow](https://docs.gitlab.com/runner/#runner-execution-flow). + +## Runner job scheduling and execution + +When a CI/CD job needs to be executed, GitLab creates a job based on the tasks defined in the `.gitlab-ci.yml` file. +The jobs are placed in a queue. GitLab checks for available runners that match: + +- Runner tags +- Runner types (like shared or group) +- Runner status and capacity +- Required capabilities + +The assigned runner receives the job details. The runner prepares the environment and runs the job's commands as specified in the `.gitlab-ci.yml` file. + +## Runner categories + +When deciding on which runners you want to execute your CI/CD jobs, you can choose: + +- [GitLab-hosted runners](index.md) for GitLab.com or GitLab Dedicated users. +- [Self-managed runners](https://docs.gitlab.com/runner/) for all GitLab installations. + +Runners can be group, project, or instance runners. GitLab-hosted runners are instance runners. + +### GitLab-hosted runners DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** GitLab.com, GitLab Dedicated -Use GitLab-hosted runners to run your CI/CD jobs on GitLab.com and GitLab Dedicated. -These runners can build, test, and deploy applications on different environments. +GitLab-hosted runners are: -To create and register your own runners, see [self-managed runners](https://docs.gitlab.com/runner/). +- Fully managed by GitLab. +- Available immediately without setup. +- Run on fresh VMs for each job. +- Include Linux, Windows, and macOS options. +- Automatically scaled based on demand. -## Hosted runners for GitLab.com +Choose GitLab-hosted runners when: + +- You want zero-maintenance CI/CD. +- You need quick setup without infrastructure management. +- Your jobs require isolation between runs. +- You're working with standard build environments. +- You're using GitLab.com or GitLab Dedicated. + +### Self-managed runners DETAILS: -**Offering:** GitLab.com +**Tier:** Free, Premium, Ultimate +**Offering:** GitLab.com, GitLab Self-Managed, GitLab Dedicated -These runners are fully integrated with GitLab.com and are enabled by default for all projects, with no configuration required. -Your jobs can run on: +Self-managed runners are: -- [Hosted runners on Linux](hosted_runners/linux.md) -- [GPU-enabled hosted runners](hosted_runners/gpu_enabled.md) -- [Hosted runners on Windows](hosted_runners/windows.md) ([beta](../../policy/development_stages_support.md#beta)) -- [Hosted runners on macOS](hosted_runners/macos.md) ([beta](../../policy/development_stages_support.md#beta)) +- Installed and managed by you. +- Run on your own infrastructure. +- Customizable to your needs. +- Support various executors (including Shell, Docker, and Kubernetes). +- Can be shared or set to specific projects or groups. -### How hosted runners for GitLab.com work +Choose self-managed runners when: -When you use hosted runners: +- You need custom configurations. +- You want to run jobs in your private network. +- You require specific security controls. +- You require project or group runners. +- You need to optimize for speed with runner reuse. +- You want to manage your own infrastructure. -- Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job. -- The virtual machine where your job runs has `sudo` access with no password. -- The storage is shared by the operating system, the image with pre-installed software, and a copy of your cloned repository. - This means that the available free disk space for your jobs to use is reduced. -- [Untagged](../yaml/index.md#tags) jobs run on the `small` Linux x86-64 runner. +## Related topics -NOTE: -Jobs handled by hosted runners on GitLab.com **time out after 3 hours**, regardless of the timeout configured in a project. - -### Security of hosted runners for GitLab.com - -The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner build environment. - -Hosted runners for GitLab.com are configured as such: - -- Firewall rules only allow outbound communication from the ephemeral VM to the public internet. -- Inbound communication from the public internet to the ephemeral VM is not allowed. -- Firewall rules do not permit communication between VMs. -- The only internal communication allowed to the ephemeral VMs is from the runner manager. -- Ephemeral runner VMs serve a single job and are deleted right after the job execution. - -#### Architecture diagram of hosted runners for GitLab.com - -The following graphic shows the architecture diagram of hosted runners for GitLab.com - -![Hosted runners for GitLab.com architecture](img/gitlab-hosted_runners_architecture_v17_0.png) - -For more information on how runners are authenticating and executing the job payload, see [Runner Execution Flow](https://docs.gitlab.com/runner#runner-execution-flow). - -#### Job isolation of hosted runners for GitLab.com - -In addition to isolating runners on the network, each ephemeral runner VM only serves a single job and is deleted straight after the job execution. -In the following example, three jobs are executed in a project's pipeline. Each of these jobs runs in a dedicated ephemeral VM. - -![Job isolation](img/build_isolation_v17_9.png) - -The build job ran on `runner-ns46nmmj-project-43717858`, test job on `f131a6a2runner-new2m-od-project-43717858` and deploy job on `runner-tmand5m-project-43717858`. - -GitLab sends the command to remove the ephemeral runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext) -takes over the task of securely deleting the virtual machine and associated data. - -For more information about the security of hosted runners for GitLab.com, see: - -- [Google Cloud Infrastructure Security Design Overview whitepaper](https://cloud.google.com/docs/security/infrastructure/design/resources/google_infrastructure_whitepaper_fa.pdf) -- [GitLab Trust Center](https://about.gitlab.com/security/) -- [GitLab Security Compliance Controls](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/sec-controls/) - -### Caching on hosted runners for GitLab.com - -The hosted runners share a [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) -stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in the last 14 days are automatically -removed, based on the [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle). -The maximum size of an uploaded cache artifact can be 5 GB after the cache becomes a compressed archive. - -For more information about how caching works, see [Architecture diagram of hosted runners for GitLab.com](#architecture-diagram-of-hosted-runners-for-gitlabcom), and [Caching in GitLab CI/CD](../caching/index.md). - -### Pricing of hosted runners for GitLab.com - -Jobs that run on hosted runners for GitLab.com consume [compute minutes](../pipelines/compute_minutes.md) allocated to your namespace. -The number of minutes you can use on these runners depends on the included compute minutes in your [subscription plan](https://about.gitlab.com/pricing/) or [additionally purchased compute minutes](../../subscriptions/gitlab_com/compute_minutes.md#purchase-additional-compute-minutes). - -For more information about the cost factor applied to the machine type based on size, see [cost factor](../../ci/pipelines/compute_minutes.md#gitlab-hosted-runner-cost-factors). - -### SLO & Release cycle for hosted runners for GitLab.com - -Our SLO objective is to make 90% of CI/CD jobs start executing in 120 seconds or less. The error rate should be less than 0.5%. - -We aim to update to the latest version of [GitLab Runner](https://docs.gitlab.com/runner/#gitlab-runner-versions) within a week of its release. -You can find all GitLab Runner breaking changes under [Deprecations and removals](../../update/deprecations.md). - -## Hosted runners for GitLab community contributions - -DETAILS: -**Offering:** GitLab.com - -If you want to [contribute to GitLab](https://about.gitlab.com/community/contribute/), jobs are picked up by the -`gitlab-shared-runners-manager-X.gitlab.com` fleet of runners, dedicated for GitLab projects and related community forks. - -These runners are backed by the same machine type as our `small` Linux x86-64 runners. -Unlike hosted runners for GitLab.com, hosted runners for GitLab community contributions are re-used up to 40 times. - -As we want to encourage people to contribute, these runners are free of charge. - -## Hosted runners for GitLab Dedicated - -DETAILS: -**Offering:** GitLab Dedicated - -Hosted runners for GitLab Dedicated are created on demand and are fully integrated with your GitLab Dedicated instance. -For more information, see [hosted runners for GitLab Dedicated](../../administration/dedicated/hosted_runners.md). - -## Supported image lifecycle - -Hosted runners on macOS and Windows can only run jobs on supported images. You cannot bring your own image. -Supported images have the following lifecycle: - -### Beta - -New images are released as beta. This allows us to gather feedback and address potential issues before general availability. -Any jobs running on beta images are not covered by the service-level agreement. -If you use beta images, you can provide feedback by creating an issue. - -### General availability - -A image becomes generally available after it completes the beta phase and is considered stable. -To become generally available, the image must fulfill the following requirements: - -- Successful completion of a beta phase by resolving all reported significant bugs -- Compatibility of installed software with the underlying OS - -Jobs that run on generally available images are covered by the defined service-level agreement. - -### Deprecated - -A maximum of two generally available images are supported at a time. After a new generally available image is released, -the oldest generally available image becomes deprecated. A deprecated image is no longer updated and is deleted after 3 months -in accordance with the [deprecation guidelines](../../development/deprecation_guidelines/index.md). +- [Install GitLab Runner](https://docs.gitlab.com/runner/install/) +- [Configure GitLab Runner](https://docs.gitlab.com/runner/configuration/) +- [Administer GitLab Runner](https://docs.gitlab.com/runner/) +- [Hosted runners for GitLab Dedicated](../../administration/dedicated/hosted_runners.md) diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md index 46263a0edff..528da530eb6 100644 --- a/doc/ci/yaml/index.md +++ b/doc/ci/yaml/index.md @@ -5290,8 +5290,13 @@ In this example, only runners with *both* the `ruby` and `postgres` tags can run **Related topics**: -- [Use tags to control which jobs a runner can run](../runners/configure_runners.md#control-jobs-that-a-runner-can-run). -- [Select different runner tags for each parallel matrix job](../jobs/job_control.md#select-different-runner-tags-for-each-parallel-matrix-job). +- [Use tags to control which jobs a runner can run](../runners/configure_runners.md#control-jobs-that-a-runner-can-run) +- [Select different runner tags for each parallel matrix job](../jobs/job_control.md#select-different-runner-tags-for-each-parallel-matrix-job) +- Runner tags for hosted runners: + - [Hosted runners on Linux](../../ci/runners/hosted_runners/linux.md) + - [GPU-enabled hosted runners](../../ci/runners/hosted_runners/gpu_enabled.md) + - [Hosted runners on macOS](../../ci/runners/hosted_runners/macos.md) + - [Hosted runners on Windows](../../ci/runners/hosted_runners/windows.md) ### `timeout` diff --git a/package.json b/package.json index 6b86b55a8d1..f51bab0566e 100644 --- a/package.json +++ b/package.json @@ -65,7 +65,7 @@ "@gitlab/ui": "107.0.1", "@gitlab/vue-router-vue3": "npm:vue-router@4.1.6", "@gitlab/vuex-vue3": "npm:vuex@4.0.0", - "@gitlab/web-ide": "^0.0.1-dev-20250110172049", + "@gitlab/web-ide": "^0.0.1-dev-20250128095641", "@gleam-lang/highlight.js-gleam": "^1.5.0", "@mattiasbuelens/web-streams-adapter": "^0.1.0", "@rails/actioncable": "7.0.807", diff --git a/scripts/utils.sh b/scripts/utils.sh index e93fdb96b4d..d8b2ff466dd 100644 --- a/scripts/utils.sh +++ b/scripts/utils.sh @@ -198,6 +198,16 @@ function setup_db_praefect() { function setup_db() { section_start "setup-db" "Setting up DBs" + if [ -f pg_dumpall.sql ]; then + echo "Found pg_dumpall.sql, applying!" + + psql -h postgres -U postgres -q < pg_dumpall.sql > /dev/null + rm pg_dumpall.sql + + section_end "setup-db" + return 0 + fi + setup_db_user_only run_timed_command_with_metric "bundle exec rake db:drop db:create db:schema:load db:migrate gitlab:db:lock_writes" "setup_db" setup_db_praefect diff --git a/spec/tooling/lib/tooling/gettext_extractor_spec.rb b/spec/tooling/lib/tooling/gettext_extractor_spec.rb index 9dec25c52bf..9cc51dc5cb5 100644 --- a/spec/tooling/lib/tooling/gettext_extractor_spec.rb +++ b/spec/tooling/lib/tooling/gettext_extractor_spec.rb @@ -6,7 +6,7 @@ require 'gitlab/rspec/all' require_relative '../../../../tooling/lib/tooling/gettext_extractor' require_relative '../../../support/tmpdir' -RSpec.describe Tooling::GettextExtractor, feature_category: :tooling do +RSpec.describe Tooling::GettextExtractor, feature_category: :tooling, quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/486873' do include StubENV include TmpdirHelper diff --git a/yarn.lock b/yarn.lock index 7cf0bcbdda7..cd0ed44ba10 100644 --- a/yarn.lock +++ b/yarn.lock @@ -1462,10 +1462,10 @@ resolved "https://registry.yarnpkg.com/vuex/-/vuex-4.0.0.tgz#ac877aa76a9c45368c979471e461b520d38e6cf5" integrity sha512-56VPujlHscP5q/e7Jlpqc40sja4vOhC4uJD1llBCWolVI8ND4+VzisDVkUMl+z5y0MpIImW6HjhNc+ZvuizgOw== -"@gitlab/web-ide@^0.0.1-dev-20250110172049": - version "0.0.1-dev-20250110172049" - resolved "https://registry.yarnpkg.com/@gitlab/web-ide/-/web-ide-0.0.1-dev-20250110172049.tgz#c10d85535f272039613866082d9aa6a9068f63b1" - integrity sha512-3duzCxQGRqSoPnOMG8dtepIxHlE2KvysSVrOGDMijajDpi6N68loFaUSM2E/shy+NtSPKQgltYiG1JXPxZlWaw== +"@gitlab/web-ide@^0.0.1-dev-20250128095641": + version "0.0.1-dev-20250128095641" + resolved "https://registry.yarnpkg.com/@gitlab/web-ide/-/web-ide-0.0.1-dev-20250128095641.tgz#06279d78773d65c72e046ba95168f0506bd7798b" + integrity sha512-cHEya9pENuypJ1LXW5oWk2Jivx/WEsybylIT4l/kPSFPJ25/mjHeUSTRGUragrnlH+ElgYEyvxElBaSMDMAG9g== "@gleam-lang/highlight.js-gleam@^1.5.0": version "1.5.0"