16.0 - Assess Breaking Changes Impact & Plan for Next Steps
Team @gl-product
, we are working to understand the impact of the breaking changes that are coming in 16.0 in partnership with #s_platforms #customer_success and support. PMs, please take a look at the following gdoc (https://docs.google.com/spreadsheets/d/1IPCtaVtCwLEm25AnzpOJIHSbWSZhNJ_SIcKoIvo0faA/edit#gid=0&fvid=133932296)
- Identify the breaking changes that you are responsible for
- Update the highlighted columns for your stage/change
- Reach
- Impact
- How to assess for impact
- How to adjust
This is an urgent request. Please complete this by 2023–03–13 17:00 UTC. Communicating potentially disruptive changes to customers is crucial in the lead up to a major release. We have 94 breaking changes in 16.0, more than the previous two versions and continuing to grow.
Deploying breaking changes now can severely impact our GitLab.com customers because they have no time to prepare for those changes. Here is a customer voice that provides some color on the negative impact of announced breaking changes: https://hello.chorus.ai/listen?guid=189829120491441b98999ed99bc53dc9
How do I fill in the fields
N.B. if the below categories are not sufficient, pleases suggest more as a comment to this issue
Reach - Think about reach by considering how many customers we are going to impact with this breaking change
- All Customers
- Some Customers
- Few Customers
Impact - Think about impact by considering the level or scope that the change will affect
- Organization level
- Group Level
- Project Level
- User Level
How to assess for impact - Here you should suggest how the customer can assess what the level of impact will be for them.
I.e. The user has to make a change at the project level and the customer has 4000 projects, how will they assess which of their projects are going to be impacted by this breaking change?
How to adjust - Do we have any tools or automated scripts that the customer can use to make their transition easier. Are there guides and documentation? Link them here so support can find them.
I filtered the doc on my id/stage - how do I get back to the summary view?
I’ve created a filter view that should make returning to the summary view easy if you load the sheet and it only contains one stage. Just apply the filter view back to your results
Noteable breaking changes by stage (Not a complete list - gdoc is SSOT)
I have tagged the reporters from the gdoc so if you need to take action you should be pinged here. However, some of the reporter information is missing / will be out of date now so please double check your stage and forward to the right person as necessary.
Plan / Manage
-
@lohrc -
No Reporter -
@Andysoiron -
@arturoherrero -
@adil.farrukh -
@hsutor -
@hsnir1 -
@nicolasdular -
@m_frankiewicz
-
environment_tier
parameter for DORA API - GraphQL field
confidential
changed tointernal
on notes - Option to delete projects immediately is deprecated from deletion protection settings
- Limit personal access token and deploy token's access with external authorization
- Test system hook endpoint
- Null value for
private_profile
attribute in User API is deprecated - Developer role providing the ability to import projects to a group
- Cookie authorization in the GitLab for Jira Cloud app
- Rake task for importing bare repositories
- GitLab.com importer
- Shimo integration
- ZenTao integration
- The Phabricator task importer is deprecated
- Non-expiring access tokens
- Atlassian Crowd OmniAuth provider
- CAS OmniAuth provider
- Jira GitHub Enterprise DVCS integration
Create
-
No Reporter -
Legacy URLs replaced or removed
-
Approvers and Approver Group fields in Merge Request Approval API
-
Single merge request changes API endpoint
-
merge_status API field
-
Toggle behavior of
/draft
quick action in merge requests -
merged_by API field
-
Changing merge request approvals with the
/approvals
API endpoint
Verify
-
HashiCorp Vault integration will no longer use CI_JOB_JWT by default. Affects customers using Vault integration. Each project with a Vault integration will need to modify the CI file.
- Any projects that use the secrets:vault keyword to retrieve secrets from Vault will need to be configured to use ID tokens.
- TODO: Develop script to analyze/modify each project ci file
- Toggle notes confidentiality on APIs
- Remove offset pagination from Jobs API
- Trigger jobs can mirror downstream pipeline status exactly
- Default CI/CD job token (
CI_JOB_TOKEN
) scope changed - Enforced validation of CI/CD parameter character lengths
- Required Pipeline Configuration is deprecated
- Old versions of JSON web tokens are deprecated
- CI/CD jobs will fail when no secret is returned from Hashicorp Vault
- GraphQL: The
DISABLED_WITH_OVERRIDE
value of theSharedRunnersSetting
enum is deprecated. UseDISABLED_AND_OVERRIDABLE
instead -
POST ci/lint
API endpoint deprecated - Configuration fields in GitLab Runner Helm Chart
- Maximum number of active pipelines per project limit (
ci_active_pipelines
) - Remove
job_age
parameter fromPOST /jobs/request
Runner endpoint - REST API Runner maintainer_note
- CiCdSettingsUpdate mutation renamed to ProjectCiCdSettingsUpdate
- GraphQL API legacyMode argument for Runner status
- GraphQL API Runner will not accept
status
filter values ofactive
orpaused
-
CI_BUILD_*
predefined variables - REST and GraphQL API Runner usage of
active
replaced bypaused
- GraphQL API Runner status will not return
paused
Secure
- License Compliance CI Template
- Dependency Scanning support for Java 13, 14, 15, and 16
- Container Scanning variables that reference Docker
- Starboard directive in the config for the GitLab Agent for Kubernetes
- The change in behavior for the SAST_DISABLED and other vars disabling scanners is huge and will have a positive impact for compliance enforcement; up to this point there was no ability to prevent projects from using these vars to bypass security scans mandated by a compliance pipeline or scan execution policy. This change doesn’t fully resolve that, but it opens the ability for true enforcement with some additional CI template modifications.
- SAST analyzer coverage changing in GitLab 16.0
- DAST API variables
- DAST ZAP advanced configuration variables deprecation
- DAST report variables deprecation
- DAST API scans using DAST template is deprecated
- Use of
id
field in vulnerabilityFindingDismiss mutation - Security report schemas version 14.x.x
- project.pipeline.securityReportFindings GraphQL query
- PipelineSecurityReportFinding projectFingerprint GraphQL field
- PipelineSecurityReportFinding name GraphQL field
Package
- Azure Storage Driver defaults to the correct root prefix
- Maintainer role providing the ability to change Package settings using GraphQL API
- Conan project-level search endpoint returns project-specific results
- Container Registry pull-through cache
- Support for third party registries
- Package pipelines in API payload is paginated
Release
- External field in GraphQL ReleaseAssetLink type
- External field in Releases and Release Links APIs
- Projects API field
operations_access_level
is deprecated - Deployment API returns error when
updated_at
andupdated_at
are not used together
Configure
-
Auto DevOps no longer provisions a PostgreSQL database by default
- Low impact - changes default behavior - customers can still opt in
-
The API no longer returns revoked tokens for the agent for Kubernetes
-
The latest Terraform templates will overwrite current stable templates
-
KAS Metrics Port in GitLab Helm Chart
-
Support for periods (
.
) in Terraform state names might break existing states
Monitor
- Embedding Grafana panels in Markdown is deprecated
- Error Tracking UI in GitLab Rails is deprecated
- Embedding Grafana panels in Markdown is removed
- GitLab self-monitoring project
- Monitor performance metrics through Prometheus
Govern
-
License-Check and the Policies tab on the License Compliance page
-
Managed Licenses API
-
vulnerabilityFindingDismiss GraphQL mutation
-
Vulnerability confidence field
Enablement
Gitaly
-
Support for Praefect custom metrics endpoint configuration
-
Legacy Praefect configuration method
-
Deprecate legacy Gitaly configuration methods
-
Deprecate Gitaly legacy config
Platforms
- Configuring Redis config file paths using environment variables is deprecated
- Non-standard default Redis ports are deprecated
Breaking changes spreadsheet
https://docs.google.com/spreadsheets/d/1IPCtaVtCwLEm25AnzpOJIHSbWSZhNJ_SIcKoIvo0faA/edit#gid=0
/cc @lyle @mbruemmer @fzimmer @justinfarris @oheigre @lstahlman @rachel_fuerst
Please leave any feedback you have to this issue as a comment - tag @swiskow
so I see it