Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 36 additions & 2 deletions .coderabbit.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -39,12 +39,14 @@ reviews:
mode: "warning"
requirements: |
PR title MUST follow Conventional Commits format:
- Format: <type>: <description> or <type>!: <description> for breaking changes
- Valid types: Refer to the 'type-enum' rule in .commitlintrc.js file for the complete list of allowed types
- Format: <required type><optional (scope)><optional !>: <required description>
- Valid types: Refer to https://github.com/linux-system-roles/auto-maintenance/blob/main/pr_title_lint.py#L23
- Examples:
- "feat: Add backup functionality"
- "fix: Correct OSTree package installation"
- "fix!: Remove deprecated variable (breaking change)"
- "chore(formatting): Fix indentation in my_module.py"
- "refactor(python)!: Use new python library thispy which has breaking api changes"

custom_checks:
- mode: "warning"
Expand All @@ -55,6 +57,8 @@ reviews:
- Must contain "Reason:" section explaining why the change was needed
- Must contain "Result:" section describing the outcome or impact
- Can contain optional "Issue Tracker Tickets (Jira or BZ if any):" section
- Must contain "Signed-off-by:" section with your name and email address - use git commit -s
- Can contain optional "Assisted-by:" section with name of the AI coding assistant and models used

Example:
```
Expand All @@ -65,6 +69,34 @@ reviews:
Result: Users can now set certificate_secure_logging: false for debugging while maintaining secure defaults.

Issue Tracker Tickets (Jira or BZ if any): RHEL-12345

Signed-off-by: John Doe john.doe@example.com

Assisted-by: Fish 4.3 using model Swim 6.2
```

For PRs that are bug fixes, you can use the following template:
- Must contain "Cause:" section explaining the root cause of the bug
- Must contain "Consequences:" section explaining the impact of the bug and how it appears to users
- Must contain "Fix:" section explaining the fix for the bug and how it fixes the bug
- Must contain "Result:" section describing the outcome or impact of the fix
- Can contain optional "Issue Tracker Tickets (Jira or BZ if any):" section
- Must contain "Signed-off-by:" section with your name and email address - use git commit -s
- Can contain optional "Assisted-by:" section with name of the AI coding assistant and models used

Example:
```
Cause: The variable rolename_user_name was being checked for a `none` value but was not being checked for string length greater than 0 if a string.

Consequences: The role allowed empty user names to be configured which caused the daemon to report "User not found".

Fix: The variable rolename_user_name is now checked for string length if not `none`, and will report an error in that case if the length is 0.

Result: The role will not allow the user to provide an empty user name and will report an error if the rolename_user_name length is 0.

Signed-off-by: John Doe john.doe@example.com

Assisted-by: Fish 4.3 using model Swim 6.2
```

path_instructions:
Expand Down Expand Up @@ -180,6 +212,8 @@ reviews:
- Tests should verify both success and failure scenarios
- Use assert module to verify expected state after role execution
- Include cleanup tasks to ensure tests are rerunnable
- Tests should be run in a block with an always section that runs the test cleanup to ensure that the cleanup is always run.
- The cleanup tasks should be tagged with `tests::cleanup` so that the cleanup can be skipped for debug purposes.
- Tests should be idempotent - running twice should not cause failures
- Example verification:
```yaml
Expand Down
141 changes: 0 additions & 141 deletions .commitlintrc.js

This file was deleted.

8 changes: 4 additions & 4 deletions .github/workflows/pr-title-lint.yml
Original file line number Diff line number Diff line change
Expand Up @@ -22,11 +22,11 @@ jobs:
with:
fetch-depth: 0

- name: Install conventional-commit linter
run: npm install @commitlint/config-conventional @commitlint/cli
- name: Install pr_title_lint.py
run: curl -o pr_title_lint.py https://raw.githubusercontent.com/linux-system-roles/auto-maintenance/main/pr_title_lint.py
Comment on lines +25 to +26

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

linux-system-roles auto-maintenance pr_title_lint.py latest commit checksum verification recommended practice for downloading scripts in CI

💡 Result:

The linux-system-roles/auto-maintenance repository is a collection of automation scripts and tools used to manage various linux-system-roles repositories [1]. Regarding the specific query about pr_title_lint.py, while auto-maintenance contains many utility scripts [1], standard PR title linting in the linux-system-roles ecosystem is typically handled via GitHub Actions—specifically using commitlint as shown in the linux-system-roles/template repository [2]. Recommended practices for downloading and executing scripts in CI pipelines emphasize security to prevent supply chain attacks, as piping directly from curl to shell (e.g., curl | bash) is considered a security risk [3][4]. The following practices are recommended: 1. Use Trusted Sources and Version Pinning: Whenever possible, use official plugins, package managers (apt, apk, npm), or container images [3][4]. If you must download a script, ensure it is from a trusted, immutable source and pin it to a specific version or commit [3]. 2. Verify Integrity via Checksums: Never execute a remote script without verification [3]. The standard practice is to: - Download the script to a temporary file [3]. - Compute its hash (e.g., sha256sum) [3][5]. - Compare the computed hash against a known, trusted checksum [3][5]. - Only execute the script if the verification succeeds [3][6][5]. Example CI pattern for checksum verification: curl -fsSL https://example.com/script.sh -o script.sh echo "EXPECTED_HASH script.sh" | sha256sum -c - if [ $? -eq 0 ]; then bash script.sh else echo "Checksum verification failed" exit 1 fi 3. Avoid Dynamic Scripts: If a script is generated dynamically, it is difficult to verify via a static checksum [5]. In such cases, prefer cloning the repository and running the script from a specific commit hash, which guarantees integrity through git's cryptographic signing rather than relying on a downloadable artifact checksum [7][5].

Citations:


🏁 Script executed:

#!/bin/bash
set -euo pipefail

git ls-files .github/workflows/pr-title-lint.yml .github/workflows
wc -l .github/workflows/pr-title-lint.yml
cat -n .github/workflows/pr-title-lint.yml | sed -n '1,120p'

printf '\n--- related references ---\n'
rg -n "pr_title_lint\.py|curl .*raw.githubusercontent.com|--fail|-f" .github/workflows . -g '!**/node_modules/**' -g '!**/dist/**' -g '!**/build/**'

Repository: linux-system-roles/certificate

Length of output: 8607


🏁 Script executed:

#!/bin/bash
set -euo pipefail

rg -n "curl .*raw\.githubusercontent\.com|curl .* -f|curl .*--fail|curl .* -L" .github/workflows -g '*.yml' -g '*.yaml'

Repository: linux-system-roles/certificate

Length of output: 736


🌐 Web query:

curl --fail exit code HTTP 404 body saved without --fail documentation

💡 Result:

When using the --fail (or -f) option in curl, the program will exit with code 22 if an HTTP server returns an error response code of 400 or greater [1][2]. Crucially, the --fail option explicitly prevents curl from outputting or saving the response body for these errors [1][3]. In these cases, curl stops immediately after receiving the response headers and does not store the content [1][4]. If you need to both trigger an exit code on HTTP errors (400+) and save the response body (such as the HTML error page or error details), you should use the --fail-with-body option instead [1][5][4]. This option, introduced in curl version 7.76.0, functions as an alternative to --fail by allowing the body to be saved while still returning exit code 22 upon encountering a server error [1][4]. These two options, --fail and --fail-with-body, are mutually exclusive [1][6].

Citations:


Pin the downloaded script to an immutable ref and fail fast on HTTP errors. Fetching from main means CI executes whatever upstream publishes next; pin a commit/tag, and use curl --fail (or --fail-with-body) so 4xx/5xx responses don’t turn into a confusing Python traceback.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/pr-title-lint.yml around lines 25 - 26, The
pr_title_lint.py download step is pulling from a mutable upstream branch and
does not fail cleanly on HTTP errors. Update the curl command in the workflow’s
install step to fetch from an immutable ref (a pinned commit or tag) instead of
main, and add curl fail behavior such as --fail or --fail-with-body so CI stops
immediately on 4xx/5xx responses before invoking the script.


- name: Run commitlint on PR title
- name: Run pr_title_lint.py on PR title
env:
PR_TITLE: ${{ github.event.pull_request.title }}
# Echo from env variable to avoid bash errors with extra characters
run: echo "$PR_TITLE" | npx commitlint --verbose
run: python3 pr_title_lint.py "${PR_TITLE}"