SAST jobs no longer use global cache settings

Deprecation Summary

In GitLab 18.0, the SAST job templates explicitly disable the use of cache. The following templates are affected:

  • SAST.gitlab-ci.yml
  • SAST-IaC.gitlab-ci.yml

Documentation

Product Usage

This was done to prevent SAST analyzers from scanning cached artifacts, which may lead to false-positives and timeout.

The previous behavior can be restored by overriding the cache property in the project's CI configuration.

This change was originally added to the latest templates in GitLab %17.8 as part of the fix for SAST-Jobs timeout or reports non-existing error... (#440829 - closed).

Breaking Change?

This is possibly a breaking change. If a user intentionally wants SAST analyzers to scan cache paths, they need to update their CI configuration to explicitly enable cache on SAST jobs.

Affected Customers

  • GitLab.com
  • Self-managed
  • Dedicated

Deprecation Milestone

%17.9

Planned Removal Milestone

%18.0

Links

Checklists

Timeline

Rollout Plan

DRIs:

The change will be rolled-out with the GitLab %18.0 release. It's already available from %17.8 via the use of the latest templates.

There's no feature flag for this change.

Communication Plan

DRIs:

Add links to the relevant merge requests.

  • As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: 17.8, 17.9, 17.10, 17.11, 18.0 – 17.9 is the third milestone preceding the major release):
  • On the major milestone:
    • The deprecated item has been removed.
    • If the removal of the deprecated item is a breaking change, the merge request is labeled breaking change.
    • Document the migration plan for users, clearly outlining the actions they need to take to mitigate the impact of the breaking change.

Development

DRIs:

  • Engineers: @philipcunningham

  • Engineering Manager: @thiagocsf

  • Measure usage of the impacted product feature

    • Evaluate metrics across GitLab.com, Self-Managed, Dedicated
    • add issue link
    • list any metrics and/or dashboards

  • Create tooling for customers to manually migrate their data or workflows

    • add issue link

  • Build mechanism for users to manually enable the breaking change ahead of time

    • add issue link

  • Automate the migration for those who do not take any manual steps (ensure the automation can be reverted)

    • add issue link

  • Develop rollout plan of breaking change on GitLab.com

    • add feature flag rollout issue

  • Dogfood the changes on GitLab.com or a Self-Managed test instance

    • add issue link

  • (Optional) Create UI controls for instance admins to disable the breaking change, providing flexibility to Self-Managed / Dedicated customers. Optional as this depends on the breaking change.

    • add issue link

Approvals

  • Product Manager @PM
  • Engineering Manager @EM
  • Senior Engineering Manager / Director @senior-eng-leader
  • Group / Director of Product Management @senior-product-leader

Mentions (as applicable)

  • Product Designer @ProductDesigner
  • Tech Writer @TW
  • Software Engineering in Test @SET
  • Any other stable counterparts based on the product categories:
    • Add Sales/CS counterpart or mention @timtams
    • Add Support counterpart or mention @gitlab-com/support/managers
    • Add Marketing counterpart or mention @cfoster3

Labels

  • This issue is labeled deprecation, and with the relevant ~devops::, ~group::, and ~Category: labels.
  • This issue is labeled breaking change if the removal of the deprecated item will be a breaking change.

References

Edited by Adam Cohen