https://docs.gitlab.com/ee/update/deprecations.html Receive notifications of upcoming changes to GitLab that may affect your team's workflow. https://gitlab.com/gitlab-org/gitlab/-/work_items/585839 AWS ElastiCache documentation. - **GCP Memorystore**: Upgrade your Redis 6 instance to Redis 7.2 or Valkey 7.2. For available upgrade paths, see GCP Memorystore documentation. - **Azure Cache for Redis**: A managed Redis 7.2 or Valkey 7.2 option is not currently available on Azure. You can self-host Redis 7.2 or Valkey 7.2 on Azure VMs or AKS. You can also use the GitLab Linux package installation method, which will support Valkey 7.2 with general availability planned for GitLab 19.0. - **Self-hosted**: Upgrade your Redis 6 instance to Redis 7.2 or Valkey 7.2. For more information, see the requirements documentation. ]]> Wed, 11 Mar 2026 10:35:29 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/583544 maintenance term for Elasticsearch 7.x ended on 2026-01-15. For GitLab Self-Managed, administrators must upgrade their Elasticsearch instance to use advanced search. ]]> Tue, 10 Mar 2026 08:56:29 +0100 https://gitlab.com/groups/gitlab-org/-/work_items/12339 Thu, 19 Feb 2026 10:51:59 -0500 https://gitlab.com/groups/gitlab-org/-/work_items/12339 Thu, 19 Feb 2026 10:51:59 -0500 https://gitlab.com/gitlab-org/gitlab/-/work_items/590799 external Ingress controller and class. ]]> Fri, 13 Feb 2026 13:11:57 +0200 https://gitlab.com/gitlab-org/gitlab/-/work_items/590800 Fri, 13 Feb 2026 13:11:57 +0200 https://gitlab.com/gitlab-org/gitlab/-/issues/589774 annual upgrade cadence for PostgreSQL. Support for PostgreSQL 16 is scheduled for removal in GitLab 19.0. In GitLab 19.0, PostgreSQL 17 becomes the minimum required PostgreSQL version. PostgreSQL 17 is available as of GitLab 18.9, and you can upgrade at any time before the removal of PostgreSQL 16 in GitLab 19.0. If you are running a single PostgreSQL instance you installed by using the Linux package, an automatic upgrade may be attempted with 18.11. Make sure you have enough disk space to accommodate the upgrade. For more information, see Upgrade packaged PostgreSQL server. ]]> Fri, 13 Feb 2026 12:05:23 +1000 https://gitlab.com/gitlab-org/gitlab/-/work_items/590796 Spamcheck from the Linux package and GitLab Helm chart. Spamcheck is a service to combat spam on public-facing GitLab instances. By its nature, this feature is primarily relevant to large public instances, which represents an edge case in our customer base. Given the low adoption and the availability of standalone deployment options, we are removing Spamcheck from the Linux package and GitLab Helm chart. Customers not using Spamcheck will not be impacted by this change. The removal will reduce package size and dependency footprint (and thus security) for the majority of customers. If you currently use the bundled Spamcheck, you can deploy it separately by using Docker. No data migration is required. Configuration guidance is available in the linked documentation. ]]> Fri, 13 Feb 2026 11:46:13 +1000 https://gitlab.com/gitlab-org/gitlab/-/work_items/590797 migration guide. The Redis and PostgreSQL provided by the Linux package are not impacted by this change. ]]> Fri, 13 Feb 2026 10:56:09 +1000 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8915 ended in May 2025. In accordance with our Linux package supported platforms policy, we drop package builds once a vendor stops supporting the operating system. From GitLab 19.0, we will no longer provide packages for the Ubuntu 20.04 distribution for Linux package installs. GitLab 18.11 will be the last GitLab version with Linux packages for Ubuntu 20.04. If you currently run GitLab on Ubuntu 20.04, you must upgrade to Ubuntu 22.04 or another supported operating system before upgrading to GitLab 19.0. Canonical provides an upgrade guide to help you migrate. ]]> Fri, 13 Feb 2026 10:11:30 +1000 https://gitlab.com/gitlab-org/gitlab/-/work_items/590802 Linux package supported platforms policy, we drop package builds once a vendor stops supporting the operating system, with at least a six-month announcement period. If you currently run GitLab on Amazon Linux 2, you must migrate to Amazon Linux 2023 (AL2023) or another supported operating system before upgrading to GitLab 19.1. Amazon provides migration documentation to help you move from AL2 to AL2023. ]]> Fri, 13 Feb 2026 10:07:01 +1000 https://gitlab.com/gitlab-org/gitlab/-/work_items/590801 Docker deployment of GitLab on your existing distribution. This avoids having to migrate to a different Linux distribution to continue to receive GitLab upgrades. ]]> Fri, 13 Feb 2026 09:32:42 +1000 https://gitlab.com/gitlab-org/gitlab/-/work_items/590798 Mattermost has deprecated GitLab SSO from their free offering. Given this change, the maturity of Mattermost standalone deployment options, and the low adoption in our customer base, we are removing Mattermost from the Linux package. If you currently use Mattermost bundled with GitLab, refer to Migrating from GitLab Omnibus to Mattermost Standalone in the Mattermost documentation for migration instructions and available Mattermost editions. ]]> Fri, 13 Feb 2026 09:26:29 +1000 https://gitlab.com/gitlab-org/gitlab/-/work_items/588961 announced that this authentication method will stop working on 2026-06-09. From GitLab 19.0, if you want to import repositories from Bitbucket Cloud through the GitLab API, you must use user API tokens instead. Users importing repositories from Bitbucket Server, or from Bitbucket Cloud through the GitLab UI, are unaffected. ]]> Tue, 10 Feb 2026 09:13:13 +0000 https://gitlab.com/gitlab-org/gitlab/-/work_items/585176 Fri, 9 Jan 2026 12:07:50 +0800 https://gitlab.com/groups/gitlab-org/-/work_items/18493 **Projects** and its associated GraphQL arguments are deprecated in GitLab 18.8 and will be removed in GitLab 19.0. In the month before the GitLab 19.0 release, the ***Trending** tab redirects to the **Active** tab sorted by stars in descending order on GitLab.com. **What's being removed** - The **Trending** tab on the **Explore** > **Projects** page - The trending argument in the following GraphQL types: - `Query.adminProjects` - `Query.projects` - `Organization.projects` **Why we're making this change** The trending algorithm only considers public projects, making it ineffective for GitLab Self-Managed instances that primarily use internal or private visibility. The algorithm's limitations and lack of search capability have led to explicit removal requests from Self-Managed users. Rather than investing in significant improvements, we're focusing resources on enhancing existing discovery mechanisms. **Action required** UI users: The **Trending** tab will be inaccessible during the next breaking change window before full removal in 19.0. We recommend using the **Active** tab to view recently updated or most starred projects. ]]> Thu, 18 Dec 2025 11:22:50 -0500 https://gitlab.com/gitlab-org/gitlab/-/work_items/569345 Slack slash commands integration is deprecated in favor of the GitLab for Slack app, which provides a more secure integration method with the same capabilities. From GitLab 19.0, users will no longer be able to configure or use the Slack slash commands integration. This integration is only available on GitLab Self-Managed and GitLab Dedicated instances. If you're on GitLab.com, you don't need to do anything. If you're on GitLab Self-Managed or GitLab Dedicated, to find out if you're impacted, see issue 569345. ]]> Tue, 9 Dec 2025 14:07:16 +1000 https://gitlab.com/groups/gitlab-org/-/work_items/20375 Mon, 17 Nov 2025 08:27:12 +0000 https://gitlab.com/gitlab-org/charts/gitlab/-/issues/6089 supported GitLab reference architecture. If you are on a reference architecture or deployed an external PostgreSQL and Redis with another vendor's packages or images, you are **not impacted** by this change. As a temporary solution, GitLab has migrated the chart configuration to the Bitnami legacy repository. However, unpatched GitLab chart environments (GitLab 17.11, GitLab 18.0.5. GitLab 18.1.4, and GitLab 18.2.1 or earlier) will continue to pull images from the deprecated Bitnami repository, which will cause deployment failures after September 29th and may cause deployment failures during the brownout phase. If you're running an affected GitLab chart configuration, you must do one of the following: - Migrate to a supported GitLab reference architecture. - Upgrade to a patched chart version. - Configure the legacy repository in your chart values. For an example, see merge request 4421. Looking ahead, we will assess alternatives to replace or potentially remove Bitnami components from the GitLab chart entirely. For more information, see the official Bitnami announcement. ]]> Mon, 8 Sep 2025 09:47:04 +1000 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/9181 Fri, 11 Jul 2025 09:14:25 +0530 https://gitlab.com/groups/gitlab-org/-/epics/12774 custom compliance frameworks. - In GitLab 18.2, we released the new dynamic compliance violations report. These features give all of the same functionality as the static violations report, but you can configure the violations that you require. In GitLab 18.8, we'll replace the static compliance violations report with the dynamic report using compliance frameworks for more accurate reporting on requirements and controls. ]]> Tue, 8 Jul 2025 12:23:45 +1200 https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5928 Release Notes 1.12 - 1.16 - Release Notes 1.17 ]]> Thu, 8 May 2025 08:42:45 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/472213 scan execution policies are limited to 10 `scan` actions per policy. You can't create new policies that exceed the limit, and you can't update existing policies if they exceed the limit. For any existing policy that exceeds the limit, only the policy's first 10 `scan` actions are run. On GitLab Self-Managed and GitLab Dedicated instances, you can configure a custom limit with the `scan_execution_policies_action_limit` application setting. Limits for these instances default to zero actions. We recommend configuring a limit of 10 actions. ]]> Thu, 24 Apr 2025 21:46:21 -0400 https://gitlab.com/gitlab-org/gitlab/-/issues/457353 required client authentication for ROPC on GitLab.com since April 8, 2025 for security reasons. Fully removing ROPC support keeps security in line with the OAuth RFC version 2.1. ]]> Wed, 23 Apr 2025 17:07:48 -0400 https://gitlab.com/gitlab-org/gitlab/-/issues/535298 on our blog. ]]> Mon, 14 Apr 2025 17:51:39 -0400 https://gitlab.com/gitlab-org/gitlab/-/issues/573447 custom stages in pipeline execution policies (available in GitLab 17.9), we've introduced the configuration option `inject_policy` to replace the deprecated `inject_ci`. This new strategy allows for a graceful rollout of the custom stages functionality for users with existing pipeline execution policies that use the `inject_ci` strategy. To prepare for the pending removal, update all pipeline execution policies that use `inject_ci` to use `inject_policy` instead. ]]> Wed, 2 Apr 2025 14:38:39 -0400 https://gitlab.com/gitlab-org/gitlab/-/issues/420865 Thu, 6 Mar 2025 08:33:17 +0100 https://gitlab.com/gitlab-org/gitlab/-/issues/521663 annual upgrade cadence for PostgreSQL. Support for PostgreSQL 14 and 15 is scheduled for removal in GitLab 18.0. In GitLab 18.0, PostgreSQL 16 becomes the minimum required PostgreSQL version. PostgreSQL 14 and 15 will be supported for the full GitLab 17 release cycle. PostgreSQL 16 will also be supported for instances that want to upgrade prior to GitLab 18.0. If you are running a single PostgreSQL instance you installed by using an Omnibus Linux package, an automatic upgrade may be attempted with 17.11. Make sure you have enough disk space to accommodate the upgrade. For more information, see the Omnibus database documentation. ]]> Wed, 5 Mar 2025 10:06:03 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/517841 GitLab Advanced SAST. ]]> Wed, 26 Feb 2025 17:27:46 +0000 https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/630 its project-specific registry to the Cloud Native GitLab (CNG) registry. From GitLab 18.0 onward, `agentk` images built in CNG will mirror into the project-specific registry. The new image is equivalent to the old image, except the new image only supports `amd64` and `arm64` architectures. It does not support the 32-bit `arm` architecture. From GitLab 19.0 onward, the project-specific registry will not receive `agentk` updates. If you mirror the `agentk` container to a local registry, you should change your mirror source to the CNG registry. If you use the official GitLab Agent Helm chart, the new `agentk` image will start deploying from the new location seamlessly in GitLab 18.0. ]]> Mon, 17 Feb 2025 15:21:41 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/517254 Fri, 14 Feb 2025 20:41:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/509578 use the legacy format for your CI/CD tokens until the GitLab 20.0 release. Known issues: 1. GitLab Runner's AWS Fargate Drive 0.5.0 and earlier is incompatible with the JWT standard. Jobs will fail with a `file name too long` error. Users of the AWS Fargate custom executor driver must upgrade to 0.5.1 or later. For migration instructions, see the documentation. 1. The much longer JWT standard breaks the `echo $CI_JOB_TOKEN | base64` command used in some CI/CD configuration files. You can use the `echo $CI_JOB_TOKEN | base64 -w0` command instead. ]]> Fri, 14 Feb 2025 18:48:53 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/516107 `allowed_pull_policies` configuration specified in the runner's `config.toml` file. If they are not, the job should fail with an `incompatible pull policy` error. In the current implementation, when multiple pull policies are defined, jobs pass if at least one pull policy matches those in `allowed-pull-policies`, even if other policies are not included. In GitLab 18.0, jobs will fail only if none of the pull policies match those in `allowed-pull-policies`. However, unlike the current behavior, jobs will use only the pull policies listed in `allowed-pull-policies`. This distinction can cause jobs that currently pass to fail in GitLab 18.0. ]]> Fri, 14 Feb 2025 04:29:36 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/519113 install the `arm64` Debian packages. For information on backing up data on a 32-bit OS and restoring it to a 64-bit OS, see Upgrading operating systems for PostgreSQL. ]]> Thu, 13 Feb 2025 23:46:20 +0000 https://gitlab.com/groups/gitlab-org/-/epics/16629 Thu, 13 Feb 2025 17:54:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/501308 dependency scanning using SBOM feature and the new dependency scanning analyzer that focuses on detecting dependencies and their relationships (dependency graph) and relies on GitLab's built-in SBOM vulnerability scanner, which is already employed by continuous vulnerability scanning, to identify their vulnerabilities. As of GitLab 18.5, this new feature is in Limited Availability. Until the majority of users have migrated to the new dependency scanning feature, GitLab will continue to support the Gemnasium analyzer. Only then, the Gemnasium analyzer will reach end of support. Due to the significant changes and feature removals this upgrade introduces, it will not be implemented automatically. Existing CI/CD jobs using the Gemnasium analyzer will continue to function by default to prevent disruption to CI/CD configurations. Please review the fully detailed changes below and consult the migration guide to assist you with the transition. - To prevent disruptions to your CI/CD configuration, when your application uses the stable dependency scanning CI/CD template (`Dependency-Scanning.gitlab-ci.yml`), dependency scanning uses only the existing CI/CD jobs based on the Gemnasium analyzer. - When your application uses the latest dependency scanning CI/CD template (`Dependency-Scanning.latest.gitlab-ci.yml`), dependency scanning uses the existing CI/CD jobs based on the Gemnasium analyzer and the new dependency scanning analyzer also runs on the supported file types. You can also opt-in to enforce the new dependency scanning analyzer for all projects. - Other migration paths might be considered as the feature gains maturity. - The Gemnasium analyzer project is deprecated, as well as the corresponding container images (all tags and variants): `gemnasium`, `gemnasium-maven`, `gemnasium-python`. These images will not be removed from the GitLab container registry. - The following CI/CD variables associated with the Gemnasium analyzer are also deprecated. While these variables will continue to work when using the Gemnasium analyzer, they will not be effective after migrating to the new dependency scanning analyzer. If a variable is also used in another context, the deprecation only applies to the dependency scanning feature (for example, `GOOS` and `GOARCH` are not specific to the dependency scanning feature). `DS_EXCLUDED_ANALYZERS`, `DS_GRADLE_RESOLUTION_POLICY`, `DS_IMAGE_SUFFIX`, `DS_JAVA_VERSION`, `DS_PIP_DEPENDENCY_PATH`, `DS_PIP_VERSION`, `DS_REMEDIATE_TIMEOUT`, `DS_REMEDIATE`, `GEMNASIUM_DB_LOCAL_PATH`, `GEMNASIUM_DB_REF_NAME`, `GEMNASIUM_DB_REMOTE_URL`, `GEMNASIUM_DB_UPDATE_DISABLED`, `GEMNASIUM_LIBRARY_SCAN_ENABLED`, `GOARCH`, `GOFLAGS`, `GOOS`, `GOPRIVATE`, `GRADLE_CLI_OPTS`, `GRADLE_PLUGIN_INIT_PATH`, `MAVEN_CLI_OPTS`, `PIP_EXTRA_INDEX_URL`, `PIP_INDEX_URL`, `PIPENV_PYPI_MIRROR`, `SBT_CLI_OPTS`. - The following CI/CD components are deprecated: Android, Rust, Swift, CocoaPods. These are replaced by the main dependency scanning CI/CD component that covers all supported languages and package managers. - The Resolve a vulnerability feature **for Yarn projects** is deprecated in GitLab 17.9. While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new dependency scanning analyzer. See the corresponding deprecation announcement for more details. - The dependency scanning for JavaScript vendored libraries feature is deprecated in GitLab 17.9. While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new dependency scanning analyzer. See the corresponding deprecation announcement for more details. ]]> Wed, 12 Feb 2025 23:32:46 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/501308 Resolve a vulnerability feature for Yarn projects provided by the Gemnasium analyzer for dependency scanning is deprecated in GitLab 17.9. While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new dependency scanning analyzer. See details in the migration guide A replacement feature is planned as part of the Auto Remediation vision but no timeline has been set for its delivery. ]]> Wed, 12 Feb 2025 23:32:46 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/501308 dependency scanning for JavaScript vendored libraries feature provided by the Gemnasium analyzer for dependency scanning is deprecated in GitLab 17.9. While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new dependency scanning analyzer. See details in the migration guide A replacement feature will be developed with dependency scanning on vendored libraries but no timeline has been set for its delivery. ]]> Wed, 12 Feb 2025 23:32:46 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/519133 reached End of Support in 15.4 - `brakeman-sast`, which reached End of Support in 17.0 - `eslint-sast`, which reached End of Support in 15.4 - `flawfinder-sast`, which reached End of Support in 17.0 - `gosec-sast`, which reached End of Support in 15.4 - `mobsf-android-sast`, which reached End of Support in 17.0 - `mobsf-ios-sast`, which reached End of Support in 17.0 - `nodejs-scan-sast`, which reached End of Support in 17.0 - `phpcs-security-audit-sast`, which reached End of Support in 17.0 - `security-code-scan-sast`, which reached End of Support in 16.0 At the time when each analyzer reached End of Support, we updated its job `rules` to cause it not to run by default and stopped releasing updates. However, you might have customized the template to continue to use these jobs or depend on them existing in your pipelines. If you have any customization that depends on the jobs above, perform the actions required before upgrading to 18.0 to avoid disruptions to your CI/CD pipelines. ]]> Wed, 12 Feb 2025 02:52:57 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/515487 merge request (MR) pipelines by default when an MR is open. Starting in GitLab 18.0, we'll align this template's behavior with the behavior of the Stable template editions for other AST scanners: - By default, the template will run scan jobs in branch pipelines. - You'll be able to set the CI/CD variable `AST_ENABLE_MR_PIPELINES: true` to use MR pipelines instead when an MR is open. The implementation of this new variable is tracked in issue 410880. ]]> Wed, 12 Feb 2025 01:18:33 +0000 https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/656 the agent installation documentation to overwrite your `kpt`-deployed `agentk` instance. ]]> Tue, 11 Feb 2025 19:58:46 +0000 https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5927 migration guide for more information. ]]> Mon, 10 Feb 2025 10:08:35 +0100 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8888 Sat, 8 Feb 2025 09:11:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/515371#note_2319368251 Wed, 5 Feb 2025 15:35:26 +1300 https://gitlab.com/gitlab-org/gitlab/-/issues/426887 required scopes, and update your workflow variables and scripts with these new tokens. To assess how this change impacts your GitLab Self-Managed instance, you can monitor authentication logs for warning messages in GitLab 17.10 and later. In your `auth_json.log` file, look for entries that contain `Dependency proxy missing authentication abilities`. If you're using GitLab Helm charts or GitLab Dedicated, then the logs will be in `component: "gitlab"` and `subcomponent: "auth_json"`. These entries show authentication attempts using tokens without the required scopes, which will fail after upgrading to GitLab 18.0. ]]> Tue, 4 Feb 2025 22:30:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/498671 `aiMetrics` API, and instead they can use the `duoAssignedUsersCount`. This removal is part of the fix to count both GitLab Duo Pro and Duo seats assigned users. ]]> Mon, 3 Feb 2025 13:35:20 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/515358 Mon, 3 Feb 2025 00:10:27 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/513685 SAST CI/CD templates to enable GitLab Advanced SAST by default in projects with GitLab Ultimate. Before this change, the GitLab Advanced SAST analyzer is enabled only if you set the CI/CD variable `GITLAB_ADVANCED_SAST_ENABLED` to `true`. This change was previously scheduled for GitLab 18.0 and has now been delayed. Advanced SAST delivers more accurate results by using cross-file, cross-function scanning and a new ruleset. Advanced SAST takes over coverage for supported languages and disables scanning for that language in the previous scanner. An automated process migrates results from previous scanners after the first scan on each project's default branch, if they're still detected. Because it scans your project in more detail, Advanced SAST may take more time to scan your project. If needed, you can disable GitLab Advanced SAST by setting the CI/CD variable `GITLAB_ADVANCED_SAST_ENABLED` to `false`. You can set this variable in your project, group, or policy now to prevent Advanced SAST from being enabled by default in GitLab 19.0. ]]> Fri, 31 Jan 2025 19:26:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/513417 all analyzers - `kics` - `kubesec` - `pmd-apex` - `semgrep` - `sobelow` - `spotbugs` ]]> Wed, 22 Jan 2025 16:13:25 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/512564 disable the use of the CI/CD job cache by default. This change affects the CI/CD templates for: - SAST: `SAST.gitlab-ci.yml`. - IaC scanning: `SAST-IaC.gitlab-ci.yml`. We already updated the `latest` templates `SAST.latest.gitlab-ci.yml` and `SAST-IaC.latest.gitlab-ci.yml`. See stable and latest templates for more details on these template versions. The cache directories are not in scope for scanning in most projects, so fetching the cache can cause timeouts or false-positive results. If you need to use the cache when scanning a project, you can restore the previous behavior by overriding the `cache` property in the project's CI configuration. ]]> Tue, 21 Jan 2025 15:53:57 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/513938 Mon, 20 Jan 2025 09:30:43 +0000 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8786 since 16.0 and will be removed in 18.0. For migration instructions, see Migrating from `git_data_dirs`. ]]> Tue, 14 Jan 2025 23:27:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/382338 Fri, 10 Jan 2025 01:51:47 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/439199 Fri, 3 Jan 2025 19:46:17 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/510897 Fri, 3 Jan 2025 16:15:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/501294 issue 429728. This change does not impact the GitLab REST API, which will continue to use the existing milestone filtering logic. The GitLab GraphQL API will be updated to adhere to the new filtering logic. ]]> Mon, 9 Dec 2024 16:10:41 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/396284 Thu, 21 Nov 2024 15:18:04 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/436361 number of jobs in active pipelines will also apply when creating jobs using the Commits API. Review your integration to ensure it stays within the configured job limits. ]]> Thu, 21 Nov 2024 00:33:55 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/502382 pipeline variables by default, without any verification or opt-in. You can already start using a more secure-by-default experience for pipeline variables by raising the minimum role to the recommended Owner only, or no one. Starting in 17.7, `no one allowed` is the default for all new projects in new namespaces on GitLab.com. ]]> Wed, 20 Nov 2024 10:46:37 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/381894 Mon, 18 Nov 2024 17:39:46 +0000 https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5794 [!note] > This change affects you only if you're using the GitLab NGINX chart, > and you have set your own NGINX RBAC rules. > > If you're using your own external NGINX chart, > or you're using the GitLab NGINX chart without any NGINX RBAC rules changes, this deprecation doesn't apply to you. In GitLab 17.6 (Helm chart 8.6), the GitLab chart updated the default NGINX controller image from version 1.3.1 to 1.11.2. This new version requires new RBAC rules that were added to our GitLab NGINX chart, so you'll need to ultimately create those rules. This change is also backported to: - GitLab 17.5.1 (Helm chart 8.5.1) - GitLab 17.4.3 (Helm chart 8.4.3) - GitLab 17.3.6 (Helm chart 8.3.6) > [!note] > The latest patch versions of Helm chart 8.3 to 8.7 contain the NGINX controller version 1.11.2. > Later chart versions include version 1.11.5, since it contains various > security fixes. GitLab 18.0 will default to controller version 1.11.5. If you manage your own NGINX RBAC rules, it means that you have set `nginx-ingress.rbac.create` to `false`. In that case, from GitLab 17.3 (Helm chart 8.3) up until GitLab 17.11 (Helm chart 8.11), there's a fallback mechanism that detects that change and uses the old controller image, which means you don't need to make any RBAC rules changes. Starting with GitLab 18.0 (Helm chart 9.0), this fallback mechanism will be removed, so the new controller image will be used and the new RBAC rules must exist. If you want to take advantage of the new NGINX controller image before it's enforced in GitLab 18.0: 1. Add the new RBAC rules to your cluster see an example. 1. Set `nginx-ingress.controller.image.disableFallback` to `true`. For more information, see the charts release page. ]]> Fri, 8 Nov 2024 00:10:58 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/459869 Thu, 7 Nov 2024 01:05:28 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/498268 GitLab Runner Docker Machine executor is deprecated and will be fully removed from the product as a supported feature in GitLab 20.0 (May 2027). The replacement for Docker Machine, GitLab Runner Autoscaler with GitLab developed plugins for Amazon Web Services (AWS) EC2, Google Compute Engine (GCE) and Microsoft Azure virtual machines (VMs) is generally available. With this announcement, the GitLab Runner team will no longer accept community contributions for the GitLab maintained Docker Machine fork, or resolve newly identified bugs. ]]> Thu, 10 Oct 2024 17:21:51 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/473759 Thu, 10 Oct 2024 02:03:38 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/391941 Tue, 1 Oct 2024 19:56:52 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/474175 upcoming default behavior change to the CI/CD job token in GitLab 18.0, we are also deprecating the associated `ciJobTokenScopeAddProject` GraphQL mutation in favor of `ciJobTokenScopeAddGroupOrProject`. ]]> Thu, 26 Sep 2024 06:26:42 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/489850 Mon, 16 Sep 2024 18:37:48 +0200 https://gitlab.com/gitlab-org/gitlab/-/issues/476858 Fri, 13 Sep 2024 14:03:42 +0000 https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/issues/79 Heroku-24 stack release notes - Heroku-24 stack upgrade notes - Heroku stack packages These changes affect you if your pipelines use the `auto-build-image` provided by the Auto Build stage of Auto DevOps. To continue to use `heroku/builder:22` after GitLab 19.0, set `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` to `heroku/builder:22`. ]]> Wed, 11 Sep 2024 21:18:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/470641 Since GitLab 14.8 the correct location is under `registry.gitlab.com/security-products` (note the absence of `gitlab-org` in the address). This change improves the security of the release process for GitLab vulnerability scanners. Users are advised to use the equivalent registry under `registry.gitlab.com/security-products/`, which is the canonical location for GitLab security scanner images. The relevant GitLab CI templates already use this location, so no changes should be necessary for users that use the unmodified templates. Offline deployments should review the specific scanner instructions to ensure the correct locations are being used to mirror the required scanner images. ]]> Tue, 3 Sep 2024 09:30:42 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/480914 User, Project, and Group endpoints. Enabling these rate limits by default can help improve overall system stability, by reducing the potential for heavy API usage to negatively impact the broader user experience. Requests made above the rate limit will return an HTTP 429 error code and additional rate limit headers. The default rate limits have been intentionally set fairly high to not disrupt most usage, based on the request rates we see on GitLab.com. Instance administrators can set higher or lower limits as needed in the Admin area, similarly to other rate limits already in place. ]]> Mon, 2 Sep 2024 12:50:39 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/471677 provide the tool's report as an artifact. We've already documented how to integrate many tools directly, and you can integrate them by following the documentation. We expect to implement this change by: 1. Changing the `Code-Quality.gitlab-ci.yml` CI/CD template to no longer execute scans. Today, this template runs CodeClimate-based scans. (We plan to change the template rather than delete it to reduce the impact on any pipelines that still `include` the template after 19.0.) 1. No longer running CodeClimate-based scanning as part of Auto DevOps. Effective immediately, CodeClimate-based scanning will receive only limited updates. After End of Support in GitLab 19.0, we won't provide further updates. However, we won't delete previously published container images or remove the ability to run them by using custom CI/CD pipeline job definitions. For more details, see Scan code for quality violations. ]]> Fri, 2 Aug 2024 02:23:15 +0000 https://gitlab.com/groups/gitlab-org/-/epics/11275 Compliance pipelines. - Security policies. To provide a single place for ensuring required jobs are run in all pipelines for a project, we have deprecated compliance pipelines in GitLab 17.3 and will remove the feature in GitLab 20.0. Customers should migrate from compliance pipelines to the new pipeline execution policy type as soon as possible. For more information, see the relevant: - Migration guide. - Blog post. ]]> Mon, 29 Jul 2024 00:40:20 +0000 https://gitlab.com/components/opentofu/-/issues/43#note_1913822299 GitLab CI/CD components for GitLab Self-Managed we are removing the redundant OpenTofu CI/CD templates in favor of the CI/CD components. For information about migrating from the CI/CD template to the component, see the OpenTofu component documentation. ]]> Wed, 22 May 2024 16:40:00 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/424417 Thu, 9 May 2024 04:27:36 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/442520 already documented supported token types. For customers already using documented and supported token types, there are no breaking changes. ]]> Tue, 30 Apr 2024 22:13:54 +0000 https://gitlab.com/gitlab-org/gitaly/-/issues/5132 `. If you have trouble converting the existing keys to the expected format, see the existing keys in the correct format in the Linux package-generated configuration file of Gitaly. By default, the configuration file is located at `/var/opt/gitlab/gitaly/config.toml`. The following configuration options that are managed by Gitaly should be removed. These keys do not need to be migrated to Gitaly: - `pack.threads=1` - `receive.advertisePushOptions=true` - `receive.fsckObjects=true` - `repack.writeBitmaps=true` - `transfer.hideRefs=^refs/tmp/` - `transfer.hideRefs=^refs/keep-around/` - `transfer.hideRefs=^refs/remotes/` - `core.alternateRefsCommand="exit 0 #"` - `core.fsyncObjectFiles=true` - `fetch.writeCommitGraph=true` ]]> Tue, 12 Mar 2024 13:54:36 -0700 https://gitlab.com/gitlab-org/gitaly/-/issues/5598 Mon, 11 Mar 2024 20:05:44 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/424513 Enforce SEP variables with the highest precedence, we have discovered unintended behavior, allowing users to set `_EXCLUDED_PATHS` in pipeline configuration and preventing them from setting `_EXCLUDED_ANALYZERS` in both policy and pipeline configuration. To ensure proper enforcement of scan execution variables, when an `_EXCLUDED_ANALYZERS` or `_EXCLUDED_PATHS` variables are specified for a scan execution policy using the GitLab scan action, the variable will now override any project variables defined for excluded analyzers. Users may enable the feature flag to enforce this behavior before 17.0. In 17.0, projects leveraging the `_EXCLUDED_ANALYZERS`/`_EXCLUDED_PATHS` variable where a scan execution policy with the variable is defined will be overridden by default. ]]> Thu, 22 Feb 2024 23:35:52 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/412060 analyzers used by default in GitLab SAST. This is part of our long-term strategy to deliver a faster, more consistent user experience across different programming languages. In GitLab 17.0, we will: 1. Remove a set of language-specific analyzers from the SAST CI/CD template and replace their coverage with GitLab-supported detection rules in the Semgrep-based analyzer. The following analyzers are now deprecated and will reach End of Support in GitLab 17.0: 1. Brakeman (Ruby, Ruby on Rails) 1. Flawfinder (C, C++) 1. MobSF (Android, iOS) 1. NodeJS Scan (Node.js) 1. PHPCS Security Audit (PHP) 1. Change the SAST CI/CD template to stop running the SpotBugs-based analyzer for Kotlin and Scala code. These languages will instead be scanned using GitLab-supported detection rules in the Semgrep-based analyzer. Effective immediately, the deprecated analyzers will receive only security updates; other routine improvements or updates are not guaranteed. After the analyzers reach End of Support in GitLab 17.0, no further updates will be provided. However, we won't delete container images previously published for these analyzers or remove the ability to run them by using custom CI/CD pipeline job definitions. The vulnerability management system will update most existing findings so that they're matched with the new detection rules. Findings that aren't migrated to the new analyzer will be automatically resolved. See Vulnerability translation documentation for further details. If you applied customizations to the removed analyzers, or if you currently disable the Semgrep-based analyzer in your pipelines, you must take action as detailed in the deprecation issue for this change. ]]> Fri, 16 Feb 2024 23:33:08 +0000 https://gitlab.com/gitlab-org/ci-cd/shared-runners/infrastructure/-/issues/60 Upgrading the operating system version of our SaaS runners on Linux. ]]> Wed, 14 Feb 2024 09:08:41 +0000 https://gitlab.com/gitlab-org/gitlab-runner/-/issues/30829 Removing tags from our small SaaS runner on Linux. ]]> Wed, 14 Feb 2024 09:07:20 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/438554 Windows 2022 support for GitLab.com runners now available. ]]> Wed, 14 Feb 2024 09:04:26 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/433009 overrides. From 17.0, npm and Yarn packages will be uploaded asynchronously. This is a breaking change because you might have pipelines that expect the package to be available as soon as it's published. As a workaround, you should use the packages API to check for packages. ]]> Mon, 12 Feb 2024 15:52:58 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/383218 Mon, 12 Feb 2024 00:02:28 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/422783 Compliance Center. Therefore, in GitLab 17.0, we are removing the management of compliance frameworks from the **General** settings page of groups and projects. ]]> Mon, 12 Feb 2024 09:45:31 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/439164 statement of support. Users are advised to use the default setting for `CS_ANALYZER_IMAGE`, which uses the Trivy scanner. The existing current major version for the Grype analyzer image will continue to be updated with the latest advisory database, and operating system packages until GitLab 19.0, at which point the analyzer will stop working. To continue to use Grype past 19.0, see the Security scanner integration documentation to learn how to create your own integration with GitLab. ]]> Fri, 9 Feb 2024 23:08:13 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/439301 artifact report type is deprecated in GitLab 16.9, and will be removed in GitLab 18.0. CI/CD configurations using this keyword will stop working in GitLab 18.0. The artifact report type is no longer used because of the removal of the legacy License Scanning CI/CD job in GitLab 16.3. Instead, you should use License scanning of CycloneDX files. ]]> Fri, 9 Feb 2024 22:52:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/441201 compatible lockfile. ]]> Fri, 9 Feb 2024 22:38:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/396376 `dependency_path` will also be deprecated and removed in 17.0. GitLab will move forward with the implementation of the dependency graph using the CycloneDX specification to provide similar information. Additionally, the container scanning CI job will no longer produce a dependency scanning report to provide the list of Operating System components as this is replaced with the CycloneDX SBOM report. The `CS_DISABLE_DEPENDENCY_LIST` environment variable for container scanning is no longer in use and will also be removed in 17.0. ]]> Fri, 9 Feb 2024 21:15:57 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/440733 Fri, 9 Feb 2024 16:27:29 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/424513 Support additional filters for scan result policies, we broke the `newly_detected` field into two options: `new_needs_triage` and `new_dismissed`. By including both options in the security policy YAML, you will achieve the same result as the original `newly_detected` field. However, you may now narrow your filter to ignore findings that have been dismissed by only using `new_needs_triage`. Based on discussion in epic 10203, we have changed the name of the `match_on_inclusion` field to `match_on_inclusion_license` for more clarity in the YAML definition. ]]> Fri, 9 Feb 2024 01:20:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/439687 Wed, 7 Feb 2024 22:32:22 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/440249 OpenTofu CI/CD component. ]]> Tue, 6 Feb 2024 08:18:07 +0100 https://gitlab.com/gitlab-org/gitlab/-/issues/408989 add `omniauth_openid_connect` as a new provider any time before 17.0. Users will see a new login button and have to manually reconnect their credentials. If you do not implement the `omniauth_openid_connect` gem before 17.0, users will no longer be able to sign in using the Azure login button, and will have to sign in using their username and password, until the correct gem is implemented by the administrator. ]]> Thu, 1 Feb 2024 15:47:29 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/438010 Terraform image, and maintain them as needed. GitLab provides detailed instructions for migrating to a custom built image. As an alternative we recommend using the new OpenTofu CI/CD component on GitLab.com or the new OpenTofu CI/CD template on GitLab Self-Managed. CI/CD components are not yet available on GitLab Self-Managed, but Issue #415638 proposes to add this feature. If CI/CD components become available on GitLab Self-Managed, the OpenTofu CI/CD template will be removed. See more about the new OpenTofu CI/CD component. ]]> Wed, 31 Jan 2024 17:34:41 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/438123 all analyzers - `brakeman` - `flawfinder` - `kubesec` - `mobsf` - `nodejs-scan` - `phpcs-security-audit` - `pmd-apex` - `semgrep` - `sobelow` - `spotbugs` ]]> Wed, 31 Jan 2024 10:49:47 +1100 https://gitlab.com/gitlab-org/gitlab/-/issues/439284 Tue, 30 Jan 2024 11:49:54 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/439157 `Jobs/License-Scanning.gitlab-ci.yml` - `Jobs/License-Scanning.latest.gitlab-ci.yml` - `Security/License-Scanning.gitlab-ci.yml` CI configurations including any of the templates above will stop working in GitLab 17.0. Users are advised to use License scanning of CycloneDX files instead. ]]> Wed, 24 Jan 2024 15:29:40 +1100 https://gitlab.com/gitlab-org/gitlab/-/issues/438772 Tue, 23 Jan 2024 01:16:48 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/438477 Tue, 23 Jan 2024 07:55:11 +1100 https://gitlab.com/gitlab-org/gitlab/-/issues/438779 GitLab CycloneDX property taxonomy. The following correct properties were added in GitLab 15.11 to address this: - `gitlab:dependency_scanning:input_file:path` - `gitlab:dependency_scanning:package_manager:name` The incorrect properties were kept for backward compatibility. They are now deprecated and will be removed in 17.0. ]]> Mon, 22 Jan 2024 08:37:09 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/435791 Sentry documentation. > [!note] > The deprecated support is for > GitLab instance error tracking features > for administrators. The deprecated support does not relate to > GitLab error tracking for > developers' own deployed applications. ]]> Mon, 22 Jan 2024 07:32:17 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/437986 feature flag REST API is deprecated and will be removed in GitLab 17.0. After the `version` field is removed, there won't be a way to create legacy feature flags. ]]> Fri, 19 Jan 2024 20:01:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/437728 Fri, 19 Jan 2024 19:45:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/437937 Fri, 19 Jan 2024 19:09:00 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/383084 default CI/CD job token scope change announced in GitLab 15.9, the `direction` argument will default to `INBOUND` and `OUTBOUND` will no longer be valid in GitLab 17.0. We will remove the `direction` argument in GitLab 18.0. If you are using `OUTBOUND` with the `direction` argument to control the direction of your project's token access, your pipeline that use job tokens risk failing authentication. To ensure pipelines continue to run as expected, you will need to explicitly add the other projects to your project's allowlist. ]]> Thu, 18 Jan 2024 05:01:42 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/435210 '` in `/etc/gitlab/gitlab.rb` for Linux package installations, or by editing `config/gitlab.yml` for self-compiled installations. While the configuration setting was available, it had no effect and did not serve the purpose it was intended. This configuration setting will be removed in GitLab 17.0. ]]> Thu, 11 Jan 2024 13:46:02 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/437789 `after_script` CI/CD keyword is used to run additional commands after the main `script` section of a job. This is often used for cleaning up environments or other resources that were used by the job. For many users, the fact that the `after_script` commands do not run if a job is canceled was unexpected and undesired. In 17.0, the keyword will be updated to also run commands after job cancellation. Make sure that your CI/CD configuration that uses the `after_script` keyword is able to handle running for canceled jobs as well. ]]> Thu, 11 Jan 2024 06:15:21 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/436100 Wed, 10 Jan 2024 23:29:14 +0000 https://gitlab.com/gitlab-org/gitlab-runner/-/issues/36869 Mon, 8 Jan 2024 10:19:50 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/437591 Mon, 8 Jan 2024 08:35:00 +1100 https://gitlab.com/gitlab-org/gitlab/-/issues/415835 Wed, 3 Jan 2024 22:39:12 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/393172 Tue, 2 Jan 2024 08:10:22 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/221031 deprecation of old JSON web token versions in GitLab 17.0, the associated `/-/jwks` endpoint, which is an alias for `/oauth/discovery/keys`, is no longer necessary and will be removed. If you've been specifying `jwks_url` in your auth configuration, update your configuration to `oauth/discovery/keys` instead and remove all uses of `/-/jwks` in your endpoints. If you've already been using `oauth_discovery_keys` in your auth configuration and the `/-/jwks` alias in your endpoints, remove `/-/jwks` from your endpoints. For example, change `https://gitlab.example.com/-/jwks` to `https://gitlab.example.com`. ]]> Tue, 5 Dec 2023 05:26:13 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/384361 backup and restore instead. ]]> Tue, 28 Nov 2023 19:14:03 -1000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124461 Settings API. To add a custom text to the sign-in and new user account pages, use the `description` field in the Appearance API. ]]> Fri, 10 Nov 2023 03:45:18 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390754 Thu, 9 Nov 2023 23:35:57 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/416384 Geo self-service framework (SSF), the legacy replication for project repositories has been removed. As a result, the following Rake tasks that relied on legacy code have also been removed. The work invoked by these Rake tasks are now triggered automatically either periodically or based on trigger events. | Rake task | Replacement | | --------- | ----------- | | `geo:git:housekeeping:full_repack` | Moved to UI. No equivalent Rake task in the SSF. | | `geo:git:housekeeping:gc` | Always executed for new repositories, and then when it's needed. No equivalent Rake task in the SSF. | | `geo:git:housekeeping:incremental_repack` | Executed when needed. No equivalent Rake task in the SSF. | | `geo:run_orphaned_project_registry_cleaner` | Executed regularly by a registry consistency worker which removes orphaned registries. No equivalent Rake task in the SSF. | | `geo:verification:repository:reset` | Moved to UI. No equivalent Rake task in the SSF. | | `geo:verification:wiki:reset` | Moved to UI. No equivalent Rake task in the SSF. | ]]> Wed, 8 Nov 2023 09:23:48 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/430966 Wed, 8 Nov 2023 00:41:31 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/430192 Geo self-service framework we have deprecated a number of Prometheus metrics. The following Geo-related Prometheus metrics are deprecated and will be removed in 17.0. The table below lists the deprecated metrics and their respective replacements. The replacements are available in GitLab 16.3.0 and later. | Deprecated metric | Replacement metric | | ---------------------------------------- | ---------------------------------------------- | | `geo_repositories_synced` | `geo_project_repositories_synced` | | `geo_repositories_failed` | `geo_project_repositories_failed` | | `geo_repositories_checksummed` | `geo_project_repositories_checksummed` | | `geo_repositories_checksum_failed` | `geo_project_repositories_checksum_failed` | | `geo_repositories_verified` | `geo_project_repositories_verified` | | `geo_repositories_verification_failed` | `geo_project_repositories_verification_failed` | | `geo_repositories_checksum_mismatch` | None available | | `geo_repositories_retrying_verification` | None available | ]]> Tue, 7 Nov 2023 09:28:29 +0000 https://gitlab.com/gitlab-org/container-registry/-/issues/1141 object storage support. OSS has an S3 compatibility mode, so consider using that if you can't migrate to a supported driver. Swift is compatible with S3 API operations, required by the S3 storage driver as well. ]]> Wed, 25 Oct 2023 09:49:30 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/428225 API or the UI. ]]> Tue, 24 Oct 2023 23:52:00 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/419445 file type CI/CD variable in another CI/CD variable, the CI/CD variable would expand to contain the contents of the file. This behavior was incorrect because it did not comply with typical shell variable expansion rules. The CI/CD variable reference should expand to only contain the path to the file, not the contents of the file itself. This was fixed for most use cases in GitLab 15.7. Unfortunately, passing CI/CD variables to downstream pipelines was an edge case not yet fixed, but which will now be fixed in GitLab 17.0. With this change, a variable configured in the `.gitlab-ci.yml` file can reference a file variable and be passed to a downstream pipeline, and the file variable will be passed to the downstream pipeline as well. The downstream pipeline will expand the variable reference to the file path, not the file contents. This breaking change could disrupt user workflows that depend on expanding a file variable in a downstream pipeline. ]]> Mon, 23 Oct 2023 09:41:53 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/422414 Support additional filters for scan result policies, we broke the `newly_detected` field into two options: `new_needs_triage` and `new_dismissed`. By including both options in the security policy YAML, you will achieve the same result as the original `newly_detected` field. However, you may now narrow your filter to ignore findings that have been dismissed by only using `new_needs_triage`. ]]> Thu, 12 Oct 2023 00:48:09 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/426547 keyset pagination instead. ]]> Tue, 3 Oct 2023 10:22:39 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/12776 protected branch, unprotecting a branch, and creating protected tags. ]]> Mon, 25 Sep 2023 12:12:16 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/389452 Mon, 25 Sep 2023 12:12:16 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/353639 changing your error tracking to Sentry in your project settings. For additional background on this removal, please reference Disable Integrated Error Tracking by Default. If you have feedback please add a comment to Feedback: Removal of Integrated Error Tracking. ]]> Mon, 25 Sep 2023 12:12:16 +0000 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8164 Wed, 20 Sep 2023 18:31:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/383084 **Authorized groups and projects** setting introduced in GitLab 15.9 (renamed from **Limit access _to_ this project** in GitLab 16.3), you can control CI/CD job token access to your project. When set to **Only this project and any groups and projects in the allowlist**, only groups or projects added to the allowlist can use job tokens to access your project. For projects created before GitLab 15.9, the allowlist was disabled by default (**All groups and projects** access setting selected), allowing job token access from any project. The allowlist is now enabled by default in all new projects. In older projects, it might still be disabled or you might have manually selected the **All groups and projects** option to make access unrestricted. Starting in GitLab 17.6, administrators for GitLab Self-Managed and GitLab Dedicated instances can optionally enforce this more secure setting for all projects. This setting prevents project maintainers from selecting **All groups and projects**. This change ensures a higher level of security between projects. In GitLab 18.0, this instance setting will be enabled by default on GitLab.com, GitLab Self-Managed, and GitLab Dedicated. GitLab Self-Managed and GitLab Dedicated administrators can disable the setting after upgrading to GitLab 18.0 to restore the pre-upgrade behavior. No project settings will be changed in GitLab 18.0 for GitLab Self-Managed and GitLab Dedicated, though the status of the instance setting impacts all projects on the instance. To prepare for this change, project maintainers using job tokens for cross-project authentication should populate their project's **Authorized groups and projects** allowlists. They should then change the setting to **Only this project and any groups and projects in the allowlist**. To help identify projects that need access to your project by authenticating with a CI/CD job token, in GitLab 17.6 we also introduced a method to track job token authentications to your projects. You can use that data to populate your CI/CI job token allowlist. From GitLab 17.10 to 18.6, you can use migration tooling to automatically populate the CI/CD job token allowlist from the job token authentication log. We encourage you to use this migration tool to populate and use the allowlist before general enforcement of allowlists in GitLab 18.0. In GitLab 18.0, automatic population and enforcement of the allowlist will occur on GitLab.com as previously announced. This migration tool was removed in GitLab 18.7. ]]> Wed, 13 Sep 2023 23:14:50 +0000 https://gitlab.com/gitlab-org/container-registry/-/issues/1094 OCI Distribution Spec did not include a tag delete operation, and an unsafe and slow workaround (involving deleting manifests, not tags) had to be used to achieve the same end. Tag deletion is an important function, so we added a tag deletion operation to the GitLab container registry, extending the V2 API beyond the scope of the Docker and OCI distribution spec. Since then, the OCI Distribution Spec has had some updates and it now has a tag delete operation, using the `DELETE /v2//manifests/` endpoint. This leaves the container registry with two endpoints that provide the exact same functionality. `DELETE /v2//tags/reference/` is the custom GitLab tag delete endpoint and `DELETE /v2//manifests/`, the OCI compliant tag delete endpoint introduced in GitLab 16.4. Support for the custom GitLab tag delete endpoint is deprecated in GitLab 16.4, and it will be removed in GitLab 17.0. This endpoint is used by the **internal** container registry application API, not the public GitLab container registry API. No action should be required by the majority of container registry users. All the GitLab UI and API functionality related to tag deletions will remain intact as we transition to the new OCI-compliant endpoint. If you do access the internal container registry API and use the original tag deletion endpoint, you must update to the new endpoint. ]]> Wed, 13 Sep 2023 15:23:01 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/424133 create a custom role for their developers and add in the `admin_vulnerability` permission to give them this access. ]]> Mon, 11 Sep 2023 02:31:04 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/424002 Geo self-service framework, the following replication details routes are deprecated: - Designs `/admin/geo/replication/designs` replaced by `/admin/geo/sites//replication/design_management_repositories` - Projects `/admin/geo/replication/projects` replaced by `/admin/geo/sites//replication/projects` From GitLab 16.4 to 17.0, lookups for the legacy routes will automatically be redirected to the new routes. We will remove the redirections in 17.0. Please update any bookmarks or scripts that may use the legacy routes. ]]> Thu, 7 Sep 2023 20:33:20 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/421440 GraphQL resource has been deprecated and will be removed in GitLab 17.0. Since GitLab 15.0 this field has returned no data. ]]> Fri, 1 Sep 2023 09:30:06 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/420678 **Limit access to this project** is enabled. If you have public or internal projects with the **Limit access to this project** setting enabled, you must add any projects which make job token requests to your project's allowlist for continued authorization. ]]> Fri, 18 Aug 2023 08:06:04 +0000 https://gitlab.com/groups/gitlab-org/-/epics/11186 -text -noout | grep "Key:"`. ]]> Thu, 17 Aug 2023 21:30:20 +0000 https://gitlab.com/gitlab-com/Product/-/issues/11417 supported OmniAuth provider. ]]> Thu, 3 Aug 2023 19:19:16 +0000 https://gitlab.com/gitlab-com/Product/-/issues/11417 another supported OmniAuth provider instead. ]]> Thu, 3 Aug 2023 19:19:16 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/416219 Mon, 24 Jul 2023 13:53:19 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/414895 Mon, 24 Jul 2023 08:46:14 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/406545 migrate to Flux. Because Flux is a mature CNCF project for GitOps, we decided to integrate Flux with GitLab in February 2023. ]]> Mon, 17 Jul 2023 16:27:02 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/416509 Tue, 11 Jul 2023 12:55:35 +0300 https://gitlab.com/gitlab-org/gitlab/-/issues/415185 GraphQL `CiRunner` type as they are duplicated with the introduction of runner managers grouped within a runner configuration. ]]> Tue, 4 Jul 2023 07:37:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/416000 supported provider in advance of support removal. ]]> Fri, 30 Jun 2023 14:28:39 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/411573 Thu, 29 Jun 2023 01:22:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/414864 issue 29479. ]]> Fri, 16 Jun 2023 13:01:09 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/414236 Fri, 16 Jun 2023 05:31:13 +0000 https://gitlab.com/groups/gitlab-org/-/epics/9662 Fri, 19 May 2023 21:44:53 +0000 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7772 deprecated and disabled in 16.0 and will be removed in 16.3. If you are using the bundled Grafana, you must migrate to either: - Another implementation of Grafana. For more information, see Switch to new Grafana instance. - Another observability platform of your choice. The version of Grafana that is currently provided is no longer a supported version. In GitLab versions 16.0 to 16.2, you can still re-enable the bundled Grafana. However, enabling the bundled Grafana will no longer work from GitLab 16.3. ]]> Fri, 12 May 2023 01:54:46 +0000 https://gitlab.com/groups/gitlab-org/-/epics/9065 annual upgrade cadence for PostgreSQL. Support for PostgreSQL 13 is scheduled for removal in GitLab 17.0. In GitLab 17.0, PostgreSQL 14 becomes the minimum required PostgreSQL version. PostgreSQL 13 will be supported for the full GitLab 16 release cycle. PostgreSQL 14 will also be supported for instances that want to upgrade prior to GitLab 17.0. If you are running a single PostgreSQL instance you installed by using an Omnibus Linux package, an automatic upgrade may be attempted with 16.11. Make sure you have enough disk space to accommodate the upgrade. For more information, see the Omnibus database documentation. ]]> Thu, 11 May 2023 19:21:24 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/409333 Mon, 8 May 2023 15:11:56 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/408396 improved multi-module support. ]]> Thu, 4 May 2023 22:47:30 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/372117 Fri, 28 Apr 2023 17:06:42 +0200 https://gitlab.com/gitlab-org/gitlab/-/issues/393836 ` can display, for example, a task or an OKR. In GitLab 15.10 we added support for using internal IDs (IID) in that path by appending a query parameter at the end (`iid_path`) in the following format: `https://gitlab.com/gitlab-org/gitlab/-/work_items/?iid_path=true`. In GitLab 16.0 we will remove the ability to use a global ID in the work items path. The number at the end of the path will be considered an internal ID (IID) without the need of adding a query parameter at the end. Only the following format will be supported: `https://gitlab.com/gitlab-org/gitlab/-/work_items/`. ]]> Mon, 20 Mar 2023 15:24:48 +0100 https://gitlab.com/gitlab-org/charts/gitlab/-/issues/4353 newer chart version from Grafana Labs or a Grafana Operator from a trusted provider. In your new Grafana instance, you can configure the GitLab provided Prometheus as a data source and connect Grafana to the GitLab UI. ]]> Mon, 20 Mar 2023 11:52:45 +0000 https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3442 PostgreSQL 12 support is being removed, and PostgreSQL 13 is becoming the new minimum. - Installs using production-ready external databases will need to complete their migration to a newer PostgreSQL version before upgrading. - Installs using the non-production bundled PostgreSQL 12 chart will have the chart upgraded to the new version. For more information, see issue 4118 - Installs using the non-production bundled Redis chart will have the chart upgraded to a newer version. For more information, see issue 3375 - Installs using the bundled cert-manager chart will have the chart upgraded to a newer version. For more information, see issue 4313 The full GitLab Helm Chart 7.0 upgrade steps will be available in the upgrade docs. ]]> Mon, 20 Mar 2023 10:44:16 +0000 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7278 Consul was updated to 1.9.6, which deprecated some telemetry metrics from being at the `consul.http` path. In GitLab 16.0, the `consul.http` path will be removed. If you have monitoring that consumes Consul metrics, update them to use `consul.api.http` instead of `consul.http`. For more information, see the deprecation notes for Consul 1.9.0. ]]> Wed, 15 Mar 2023 00:38:37 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/393574 the upgrade instructions. ]]> Tue, 14 Mar 2023 22:36:32 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/382532 Thu, 2 Mar 2023 19:34:27 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390855 Fri, 24 Feb 2023 10:17:17 +0100 https://gitlab.com/gitlab-org/gitlab/-/issues/391896 `CI_PRE_CLONE_SCRIPT` variable supported by GitLab.com Runners is deprecated as of GitLab 15.9 and will be removed in 16.0. The `CI_PRE_CLONE_SCRIPT` variable enables you to run commands in your CI/CD job prior to the runner executing Git init and get fetch. For more information about how this feature works, see Pre-clone script. As an alternative, you can use the `pre_get_sources_script`. ]]> Tue, 21 Feb 2023 19:25:56 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390291 the upgrade instructions. This change brings Praefect configuration in Omnibus GitLab in line with the configuration structure of Praefect. Previously, the hierarchies and configuration keys didn't match. The change improves consistency between Omnibus GitLab and source installs and enables us to provide better documentation and tooling for both. ]]> Tue, 21 Feb 2023 00:17:04 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390417 Fri, 17 Feb 2023 21:16:12 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/372770 job names have a strict 255 character limit, other CI/CD parameters do not yet have validations ensuring they also stay under the limit. In GitLab 16.0, validation will be added to strictly limit the following to 255 characters as well: - The `stage` keyword. - The `ref`, which is the Git branch or tag name for the pipeline. - The `description` and `target_url` parameter, used by external CI/CD integrations. Users on GitLab Self-Managed should update their pipelines to ensure they do not use parameters that exceed 255 characters. Users on GitLab.com do not need to make any changes, as these are already limited in that database. ]]> Fri, 17 Feb 2023 18:26:18 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/391822 `API-Fuzzing.gitlab-ci.yml` - Container scanning: `Container-Scanning.gitlab-ci.yml` - Coverage-guided fuzzing: `Coverage-Fuzzing.gitlab-ci.yml` - DAST: `DAST.gitlab-ci.yml` - DAST API: `DAST-API.gitlab-ci.yml` - Dependency scanning: `Dependency-Scanning.gitlab-ci.yml` - IaC scanning: `SAST-IaC.gitlab-ci.yml` - SAST: `SAST.gitlab-ci.yml` - Secret detection: `Secret-Detection.gitlab-ci.yml` We recommend that you test your pipelines before the 16.0 release if you use one of the templates listed above and you use the `_DISABLED` variables but set a value other than `"true"`. **Update**: We previously announced that we would update the `rules` on the affected templates to run in merge request pipelines by default. However, due to compatibility issues discussed in the deprecation issue, we will no longer make this change in GitLab 16.0. We will still release the changes to the `_DISABLED` variables as described above. ]]> Fri, 17 Feb 2023 03:36:16 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390417 license approval policy instead. ]]> Fri, 17 Feb 2023 00:09:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390416 analyzers to scan code for vulnerabilities. We're reducing the number of supported analyzers used by default in GitLab SAST. This is part of our long-term strategy to deliver a faster, more consistent user experience across different programming languages. Starting in GitLab 16.0, the GitLab SAST CI/CD template will no longer use the Security Code Scan-based analyzer for .NET, and it will enter End of Support status. We'll remove this analyzer from the SAST CI/CD template and replace it with GitLab-supported detection rules for C# in the Semgrep-based analyzer. Effective immediately, this analyzer will receive only security updates; other routine improvements or updates are not guaranteed. After this analyzer reaches End of Support in GitLab 16.0, no further updates will be provided. However, we won't delete container images previously published for this analyzer or remove the ability to run it by using a custom CI/CD pipeline job. If you've already dismissed a vulnerability finding from the deprecated analyzer, the replacement attempts to respect your previous dismissal. The system behavior depends on: - whether you've excluded the Semgrep-based analyzer from running in the past. - which analyzer first discovered the vulnerabilities shown in the project's Vulnerability Report. See Vulnerability translation documentation for further details. If you applied customizations to the affected analyzer, or if you currently disable the Semgrep-based analyzer in your pipelines, you must take action as detailed in the deprecation issue for this change. **Update**: We've reduced the scope of this change. We will no longer make the following changes in GitLab 16.0: 1. Remove support for the analyzer based on PHPCS Security Audit and replace it with GitLab-managed detection rules in the Semgrep-based analyzer. 1. Remove Scala from the scope of the SpotBugs-based analyzer and replace it with GitLab-managed detection rules in the Semgrep-based analyzer. Work to replace the PHPCS Security Audit-based analyzer is tracked in issue 364060 and work to migrate Scala scanning to the Semgrep-based analyzer is tracked in issue 362958. ]]> Thu, 16 Feb 2023 23:09:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/387561 license scanning of CycloneDX files we will do this in 16.3 instead. The GitLab license compliance CI/CD template is now deprecated and is scheduled for removal in the GitLab 16.3 release. To continue using GitLab for license compliance, remove the license compliance template from your CI/CD pipeline and add the dependency scanning template. The dependency scanning template is now capable of gathering the required license information, so it is no longer necessary to run a separate license compliance job. Before you remove the license compliance CI/CD template, verify that the instance has been upgraded to a version that supports the new method of license scanning. To begin using the Dependency Scanner quickly at scale, you may set up a scan execution policy at the group level to enforce the SBOM-based license scan for all projects in the group. Then, you may remove the inclusion of the `Jobs/License-Scanning.gitlab-ci.yml` template from your CI/CD configuration. If you wish to continue using the legacy license compliance feature, you can do so by setting the `LICENSE_MANAGEMENT_VERSION CI` variable to `4`. This variable can be set at the project, group, or instance level. This configuration change will allow you to continue using an existing version of license compliance without having to adopt the new approach. Bugs and vulnerabilities in this legacy analyzer will no longer be fixed. | CI Pipeline Includes | GitLab <= 15.8 | 15.9 <= GitLab < 16.3 | GitLab >= 16.3 | | ------------- | ------------- | ------------- | ------------- | | Both DS and LS templates | License data from LS job is used | License data from LS job is used | License data from DS job is used | | DS template is included but LS template is not | No license data | License data from DS job is used | License data from DS job is used | | LS template is included but DS template is not | License data from LS job is used | License data from LS job is used | No license data | ]]> Thu, 16 Feb 2023 22:53:28 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/366798 ID tokens with OIDC support were introduced in GitLab 15.7. These tokens are more configurable than the old JSON web tokens (JWTs), are OIDC compliant, and only available in CI/CD jobs that explicitly have ID tokens configured. ID tokens are more secure than the old `CI_JOB_JWT*` JSON web tokens which are exposed in every job, and as a result these old JSON web tokens are deprecated: - `CI_JOB_JWT` - `CI_JOB_JWT_V1` - `CI_JOB_JWT_V2` To prepare for this change, configure your pipelines to use ID tokens instead of the deprecated tokens. For OIDC compliance, the `iss` claim now uses the fully qualified domain name, for example `https://example.com`, previously introduced with the `CI_JOB_JWT_V2` token. In GitLab 15.9 to 15.11, you can enable the **Limit JSON Web Token (JWT) access** setting, which prevents the old tokens from being exposed to any jobs and enables ID token authentication for the `secrets:vault` keyword. In GitLab 16.0 and later: - This setting will be removed. - CI/CD jobs that use the `id_tokens` keyword can use ID tokens with `secrets:vault`, and will not have any `CI_JOB_JWT*` tokens available. - Jobs that do not use the `id_tokens` keyword will continue to have the `CI_JOB_JWT*` tokens available until GitLab 17.0. In GitLab 17.0, the deprecated tokens will be completely removed and will no longer be available in CI/CD jobs. ]]> Thu, 16 Feb 2023 11:28:52 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/214217 issue 28848. Update any scripts or bookmarks that reference the legacy URLs. GitLab APIs are not affected by this change. ]]> Wed, 15 Feb 2023 22:49:48 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390912 maintenance policy. As required, security patches will be backported within the latest 3 minor releases. Specifically, the following are being deprecated and will no longer be updated after 16.0 GitLab release: - API fuzzing: version 2 - Container scanning: version 5 - Coverage-guided fuzz testing: version 3 - Dependency scanning: version 3 - Dynamic application security testing (DAST): version 3 - DAST API: version 2 - IaC scanning: version 3 - License scanning: version 4 - Secret detection: version 4 - Static application security testing (SAST): version 3 of all analyzers - `brakeman`: version 3 - `flawfinder`: version 3 - `kubesec`: version 3 - `mobsf`: version 3 - `nodejs-scan`: version 3 - `phpcs-security-audit`: version 3 - `pmd-apex`: version 3 - `security-code-scan`: version 3 - `semgrep`: version 3 - `sobelow`: version 3 - `spotbugs`: version 3 ]]> Wed, 15 Feb 2023 21:36:00 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109704 GraphQL API, the `external` field of `ReleaseAssetLink` type was used to indicate whether a release link is internal or external to your GitLab instance. As of GitLab 15.9, we treat all release links as external, and therefore, this field is deprecated in GitLab 15.9, and will be removed in GitLab 16.0. To avoid any disruptions to your workflow, please stop using the `external` field because it will be removed and will not be replaced. ]]> Wed, 15 Feb 2023 12:08:30 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109705 Releases API and Release Links API, the `external` field was used to indicate whether a release link is internal or external to your GitLab instance. As of GitLab 15.9, we treat all release links as external, and therefore, this field is deprecated in GitLab 15.9, and will be removed in GitLab 16.0. To avoid any disruptions to your workflow, please stop using the `external` field because it will be removed and will not be replaced. ]]> Wed, 15 Feb 2023 11:03:03 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/395708 limit access _from_ your project's CI/CD job tokens (`CI_JOB_TOKEN`) to make it more secure. This setting was called **Limit CI_JOB_TOKEN access**. In GitLab 16.3, we renamed this setting to **Limit access _from_ this project** for clarity. In GitLab 15.9, we introduced an alternative setting called **Authorized groups and projects**. This setting controls job token access _to_ your project by using an allowlist. This new setting is a large improvement over the original. The first iteration was deprecated in GitLab 16.0 and scheduled for removal in GitLab 18.0. The **Limit access _from_ this project** setting is disabled by default for all new projects. In GitLab 16.0 and later, you cannot re-enable this setting after it is disabled in any project. Instead, use the **Authorized groups and projects** setting to control job token access to your projects. ]]> Tue, 14 Feb 2023 13:58:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390787 queue selector (having multiple processes listening to a set of queues) and negate settings is deprecated and will be fully removed in 17.0. You can migrate away from queue selectors to listening to all queues in all processes. For example, if Sidekiq is currently running with 4 processes (denoted by 4 elements in `sidekiq['queue_groups']` in `/etc/gitlab/gitlab.rb`) with queue selector (`sidekiq['queue_selector'] = true`), you can change Sidekiq to listen to all queues in all 4 processes,for example `sidekiq['queue_groups'] = ['*'] * 4`. This approach is also recommended in our Reference Architecture. Note that Sidekiq can effectively run as many processes as the number of CPUs in the machine. While the above approach is recommended for most instances, Sidekiq can also be run using routing rules which is also being used on GitLab.com. You can follow the migration guide from queue selectors to routing rules. You need to take care with the migration to avoid losing jobs entirely. ]]> Mon, 13 Feb 2023 09:46:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/366798 `secrets:vault` keyword to retrieve secrets from Vault will need to be configured to use the ID tokens. ID tokens were introduced in 15.7. To prepare for this change, use the new `id_tokens` keyword and configure the `aud` claim. Ensure the bound audience is prefixed with `https://`. In GitLab 15.9 to 15.11, you can enable the **Limit JSON Web Token (JWT) access** setting, which prevents the old tokens from being exposed to any jobs and enables ID token authentication for the `secrets:vault` keyword. In GitLab 16.0 and later: - This setting will be removed. - CI/CD jobs that use the `id_tokens` keyword can use ID tokens with `secrets:vault`, and will not have any `CI_JOB_JWT*` tokens available. - Jobs that do not use the `id_tokens` keyword will continue to have the `CI_JOB_JWT*` tokens available until GitLab 17.0. ]]> Fri, 10 Feb 2023 10:08:20 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/389467 Security policies scoped to compliance frameworks, which are experimental. - Compliance pipelines, which are available now. We recommend these alternative solutions because they provides greater flexibility, allowing required pipelines to be assigned to specific compliance framework labels. Compliance pipelines will be deprecated in the future and migrated to security policies. For more information, see the migration and deprecation epic. ]]> Fri, 10 Feb 2023 06:04:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/375505 Wed, 8 Feb 2023 04:37:21 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/390266 Tue, 7 Feb 2023 00:30:10 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/389477 embed charts with the GitLab Observability UI. ]]> Mon, 6 Feb 2023 11:54:56 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/389557 Fri, 3 Feb 2023 13:12:03 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/353080 Mon, 30 Jan 2023 23:21:01 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/387937 GitLab Runner documentation instead of using these API queries. ]]> Wed, 25 Jan 2023 14:08:02 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/387299 set up OAuth authentication to continue to use the GitLab for Jira Cloud app. Without OAuth, you can't manage linked namespaces. ]]> Thu, 19 Jan 2023 15:31:36 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/387976 Thu, 19 Jan 2023 13:34:58 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/388255 Wed, 18 Jan 2023 09:44:28 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/328500 Wed, 18 Jan 2023 03:55:34 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/385798 Wed, 18 Jan 2023 00:00:01 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/383889 Tue, 17 Jan 2023 22:40:02 +0000 https://gitlab.com/gitlab-org/charts/gitlab/-/issues/4097 merge request that introduces the `global.kas.tls.*` values. - The deprecated `gitlab.kas.privateApi.tls.*` documentation. - The new `global.kas.tls.*` documentation. ]]> Tue, 17 Jan 2023 17:04:55 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/343988 Tue, 17 Jan 2023 16:52:51 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/211643 Cloud Native Buildpacks. You should migrate your builds from Herokuish to Cloud Native Buildpacks. From GitLab 14.0, Auto Build uses Cloud Native Buildpacks by default. Because Cloud Native Buildpacks do not support automatic testing, the Auto Test feature of Auto DevOps is also deprecated. ]]> Tue, 17 Jan 2023 16:39:36 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/388269 Tue, 17 Jan 2023 16:28:03 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/386001 quickstart and the base templates. Because the new templates ship with default rules, the update might break your Terraform pipelines. For example, if your Terraform jobs are triggered as a downstream pipeline, the rules won't trigger your jobs in GitLab 16.0. To accommodate the changes, you might need to adjust the `rules` in your `.gitlab-ci.yml` file. ]]> Tue, 17 Jan 2023 15:39:25 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/382129 Cluster Agents API endpoints can return revoked tokens. In GitLab 16.0, GET requests will not return revoked tokens. You should review your calls to these endpoints and ensure you do not use revoked tokens. This change affects the following REST and GraphQL API endpoints: - REST API: - List tokens - Get a single token - GraphQL: - `ClusterAgent.tokens` ]]> Tue, 17 Jan 2023 15:21:30 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/385636 Mon, 16 Jan 2023 15:25:53 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/365939 Mon, 16 Jan 2023 11:27:50 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/387891 Mon, 16 Jan 2023 12:38:31 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/387721 Thu, 12 Jan 2023 17:59:45 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/387751 Thu, 12 Jan 2023 06:52:09 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/387560 Oracle support policy as Oracle Premier and Extended Support for these versions has ended. This also allows GitLab to focus dependency scanning Java support on LTS versions moving forward. ]]> Tue, 10 Jan 2023 05:01:12 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/370471 Allowing or preventing duplicate package uploads. - Package request forwarding. - Enabling lifecycle rules for the Dependency Proxy. In GitLab 17.0 and later, you must have the Owner role for a group to change the **Packages and registries** settings for the group using either the GitLab UI or GraphQL API. ]]> Thu, 5 Jan 2023 21:31:29 +0000 https://gitlab.com/gitlab-org/container-registry/-/issues/854 /`. We have maintained this legacy behavior to support older deployments using this storage driver. However, when moving to Azure from another storage driver, this behavior hides all your data until you configure the storage driver to build root paths without an extra leading slash by setting `trimlegacyrootprefix: true`. The new default configuration for the storage driver will set `trimlegacyrootprefix: true`, and `/` will be the default root directory. You can add `trimlegacyrootprefix: false` to your current configuration to avoid any disruptions. This breaking change will happen in GitLab 16.0. ]]> Thu, 5 Jan 2023 20:11:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/384455 project-level or instance-level endpoints. Each level supports the Conan search command. However, the search endpoint for the project level is also returning packages from outside the target project. This unintended functionality is deprecated in GitLab 15.8 and will be removed in GitLab 16.0. The search endpoint for the project level will only return packages from the target project. ]]> Thu, 5 Jan 2023 00:35:48 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/376216 end of support is scheduled for GitLab 16.0. This impacts users on GitLab Self-Managed that have connected their external registry to the GitLab user interface to find, view, and delete container images. Supporting both the GitLab container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility, and hinders our ability to stay efficient. As a result we will not support this functionality moving forward. This change will not impact your ability to pull and push container images to external registries using pipelines. Since we released the new GitLab container registry version for GitLab.com, we've started to implement additional features that are not available in third-party container registries. These new features have allowed us to achieve significant performance improvements, such as cleanup policies. We are focusing on delivering new features, most of which will require functionalities only available on the GitLab container registry. This deprecation allows us to reduce fragmentation and user frustration in the long term by focusing on delivering a more robust integrated registry experience and feature set. Moving forward, we'll continue to invest in developing and releasing new features that will only be available in the GitLab container registry. ]]> Wed, 4 Jan 2023 21:01:04 +0000 https://gitlab.com/gitlab-org/container-registry/-/issues/842 pull-through cache is deprecated in GitLab 15.8 and will be removed in GitLab 16.0. The pull-through cache is part of the upstream Docker Distribution project. However, we are removing the pull-through cache in favor of the GitLab Dependency Proxy, which allows you to proxy and cache container images from Docker Hub. Removing the pull-through cache allows us also to remove the upstream client code without sacrificing functionality. ]]> Wed, 4 Jan 2023 19:55:34 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/385564 adds full support for state names that contain periods. If you used a workaround to handle these state names, your jobs might fail, or it might look like you've run Terraform for the first time. To resolve the issue: 1. Change any references to the state file by excluding the period and any characters that follow. - For example, if your state name is `state.name`, change all references to `state`. 1. Run your Terraform commands. To use the full state name, including the period, migrate to the full state file. ]]> Thu, 15 Dec 2022 21:43:25 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/385235 simulation are available in the GitLab pipeline editor. ]]> Wed, 14 Dec 2022 08:57:59 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/383467 Wed, 14 Dec 2022 02:15:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/384340 Wed, 14 Dec 2022 00:36:42 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/384198 DAST API analyzer documentation for configuration details. ]]> Tue, 13 Dec 2022 23:44:47 +0000 https://gitlab.com/gitlab-com/Product/-/issues/4894 Fri, 9 Dec 2022 15:58:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/377824 Thu, 8 Dec 2022 13:05:21 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/383467 Tue, 29 Nov 2022 04:03:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/381669 `POST /projects/:id/ci/lint`, which properly validates CI/CD configuration. ]]> Thu, 24 Nov 2022 16:30:28 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/383039 GitLab Helm Chart. This port is used for much more than just metrics, which warranted this change to avoid confusion in configuration. ]]> Wed, 23 Nov 2022 21:31:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/379064 specify any runner configuration in the GitLab Runner Helm chart. When we implemented this feature, we deprecated values in the GitLab Helm Chart configuration that were specific to GitLab Runner. The deprecated values will be removed in GitLab 16.0. ]]> Thu, 10 Nov 2022 08:25:13 -0500 https://gitlab.com/gitlab-org/gitlab/-/issues/353097 `/approval_rules` endpoint to create or update the approval rules for a merge request. ]]> Wed, 9 Nov 2022 20:52:03 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/29407 Thu, 20 Oct 2022 10:44:58 -0600 https://gitlab.com/gitlab-org/gitlab/-/issues/371485 Fri, 14 Oct 2022 10:53:46 +0200 https://gitlab.com/gitlab-org/gitlab/-/issues/375645 deprecated in 15.3). Users should instead use `VulnerabilityDismiss` to dismiss vulnerabilities in the Vulnerability Report or `SecurityFindingDismiss` for security findings in the CI Pipeline Security tab. ]]> Wed, 12 Oct 2022 16:48:58 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/372332 security report schemas below version 15 were deprecated. The `confidence` attribute on vulnerability findings exists only in schema versions before `15-0-0`, and therefore is effectively deprecated because GitLab 15.4 supports schema version `15-0-0`. To maintain consistency between the reports and our public APIs, the `confidence` attribute on any vulnerability-related components of our GraphQL API is now deprecated and will be removed in 17.0. ]]> Tue, 13 Sep 2022 19:05:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/365365 Tue, 13 Sep 2022 18:19:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/368828 Mon, 12 Sep 2022 21:23:23 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/371840 new variable names `CS_IMAGE`, `CS_REGISTRY_PASSWORD`, `CS_REGISTRY_USER`, and `CS_DOCKERFILE_PATH` in place of the deprecated names. ]]> Mon, 12 Sep 2022 18:08:37 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/369122 populate a default expiration date. In GitLab 16.0, any personal, project, or group access token that does not have an expiration date will automatically have an expiration date set at one year. We recommend giving your access tokens an expiration date in line with your company's security policies before the default is applied: - On GitLab.com during the 16.0 milestone. - On GitLab Self-Managed when they are upgraded to 16.0. ]]> Fri, 2 Sep 2022 00:26:50 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/367166 Thu, 18 Aug 2022 09:32:50 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/366477 security report schemas are deprecated. In GitLab 15.8 and later, security report scanner integrations that use schema version 14.x.x will display a deprecation warning in the pipeline's **Security** tab. In GitLab 16.0 and later, the feature will be removed. Security reports that use schema version 14.x.x will cause an error in the pipeline's **Security** tab. For more information, refer to security report validation. ]]> Tue, 16 Aug 2022 22:55:19 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/331468 was updated to Redis 6. Redis 5 has reached the end of life in April 2022 and will no longer be supported as of GitLab 15.6. If you are using your own Redis 5.0 instance, you should upgrade it to Redis 6.0 or higher before upgrading to GitLab 16.0 or higher. ]]> Sat, 13 Aug 2022 08:34:55 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/369127 upgrading to OmniAuth 2.0. ]]> Wed, 10 Aug 2022 01:04:06 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/334253 Wed, 13 Jul 2022 08:00:45 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/343475 `project_fingerprint` attribute of vulnerability findings is being deprecated in favor of a `uuid` attribute. By using UUIDv5 values to identify findings, we can easily associate any related entity with a finding. The `project_fingerprint` attribute is no longer being used to track findings, and will be removed in GitLab 17.0. Starting in 16.1, the output of `project_fingerprint` returns the same value as the `uuid` field. ]]> Fri, 10 Jun 2022 18:33:08 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/346335 `PipelineSecurityReportFinding` GraphQL type was updated to include a new `title` field. This field is an alias for the current `name` field, making the less specific `name` field redundant. The `name` field will be removed from the `PipelineSecurityReportFinding` type in GitLab 16.0. ]]> Fri, 10 Jun 2022 18:33:08 +0000 https://gitlab.com/groups/gitlab-org/-/epics/7508 Jira DVCS connector for Jira Cloud has been deprecated and will be removed in GitLab 16.0. If you're using the Jira DVCS connector with Jira Cloud, migrate to the GitLab for Jira Cloud app. The Jira DVCS connector is also deprecated for Jira 8.13 and earlier. You can only use the Jira DVCS connector with Jira Server or Jira Data Center in Jira 8.14 and later. ]]> Wed, 8 Jun 2022 16:05:25 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/349185 Wed, 11 May 2022 15:32:28 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85438 the most up-to-date Long Term Support (LTS) version. Dependency scanning continues to support the same range of versions (8, 11, 13, 14, 15, 16, 17), only the default version is changing. If your project uses the previous default of Java 11, be sure to set the `DS_Java_Version` variable to match. ]]> Wed, 20 Apr 2022 20:35:52 +0000 https://gitlab.com/groups/gitlab-org/configure/-/epics/8 deprecated and removed. As a GitLab.com user, on new namespaces, you will no longer be able to integrate GitLab and your cluster using the certificate-based approach as of GitLab 15.0. The integration for current users will be enabled per namespace. For a more robust, secure, forthcoming, and reliable integration with Kubernetes, we recommend you use the agent for Kubernetes to connect Kubernetes clusters with GitLab. How do I migrate? For updates and details about this deprecation, follow this epic. GitLab Self-Managed customers can still use the feature with a feature flag. ]]> Wed, 20 Apr 2022 18:57:52 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/359133 upgrade documentation for details. ]]> Mon, 18 Apr 2022 12:33:00 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/350670 Fri, 8 Apr 2022 20:45:34 +0200 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83220 API field is deprecated in GitLab 14.9 and removed in GitLab 16.7. Until the feature is removed, `user_email_lookup_limit` is aliased to `search_rate_limit` and existing workflows still work. Any API calls to change the rate limits for `user_email_lookup_limit` must use `search_rate_limit` instead. ]]> Tue, 22 Mar 2022 15:57:07 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/26600 object storage feature, support for using `background_upload` to upload files is deprecated and will be fully removed in GitLab 15.0. Review the 15.0 specific changes for the removed background uploads settings for object storage. This impacts a small subset of object storage providers: - **OpenStack** Customers using OpenStack need to change their configuration to use the S3 API instead of Swift. - **RackSpace** Customers using RackSpace-based object storage need to migrate data to a different provider. GitLab will publish additional guidance to assist affected customers in migrating. ]]> Tue, 22 Mar 2022 14:10:45 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82852 Tue, 15 Mar 2022 20:19:59 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82646 Package Registry settings - Container registry cleanup policy - Dependency Proxy time-to-live policy - Enabling the Dependency Proxy for your group ]]> Mon, 14 Mar 2022 21:11:51 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82652 authentication with `htpasswd`. It relies on an Apache `htpasswd` file, with passwords hashed using `bcrypt`. Since it isn't used in the context of GitLab (the product), `htpasswd` authentication will be deprecated in GitLab 14.9 and removed in GitLab 15.0. ]]> Fri, 11 Mar 2022 23:58:13 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/348909 Fri, 4 Mar 2022 19:03:41 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80873 `PipelineSecurityReportFinding` GraphQL object is being deprecated. This field contains a "fingerprint" of security findings used to determine uniqueness. The method for calculating fingerprints has changed, resulting in different values. Going forward, the new values will be exposed in the UUID field. Data previously available in the `projectFingerprint` field will eventually be removed entirely. ]]> Thu, 17 Feb 2022 08:35:13 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/350936 maintenance policy. As required security patches will be backported within the latest 3 minor releases. Specifically, the following are being deprecated and will no longer be updated after 15.0 GitLab release: - API security: version 1 - Container scanning: version 4 - Coverage-guided fuzz testing: version 2 - Dependency scanning: version 2 - Dynamic application security testing (DAST): version 2 - Infrastructure as Code (IaC) scanning: version 1 - License scanning: version 3 - Secret detection: version 3 - Static application security testing (SAST): version 2 of all analyzers, except `gosec` which is currently at version 3 - `bandit`: version 2 - `brakeman`: version 2 - `eslint`: version 2 - `flawfinder`: version 2 - `gosec`: version 3 - `kubesec`: version 2 - `mobsf`: version 2 - `nodejs-scan`: version 2 - `phpcs-security-audit`: version 2 - `pmd-apex`: version 2 - `security-code-scan`: version 2 - `semgrep`: version 2 - `sobelow`: version 2 - `spotbugs`: version 2 ]]> Thu, 17 Feb 2022 06:26:29 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/352564 analyzers to scan for security vulnerabilities. Each analyzer is distributed as a container image. Starting in GitLab 14.8, new versions of GitLab Secure and Protect analyzers are published to a new registry location under `registry.gitlab.com/security-products`. We will update the default value of GitLab-managed CI/CD templates to reflect this change: - For all analyzers except container scanning, we will update the variable `SECURE_ANALYZERS_PREFIX` to the new image registry location. - For container scanning, the default image address is already updated. There is no `SECURE_ANALYZERS_PREFIX` variable for container scanning. In a future release, we will stop publishing images to `registry.gitlab.com/gitlab-org/security-products/analyzers`. Once this happens, you must take action if you manually pull images and push them into a separate registry. This is commonly the case for offline deployments. Otherwise, you won't receive further updates. See the deprecation issue for more details. ]]> Thu, 17 Feb 2022 02:23:46 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/262019 Wed, 16 Feb 2022 18:10:40 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/352957 predefined variables which are functionally identical: | Removed variable | Replacement variable | | --------------------- |------------------------ | | `CI_BUILD_BEFORE_SHA` | `CI_COMMIT_BEFORE_SHA` | | `CI_BUILD_ID` | `CI_JOB_ID` | | `CI_BUILD_MANUAL` | `CI_JOB_MANUAL` | | `CI_BUILD_NAME` | `CI_JOB_NAME` | | `CI_BUILD_REF` | `CI_COMMIT_SHA` | | `CI_BUILD_REF_NAME` | `CI_COMMIT_REF_NAME` | | `CI_BUILD_REF_SLUG` | `CI_COMMIT_REF_SLUG` | | `CI_BUILD_REPO` | `CI_REPOSITORY_URL` | | `CI_BUILD_STAGE` | `CI_JOB_STAGE` | | `CI_BUILD_TAG` | `CI_COMMIT_TAG` | | `CI_BUILD_TOKEN` | `CI_JOB_TOKEN` | | `CI_BUILD_TRIGGERED` | `CI_PIPELINE_TRIGGERED` | ]]> Wed, 16 Feb 2022 22:48:48 +0900 https://gitlab.com/gitlab-org/gitlab/-/issues/352553 severity values for vulnerabilities along with other new features and improvements. - Removes .NET 2.1 support. - Adds support for .NET 6.0, Visual Studio 2019, and Visual Studio 2022. Version 3 was announced in GitLab 14.6 and made available as an optional upgrade. If you rely on .NET 2.1 support being present in the analyzer image by default, you must take action as detailed in the deprecation issue for this change. ]]> Wed, 16 Feb 2022 04:12:42 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/352554 analyzers to scan code for vulnerabilities. We are reducing the number of analyzers used in GitLab SAST as part of our long-term strategy to deliver a better and more consistent user experience. Streamlining the set of analyzers will also enable faster iteration, better results, and greater efficiency (including a reduction in CI runner usage in most cases). In GitLab 15.4, GitLab SAST will no longer use the following analyzers: - ESLint (JavaScript, TypeScript, React) - Gosec (Go) - Bandit (Python) > [!note] > This change was originally planned for GitLab 15.0 and was postponed to GitLab 15.4. These analyzers will be removed from the GitLab-managed SAST CI/CD template and replaced with the Semgrep-based analyzer. Effective immediately, they will receive only security updates; other routine improvements or updates are not guaranteed. After these analyzers reach End of Support, no further updates will be provided. We will not delete container images previously published for these analyzers; any such change would be announced as a deprecation, removal, or breaking change announcement. We will also remove Java from the scope of the SpotBugs analyzer and replace it with the Semgrep-based analyzer. This change will make it simpler to scan Java code; compilation will no longer be required. This change will be reflected in the automatic language detection portion of the GitLab-managed SAST CI/CD template. Note that the SpotBugs-based analyzer will continue to cover Groovy, Kotlin, and Scala. If you've already dismissed a vulnerability finding from one of the deprecated analyzers, the replacement attempts to respect your previous dismissal. The system behavior depends on: - whether you've excluded the Semgrep-based analyzer from running in the past. - which analyzer first discovered the vulnerabilities shown in the project's Vulnerability Report. See Vulnerability translation documentation for further details. If you applied customizations to any of the affected analyzers or if you currently disable the Semgrep analyzer in your pipelines, you must take action as detailed in the deprecation issue for this change. ]]> Wed, 16 Feb 2022 03:33:13 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/352549 GitLab SAST SpotBugs analyzer scans Java, Scala, Groovy, and Kotlin code for security vulnerabilities. For technical reasons, the analyzer must first compile the code before scanning. Unless you use the pre-compilation strategy, the analyzer attempts to automatically compile your project's code. In GitLab versions prior to 15.0, the analyzer image includes Java 8 and Java 11 runtimes to facilitate compilation. In GitLab 15.0, we will: - Remove Java 8 from the analyzer image to reduce the size of the image. - Add Java 17 to the analyzer image to make it easier to compile with Java 17. If you rely on Java 8 being present in the analyzer environment, you must take action as detailed in the deprecation issue for this change. ]]> Wed, 16 Feb 2022 02:56:55 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80199 required pipeline configuration feature is deprecated in GitLab 14.8 for Premium customers and is scheduled for removal in GitLab 15.0. This feature is not deprecated for GitLab Ultimate customers. This change to move the feature to GitLab Ultimate tier is intended to help our features better align with our pricing philosophy as we see demand for this feature originating primarily from executives. This change will also help GitLab remain consistent in its tiering strategy with the other related Ultimate-tier features of: Security policies and compliance framework pipelines. ]]> Wed, 16 Feb 2022 11:22:24 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/350510 Tue, 15 Feb 2022 22:22:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/257883 deprecation issue. You can test if this change affects you by validating your queries locally, using schema data fetched from a GitLab server. You can do this by using the GraphQL explorer tool for the relevant GitLab instance. For example: `https://gitlab.com/-/graphql-explorer`. For example, the following query illustrates the breaking change: ```graphql # a query using the deprecated type of Query.issue(id:) # WARNING: This will not work after GitLab 15.0 query($id: ID!) { deprecated: issue(id: $id) { title, description } } ``` The query above will not work after GitLab 15.0 is released, because the type of `Query.issue(id:)` is actually `IssueID!`. Instead, you should use one of the following two forms: ```graphql # This will continue to work query($id: IssueID!) { a: issue(id: $id) { title, description } b: issue(id: "gid://gitlab/Issue/12345") { title, description } } ``` This query works now, and will continue to work after GitLab 15.0. You should convert any queries in the first form (using `ID` as a named type in the signature) to one of the other two forms (using the correct appropriate type in the signature, or using an inline argument expression). ]]> Tue, 15 Feb 2022 15:03:38 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79178 opt in to expiring tokens before GitLab 15.0 is released: 1. Edit the application. 1. Select **Expire access tokens** to enable them. Tokens must be revoked or they don't expire. ]]> Tue, 15 Feb 2022 05:11:20 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/352609 deprecated. These variables are being replaced with standard `config.toml` Gitaly configuration. GitLab instances that use `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` to configure Gitaly should switch to configuring using `config.toml`. ]]> Tue, 15 Feb 2022 04:32:12 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80283 deprecated. If you currently use a gRPC-aware proxy for Gitaly connections, you should change your proxy configuration to use TCP or TLS proxying (OSI layer 4) instead. Gitaly Cluster became incompatible with gRPC-aware proxies in GitLab 13.12. Now all GitLab installations will be incompatible with gRPC-aware proxies, even without Gitaly Cluster. By sending some of our internal RPC traffic through a custom protocol (instead of gRPC) we increase throughput and reduce Go garbage collection latency. For more information, see the relevant epic. ]]> Mon, 14 Feb 2022 00:08:46 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/350275 plan to support in GitLab 15.0. ]]> Fri, 11 Feb 2022 19:08:19 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/352488 Request profiling is deprecated in GitLab 14.8 and scheduled for removal in GitLab 15.0. We're working on consolidating our profiling tools and making them more easily accessible. We evaluated the use of this feature and we found that it is not widely used. It also depends on a few third-party gems that are not actively maintained anymore, have not been updated for the latest version of Ruby, or crash frequently when profiling heavy page loads. For more information, check the summary section of the deprecation issue. ]]> Fri, 11 Feb 2022 17:59:36 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/334060 supported version and 3.6 is no longer supported. For users using Python 3.9 or 3.9-compatible projects, you should not need to take action and dependency scanning should begin to work in GitLab 15.0. If you wish to test the new container now please run a test pipeline in your project with this container (which will be removed in 15.0). Use the Python 3.9 image: ```yaml gemnasium-python-dependency_scanning: image: name: registry.gitlab.com/gitlab-org/security-products/analyzers/gemnasium-python:2-python-3.9 ``` For users using Python 3.6, as of GitLab 15.0 you will no longer be able to use the default template for dependency scanning. You will need to switch to use the deprecated `gemnasium-python:2` analyzer image. If you are impacted by this please comment in this issue so we can extend the removal if needed. For users using the 3.9 special exception image, you must instead use the default value and no longer override your container. To verify if you are using the 3.9 special exception image, check your `.gitlab-ci.yml` file for the following reference: ```yaml gemnasium-python-dependency_scanning: image: name: registry.gitlab.com/gitlab-org/security-products/analyzers/gemnasium-python:2-python-3.9 ``` ]]> Fri, 11 Feb 2022 05:23:33 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79698 AppArmor, Cilium, Falco, FluentD, Pod Security Admission. To integrate these technologies into GitLab, add the desired Helm charts into your copy of the Cluster Management Project Template. Deploy these Helm charts in production by calling commands through GitLab CI/CD. As part of this change, the following specific capabilities within GitLab are now deprecated, and are scheduled for removal in GitLab 15.0: - The **Security & Compliance** > **Threat Monitoring** page. - The `Network Policy` security policy type, as found on the **Security & Compliance** > **Policies** page. - The ability to manage integrations with the following technologies through GitLab: AppArmor, Cilium, Falco, FluentD, and Pod Security Policies. - All APIs related to the above functionality. For additional context, or to provide feedback regarding this change, please reference our open deprecation issue. ]]> Mon, 7 Feb 2022 18:55:39 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79988 project setting for test coverage parsing is being removed. Instead, using the project's `.gitlab-ci.yml`, provide a regular expression with the `coverage` keyword to set testing coverage results in merge requests. ]]> Mon, 7 Feb 2022 07:57:08 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/351963 Fri, 4 Feb 2022 12:23:09 +1000 https://gitlab.com/gitlab-org/gitlab/-/issues/351962 Fri, 4 Feb 2022 10:50:03 +1000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79250 external status check API was originally implemented to support pass-by-default requests to mark a status check as passing. Pass-by-default requests are now deprecated. Specifically, the following are deprecated: - Requests that do not contain the `status` field. - Requests that have the `status` field set to `approved`. Beginning in GitLab 15.0, status checks will only be updated to a passing state if the `status` field is both present and set to `passed`. Requests that: - Do not contain the `status` field will be rejected with a `422` error. For more information, see the relevant issue. - Contain any value other than `passed` will cause the status check to fail. For more information, see the relevant issue. To align with this change, API calls to list external status checks will also return the value of `passed` rather than `approved` for status checks that have passed. ]]> Mon, 31 Jan 2022 22:26:18 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/332323 Mon, 31 Jan 2022 11:49:38 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78949 supported OAuth flows. ]]> Thu, 27 Jan 2022 02:00:21 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79254 **Policies** and creating a new Scan Result Policy. The new security approvals feature is similar to vulnerability check. For example, both can require approvals for MRs that contain security vulnerabilities. However, security approvals improve the previous experience in several ways: - Users can choose who is allowed to edit security approval rules. An independent security or compliance team can therefore manage rules in a way that prevents development project maintainers from modifying the rules. - Multiple rules can be created and chained together to allow for filtering on different severity thresholds for each scanner type. - A two-step approval process can be enforced for any desired changes to security approval rules. - A single set of security policies can be applied to multiple development projects to allow for ease in maintaining a single, centralized ruleset. ]]> Wed, 26 Jan 2022 23:32:27 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/334018 iterations GraphQL API and iterations REST API is deprecated. The GraphQL API version will be removed in GitLab 16.0. This state is being replaced with the `current` state (already available) which aligns with the naming for other time-based entities, such as milestones. We plan to continue to support the `started` state in REST API version until the next v5 REST API version. ]]> Mon, 24 Jan 2022 12:19:43 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/347509 metrics and health checks from two separate processes to improve stability and availability and prevent data loss in edge cases. As those are two separate servers, a configuration change will be required in 15.0 to explicitly set separate ports for metrics and health-checks. The newly introduced settings for `sidekiq['health_checks_*']` should always be set in `gitlab.rb`. For more information, check the documentation for configuring Sidekiq. These changes also require updates in either Prometheus to scrape the new endpoint or k8s health-checks to target the new health-check port to work properly, otherwise either metrics or health-checks will disappear. For the deprecation period those settings are optional and GitLab will default the Sidekiq health-checks port to the same port as `sidekiq_exporter` and only run one server (not changing the current behavior). Only if they are both set and a different port is provided, a separate metrics server will spin up to serve the Sidekiq metrics, similar to the way Sidekiq will behave in 15.0. ]]> Mon, 17 Jan 2022 12:59:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/348980 `artifacts:reports:coverage_report`. Cobertura will be the only supported report file in 15.0, but this is the first step towards GitLab supporting other report types. ]]> Thu, 13 Jan 2022 23:06:39 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/346540 Opstrace integration with GitLab. ]]> Wed, 12 Jan 2022 21:49:32 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/346541 Opstrace. An issue exists for you to follow work on the Opstrace integration. ]]> Wed, 12 Jan 2022 18:56:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/346485 integrating Opstrace with GitLab. ]]> Wed, 12 Jan 2022 18:36:50 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/335707 Fri, 10 Dec 2021 00:47:46 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/289832 Thu, 9 Dec 2021 22:16:15 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76325 Thu, 9 Dec 2021 11:10:55 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/333233 Wed, 1 Dec 2021 03:41:35 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/342800 Mon, 22 Nov 2021 02:30:49 +0000 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74631 ended on March 31, 2021. The CA certificates on SP2 include the expired DST root certificate, and it's not getting new CA certificate package updates. We have implemented some workarounds, but we will not be able to continue to keep the build running properly. ]]> Wed, 17 Nov 2021 02:26:47 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/342882 `PackageDetailsType` to get the pipelines for package versions: - The `versions` field's `pipelines` field. This returns all the pipelines associated with all the package's versions, which can pull an unbounded number of objects in memory and create performance concerns. - The `pipelines` field of a specific `version`. This returns only the pipelines associated with that single package version. To mitigate possible performance problems, we will remove the `versions` field's `pipelines` field in milestone 15.0. Although you will no longer be able to get all pipelines for all versions of a package, you can still get the pipelines of a single version through the remaining `pipelines` field for that version. ]]> Mon, 15 Nov 2021 18:03:05 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/336912 gets registry repositories from a group. The `GET /groups/:id/registry/repositories` endpoint will remain, but won't return any info about tags. To get the info about tags, you can use the existing `GET /registry/repositories/:id` endpoint, which will continue to support the `tags` and `tag_count` options as it does today. The latter must be called once per image repository. ]]> Fri, 12 Nov 2021 23:54:04 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/343210 Fri, 12 Nov 2021 12:38:10 +0000 https://gitlab.com/groups/gitlab-org/configure/-/epics/8 will be deprecated and removed. For GitLab Self-Managed, we are introducing the feature flag `certificate_based_clusters` in GitLab 15.0 so you can keep your certificate-based integration enabled. However, the feature flag will be disabled by default, so this change is a **breaking change**. For a more robust, secure, forthcoming, and reliable integration with Kubernetes, use the agent for Kubernetes to connect Kubernetes clusters with GitLab. For information about this migration, see migrate to agent for Kubernetes. GitLab will not remove this feature until the new solution has feature parity. For more information about the blockers to removal, see issue 199. For updates and details about this deprecation, see epic 8. ]]> Fri, 12 Nov 2021 06:15:17 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/345451 Thu, 11 Nov 2021 22:48:20 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/345207 Thu, 11 Nov 2021 03:18:37 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/345207 Thu, 11 Nov 2021 03:18:37 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/345347 Wed, 10 Nov 2021 22:44:01 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/289956 Wed, 10 Nov 2021 21:41:17 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/276777 GitLab-#11582 changed how public groups use the Dependency Proxy. Prior to this change, you could use the Dependency Proxy without authentication. The change requires authentication to use the Dependency Proxy. In milestone 15.0, we will remove the feature flag entirely. Moving forward, you must authenticate when using the Dependency Proxy. ]]> Wed, 10 Nov 2021 19:40:09 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/327453 Package Registry GraphQL API, the Package group deprecated the `Version` type for the basic `PackageType` type and moved it to `PackageDetailsType`. In milestone 15.0, we will completely remove `Version` from `PackageType`. ]]> Wed, 10 Nov 2021 18:58:24 +0000 https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28192 GitLab 14.3, we added a configuration setting in the GitLab Runner `config.toml` file. This setting, [`[runners.ssh.disable_strict_host_key_checking]`](https://docs.gitlab.com/runner/executors/ssh/#security), controls whether or not to use strict host key checking with the SSH executor. In GitLab 15.0 and later, the default value for this configuration option will change from `true` to `false`. This means that strict host key checking will be enforced when using the GitLab Runner SSH executor. ]]> Tue, 9 Nov 2021 20:50:23 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/344648 Thu, 4 Nov 2021 10:17:03 +0100 https://gitlab.com/groups/gitlab-org/configure/-/epics/6 Thu, 16 Sep 2021 09:09:02 +0900 https://gitlab.com/gitlab-org/gitlab/-/issues/337384 SPNEGO integration instead. You can follow the upgrade instructions to upgrade from the `omniauth-kerberos` integration to the supported one. Note that we are not deprecating the Kerberos SPNEGO integration, only the old password-based Kerberos integration. ]]> Wed, 15 Sep 2021 23:41:32 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/338182 GitLabs database configuration located in `database.yml` is changing and the legacy format is deprecated. The legacy format supported using a single PostgreSQL adapter, whereas the new format is changing to support multiple databases. The `main:` database needs to be defined as a first configuration item. This deprecation mainly impacts users compiling GitLab from source because Omnibus will handle this configuration automatically. ]]> Wed, 15 Sep 2021 16:52:41 +0000 https://gitlab.com/gitlab-org/gitlab/-/issues/337993 Tue, 14 Sep 2021 19:06:13 +0000