feat: add --no_pip_packages and --no_system_packages options

[kdvalin]

User description

Description

Add two new command-line options to control package installation:

• --no_pip_packages: Skip installation of pip packages
• --no_system_packages: Skip installation of system packages (dnf/apt/etc)

These options complement the existing --no_packages flag and provide more granular control over which package types are installed.

Changes:

• burden: Add global variables, argument parsing, and ansible vars output
• test_generic ansible role: Pass flags to test execution script
• Updated usage documentation

🤖 Generated with Claude Code

Before/After Comparison

Before

Only --no_packages was allowed, this would result in neither system packages AND pip packages being installed. This is fine for instances like bootc based hosts, but for other instances, we want to test without installing system packages and with installing pip packages.

After

Adds - --no_pip_packages and --no_system_packages flags, which prevent installing their respective types of packages. --no_packages is still available and behaves as normal.

Documentation Check

Docs need to be updated.

Clerical Stuff

Closes #346

Relates to JIRA: RPOPC-806

Relevant Logs

Will come shortly

---

PR Type

Enhancement

---

Description

• Add --no_pip_packages flag for granular pip package control

• Add --no_system_packages flag for granular system package control

• Pass new flags through ansible test execution pipeline

• Update usage documentation with new options

---

Diagram Walkthrough

flowchart LR
  CLI["CLI Arguments<br/>--no_pip_packages<br/>--no_system_packages"]
  BURDEN["burden Script<br/>Parse & Store Flags"]
  ANSIBLE["Ansible Variables<br/>do_not_install_pip_packages<br/>do_not_install_system_packages"]
  TEST["Test Execution<br/>Pass Flags to Script"]
  CLI -- "Parse arguments" --> BURDEN
  BURDEN -- "Output to vars" --> ANSIBLE
  ANSIBLE -- "Pass to test" --> TEST

Loading

File Walkthrough

Relevant files

Enhancement

burden Add granular package control flags and parsing                      bin/burden Add two new global variables gl_no_pip_packages and gl_no_system_packages initialized to 0 Add argument parsing for --no_pip_packages and --no_system_packages flags in set_general_value() function Output new flags to ansible variables file in create_ansible_options() function Add new flags to NO_ARGUMENTS array in grab_cli_data() function Update usage documentation to describe the two new options +18/-0    main.yml Pass new package flags to test script                                        ansible_roles/roles/test_generic/tasks/main.yml Add conditional output of --no_pip_packages flag to command line if config_info.do_not_install_pip_packages is set Add conditional output of --no_system_packages flag to command line if config_info.do_not_install_system_packages is set Flags are passed to the test execution script via command line arguments +2/-0

---

[github-actions]

This relates to RPOPC-806

[qodo-code-review]

PR Compliance Guide 🔍

(Compliance updated until commit 3eec7f7)

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #346 🟢 Add support for `--no_pip_packages` and `--no_system_packages` CLI options in Zathras. Pass these options through to the test-tools wrappers/test execution so wrappers can act on them. Minimize the need to modify each wrapper individually (prefer a generic pass-through mechanism). ⚪ Verify end-to-end behavior that the wrappers actually honor --no_pip_packages / --no_system_packages when invoked (runtime/integration validation).
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

---

Previous compliance checks

Compliance check up to commit ebfc190

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #346 🟢 Add CLI support for `--no_pip_packages` and `--no_system_packages`. ⚪ Ensure these options can be passed through to the test-tools wrappers (ideally minimizing per-wrapper changes).
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

[github-actions]

PullHero Review

Provider: generativelanguage.googleapis.com Model: gemini-2.0-flash

Okay, I will review the proposed changes to the Zathras repository.

Code Review

Overview

This PR introduces two new command-line options: --no_pip_packages and --no_system_packages. These options allow users to disable the installation of pip and system packages, respectively. The changes primarily involve modifying the bin/burden script to handle these new options and passing them to the test execution phase via an Ansible variable.

Analysis

1. Code Quality and Maintainability:

   • The changes are relatively straightforward and follow the existing code structure in bin/burden.
   • The new options are added in a consistent manner with other existing options.
   • The usage message is updated to include the new options.
   • The Ansible task ansible_roles/roles/test_generic/tasks/main.yml is updated to pass the new options to the test execution script.

2. Potential Bugs or Security Issues:

   • There are no immediately apparent security issues.
   • It's important to ensure that the test wrappers correctly handle the absence of pip and system packages when these options are used. The wrappers should gracefully handle missing dependencies or provide informative error messages. This aspect isn't directly addressed in the provided diff, but it's a crucial consideration for overall functionality.
   • Consider adding some validation in bin/burden to make sure that there aren't any conflicting options. For example, if bootc_mode is enabled, then perhaps --no_system_packages is implicitly set.

3. Adherence to Project Conventions:

   • The changes generally adhere to the project's coding style and conventions.
   • The use of Ansible variables for passing the options is consistent with the existing approach.

4. Documentation Completeness:

   • The changes include updating the usage() function in bin/burden to document the new options.
   • The README.md should be updated with these new features.

Specific Feedback

• Good: The usage() function in bin/burden is updated to reflect the new command-line options.

• Concern: The test wrappers need to be able to handle the cases where these packages are not present. This isn't directly part of this diff but is a required consideration.

• Suggestion: Consider adding a check in bin/burden to ensure that --no_packages, --no_pip_packages, and --no_system_packages are mutually exclusive. If --no_packages is used, it should implicitly enable both --no_pip_packages and --no_system_packages. Conversely, if both --no_pip_packages and --no_system_packages are used, --no_packages should be ignored.

• Suggestion: Add a section to the README.md file documenting the new options and their impact on test execution. Also, add a section to the docs/command_line_reference.md file.

Example of adding the new options to the README.md file:

#### --no_pip_packages
Do not install pip packages. The default is no.

#### --no_system_packages
Do not install system packages (via dnf/apt/etc). The default is no.

Conclusion

The changes are well-structured and provide useful new functionality. However, it's crucial to ensure that the test wrappers are robust enough to handle the cases where pip and system packages are not installed.

Vote: +1

Vote: +1

PullHero

[qodo-code-review]

PR Code Suggestions ✨

Latest suggestions up to 3eec7f7

Category	Suggestion	Impact
Possible issue	Prevent undefined variable failures Add a default(false) filter to the new Jinja2 template conditions to prevent undefined variable errors when the corresponding variables are not set. ansible_roles/roles/test_generic/tasks/main.yml [83-84] -{{ "--no_pip_packages" if config_info.do_not_install_pip_packages else "" }} -{{ "--no_system_packages" if config_info.do_not_install_system_packages else "" }} +{{ "--no_pip_packages" if (config_info.do_not_install_pip_packages|default(false)) else "" }} +{{ "--no_system_packages" if (config_info.do_not_install_system_packages|default(false)) else "" }} Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential runtime error if the new variables are not defined and provides the standard Ansible/Jinja2 fix, improving the role's robustness and backward compatibility.	Medium
Incremental [*]	Prevent unintended flag overriding Instead of setting gl_no_pip_packages and gl_no_system_packages when --no_packages is used, remove these assignments. The logic to handle --no_packages as a master switch should be implemented where these variables are used. bin/burden [3538-3539] -gl_no_pip_packages=1 -gl_no_system_packages=1 +# NOTE: Do not force-set granular flags here; let later logic interpret +# gl_no_packages as "skip all package installs" in one place. Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies a potential logic issue where setting granular flags from a general flag (--no_packages) can lead to unexpected behavior, and proposes a more robust design.	Low
Update

---

Previous suggestions

Suggestions up to commit ebfc190

Category	Suggestion	Impact
Possible issue	Ensure master flag disables sub-options To ensure --no_packages acts as a master switch, modify the script to also set gl_no_pip_packages and gl_no_system_packages to 1 when gl_no_packages is 1. bin/burden [1854-1858] echo " "run_label: ${gl_run_prefix}_${gl_os_vendor} >> ansible_vars_main.yml + if [[ $gl_no_packages -eq 1 ]]; then + gl_no_pip_packages=1 + gl_no_system_packages=1 + fi echo " "do_not_install_packages: ${gl_no_packages} >> ansible_vars_main.yml echo " "do_not_install_pip_packages: ${gl_no_pip_packages} >> ansible_vars_main.yml echo " "do_not_install_system_packages: ${gl_no_system_packages} >> ansible_vars_main.yml echo " "bootc_mode: ${gl_bootc_mode} >> ansible_vars_main.yml [Suggestion processed] Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a logical flaw where the master flag --no_packages does not automatically disable the new, more specific package flags, leading to potentially unexpected behavior.	Medium

[dvalinrh]

LGTM.