Address unpinned Python dependencies

[cboneti]

Description

This PR improves the supply chain security of the repository by pinning build-time Python dependencies in Dockerfiles and scripts. This ensures deterministic builds and reduces the risk of installing unexpected package versions.

Changes Made

community/cos-nvidia-bug-report

• Pinned dependencies in requirements.txt with specific versions and hashes.
• Added requirements.in for tracking top-level dependencies.

tools/cloud-build

• Pinned versions in requirements.txt for required tools.

tools/cloud-workstations

• Vendored a remote requirements file to avoid dynamic fetching during the container build process.
• Updated the Dockerfile to use this local vendored file.

Verification Plan

Automated Tests

• Dependencies were resolved to find stable versions.

Manual Verification

• Verified that all modified requirement files contain pinned versions.
• Verified that the Dockerfile correctly references the local vendored file.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the repository's supply chain security by transitioning from unpinned to pinned Python dependencies. By enforcing specific versions and hashes, the changes ensure build reproducibility and mitigate risks associated with dynamic package resolution. Additionally, the move to local vendoring for remote requirements further hardens the build process against external network dependencies.

Highlights

• Dependency Pinning: Pinned Python dependencies in community/cos-nvidia-bug-report and tools/cloud-build to specific versions and added cryptographic hashes to ensure deterministic and secure builds.
• Supply Chain Security: Vendored a remote requirements file in tools/cloud-workstations to eliminate dynamic fetching from external URLs during container build processes.
• Build Configuration: Updated the Dockerfile in tools/cloud-workstations to reference the local vendored requirements file instead of a remote source.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates dependency management by pinning versions and vendoring requirements files across several components. Feedback focuses on a critical issue where a generated requirements file incorrectly points to a private staging registry, which would cause build failures for external users. Additionally, the transition from dynamic fetching to local vendoring of slurm-gcp requirements was identified as a violation of the project's consistency guidelines, which prefer fetching shared scripts from the master branch of the slurm-gcp repository.

[gemini-code-assist]

The --index-url points to a staging artifact registry (ah-3p-staging-python). For a community module, this should point to the public PyPI or be omitted to use the default. Using a staging registry will cause build failures for users who do not have access to this specific GCP project. Please re-generate this file using the public PyPI index.

--index-url https://pypi.org/simple

[gemini-code-assist]

This change replaces the dynamic fetching of requirements from the slurm-gcp master branch with a local vendored file. This violates the general rule: "To maintain consistency across blueprints, shared scripts ... should be fetched from the master branch of the GoogleCloudPlatform/slurm-gcp repository rather than being pinned to a specific version." While pinning improves determinism and security, it breaks consistency with the latest slurm-gcp scripts that the toolkit depends on. Consider if the security benefit outweighs the maintenance burden and risk of drift.

References

1. To maintain consistency across blueprints, shared scripts (e.g., sudo-oslogin, imex_prolog, imex_epilog) should be fetched from the master branch of the GoogleCloudPlatform/slurm-gcp repository rather than being pinned to a specific version.