mirror of
https://github.com/data-privacy-stack/presidio.git
synced 2026-08-03 16:50:48 -05:00
d163f10ee6
* Initial plan * Pin pip commands with hashes for OSSF scorecard compliance Add --require-hashes to all pip install commands across Dockerfiles, CI workflows, and shell scripts. Generate locked requirements files with hashes for e2e tests, docs, and sample deployments. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Revert requirements-locked.txt changes, keep only direct pip hash pinning Remove all changes that involve requirements-locked.txt files per user request. Retain direct pip install hash pinning for poetry, ruff, build, and other version-pinned packages. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * fix: Remove --require-hashes/--hash from pip install commands pip 26.0 removed the --hash CLI option. Hash verification via command-line arguments is no longer supported; hashes can only be specified in requirements files. Revert all pip install commands to use simple version pinning (package==version) which is compatible with all pip versions. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Pin pip commands by hash via requirements files for OSSF compliance Use pip install --require-hashes with dedicated requirements files instead of bare pip install commands. This satisfies the OSSF scorecard pinned-dependencies check. - Create requirements-poetry.txt, requirements-ruff.txt, and requirements-build.txt with SHA256 hashes - Update all Dockerfiles to use hash-pinned poetry install - Update ci.yml to use hash-pinned ruff, poetry, and build installs - Update release.yml to use hash-pinned build install - Update spark startup.sh to use hash-pinned requirements file Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Plan: inline hashes via /dev/stdin instead of separate files Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Inline pip hashes via printf|stdin, remove separate requirements files Replace requirements-poetry.txt, requirements-ruff.txt, and requirements-build.txt with inline printf|pip install -r /dev/stdin. pip --hash only works inside requirements files, not as a CLI flag, so piping through /dev/stdin is the most inline approach possible. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Simplify ruff hash: use single linux x86_64 hash instead of all 17 platform hashes The lint job runs only on ubuntu-slim (x86_64), so only the manylinux_2_17_x86_64 wheel hash is needed. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Fix Windows Dockerfiles: use PowerShell for hash-pinned pip install The printf|/dev/stdin pattern is Unix-only and doesn't work on Windows Server Core. Use PowerShell Set-Content to write a temp requirements file instead. The hash is correct — poetry is a pure Python wheel (py3-none-any), same on all platforms. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Fix CI: remove --no-deps from poetry and build pip installs poetry and build have transitive dependencies (cleo, pyproject_hooks, etc.) that must be installed. --no-deps prevented their installation, causing ModuleNotFoundError: No module named 'cleo'. ruff keeps --no-deps --require-hashes since it has zero Python deps. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Plan: move requirements files into .github/pipelines/ Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Move CI requirements files to .github/pipelines/ directory Organize all pip-compile generated requirements files under .github/pipelines/ for ruff, poetry, and build tools. Replaces inline printf hash approach with proper requirements files. Component-level requirements-poetry.txt copies remain for Docker build context (COPY requires files within build context). Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Remove unnecessary .in files from .github/pipelines/ The .in files are just pip-compile input files containing the direct dependency name. This info is already in the header comment of each generated .txt file, making the .in files redundant. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Share single requirements-poetry.txt via Docker --build-context Replace 4 identical copies of requirements-poetry.txt (713 lines each) with a single file at the repo root. Dockerfiles use COPY --from=pipelines to access it from a named build context, eliminating duplication. Also consolidate requirements-ruff.txt and requirements-build.txt at the repo root. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Rename Docker build context from 'pipelines' to 'root' The requirements files are at the repo root, not in a pipelines directory. Rename the named build context to 'root' for clarity. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Scope down to CI-only ruff and build hash pinning Revert all Docker changes (Dockerfiles, docker-compose.yml, build context). Keep hash-pinned pip installs only for ruff and build in CI workflow. Requirements files live in .github/pipelines/. Reverted: all 10 Dockerfiles, docker-compose.yml, release.yml, poetry install in ci.yml, spark startup.sh. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Add 0BSD to allowed licenses in dependency-review Ruff's SPDX license expression is '0BSD AND Apache-2.0 AND BSD-3-Clause AND MIT'. The 0BSD component was not in the allow list, causing the dependency review to fail. 0BSD is a permissive public-domain-equivalent license. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> * Fix dependency-review: allow ruff's full compound SPDX license The dependency-review-action doesn't decompose compound SPDX expressions. Ruff's license '0BSD AND Apache-2.0 AND BSD-3-Clause AND MIT' must be listed as a complete expression in allow-licenses. Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: SharonHart <15013757+SharonHart@users.noreply.github.com> Co-authored-by: Sharon Hart <sharonh.dev@gmail.com>