## Problem to solve The dependency scanning analyzer currently exposes a CI/CD variable named `DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN` which is used to point at a **lockfile** (a `requirements.txt` generated by `pip-compile`) so the analyzer can scan it directly. The current name is ambiguous because in the Python ecosystem `requirements.txt` can be **either**: - a **manifest** (loose, hand-authored constraints — input to `pip-compile`), or - a **lockfile** (fully pinned output of `pip-compile`). Today the variable name says `REQUIREMENTS`, which most Python users will read as "manifest". This is the opposite of what the variable actually does. The confusion was discussed in detail in [the parent issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/593859#note_3215486291). ## Proposal Replace `DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN` with `DS_PIPCOMPILE_LOCKFILE_FILE_NAME_PATTERN` everywhere it is referenced, while keeping the old name working as a deprecated variable to avoid breaking existing pipelines. Similarly, replace the corresponding spec:input `pipcompile_requirements_file_name_pattern` with `pipcompile_lockfile_file_name_pattern`. ### Naming rationale | Variable | Points at | Used by | |----------|-----------|---------| | `DS_PIPCOMPILE_LOCKFILE_FILE_NAME_PATTERN` (new) | pip-compile **lockfile** (pinned `requirements.txt`) | DS analyzer (direct scan) and DR service (skip directory) | | `DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN` (deprecated alias) | same as above | kept as alias for backward compatibility | This naming aligns with the convention being introduced for the future manifest-side variable (`DS_PIP_MANIFEST_FILE_NAME_PATTERN`), so users get an unambiguous "manifest vs lockfile" split as [discussed in the issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/593859#note_3217259587).