Conversation
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
📝 WalkthroughWalkthroughThis PR establishes comprehensive CI/CD automation and Python packaging infrastructure. It adds 11 GitHub Actions workflows for testing, linting, coverage, dependency auditing, and release management—all delegating to centralized reusable workflows—along with packaging metadata, a Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Beep! Automated checks have reached 100% completion. 🔋I've aggregated the results of the automated checks for this PR below. 🏷️ Release PreviewThe draft for the big day is ready for review. 📝 Current:
✅ PR title follows conventional commit format. 🚀 Release Channel Compatibility Predicted next version:
📋 Repo HealthYour repository is in great shape! ✅ Latest Version: ✅ 📊 CoverageI've mapped out the test coverage for you! 🗺️ ⚖️ License CheckScanning for any potential trademark infringements. ™️ ✅ No license violations found (48 packages). License distribution: 13× MIT License, 9× MIT, 5× Apache Software License, 5× Apache-2.0, 4× BSD-3-Clause, 2× ISC License (ISCL), 2× PSF-2.0, 1× Apache Software License; BSD License, +7 more Full breakdown — 48 packages
Copyright (c) 2022 Phil Ewels Permission is hereby granted, free of charge, to any person obtaining a copy The above copyright notice and this permission notice shall be included in all THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR Policy: Apache 2.0 (universal donor). StrongCopyleft / NetworkCopyleft / WeakCopyleft / Other / Error categories fail. MPL allowed. 🔒 Security (pip-audit)I've audited the packages. Safety first! 🦺 ✅ No known vulnerabilities found (66 packages scanned). 🔨 Build TestsMixing the ingredients and seeing if the cake rises! 🎂
❌ 3.10: Signed, sealed, and delivered by the OVOS bot. 📧 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (4)
HiveMind_cli.egg-info/dependency_links.txt (1)
1-1: Avoid tracking generated.egg-infometadata in git.This file appears to be build-generated metadata and is empty; consider removing tracked
.egg-infoartifacts and relying on build-time generation to prevent metadata drift.Suggested cleanup
- HiveMind_cli.egg-info/dependency_links.txt+# .gitignore +*.egg-info/🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@HiveMind_cli.egg-info/dependency_links.txt` at line 1, Remove the generated .egg-info metadata from source control: stop tracking the empty dependency_links.txt (and other files under the .egg-info directory) by removing them from the repo and adding the pattern "*.egg-info/" (or the specific artifact name "dependency_links.txt") to .gitignore; use git rm --cached to untrack the files and commit the change, and rely on build-time generation (e.g., via setup.py/poetry/build) to recreate the .egg-info artifacts as needed.HiveMind_cli.egg-info/requires.txt (1)
1-2: Avoid committing generated*.egg-infometadata files.Line 1 and Line 2 are valid metadata entries, but
HiveMind_cli.egg-info/*is build-generated and can drift frompyproject.toml. Prefer generating these during build and excluding them from VCS.Suggested cleanup
+# .gitignore +*.egg-info/🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@HiveMind_cli.egg-info/requires.txt` around lines 1 - 2, This commit includes generated metadata file HiveMind_cli.egg-info/requires.txt which should not be versioned; remove HiveMind_cli.egg-info/* from the repository, add an ignore rule for HiveMind_cli.egg-info/ (or *.egg-info/) to .gitignore, and ensure dependency metadata remains authoritative in pyproject.toml; after removing, recreate any needed build artifacts locally via your normal build step to verify nothing else depends on the checked-in egg-info.HiveMind_cli.egg-info/PKG-INFO (1)
1-18: Generated packaging artifacts should not be committed.The
HiveMind_cli.egg-info/directory is auto-generated during package installation/building and should be added to.gitignore. Committing these files can lead to:
- Merge conflicts when multiple developers build locally
- Stale metadata that doesn't reflect actual package state
- Repository bloat
Recommended fix
Add to
.gitignore:*.egg-info/Then remove the committed directory:
git rm -r HiveMind_cli.egg-info/🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@HiveMind_cli.egg-info/PKG-INFO` around lines 1 - 18, The repo contains committed build artifacts under HiveMind_cli.egg-info (seen in PKG-INFO) which should not be tracked; add the pattern *.egg-info/ to .gitignore and remove the committed directory from git tracking (e.g., run git rm -r HiveMind_cli.egg-info/ and commit the deletion) so future builds do not reintroduce these generated metadata files..github/workflows/publish_stable.yml (1)
5-6: Consider tag/manual gating for stable publish.Triggering stable publish on every push to
main/mastercan accidentally cut releases. Prefer tags (for examplev*) or manual-only flow.Possible trigger hardening
on: workflow_dispatch: push: - branches: [master, main] + tags: + - 'v*'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish_stable.yml around lines 5 - 6, The workflow currently triggers stable publish on every push via the push: branches: [master, main] setting; change the trigger to require a tag or manual approval instead: replace or augment push: branches with push: tags: [ "v*" ] to only publish on version tags and/or add workflow_dispatch to allow manual runs (or add a conditional check on github.ref_type == 'tag' in the job) so releases are only cut from explicit tags or manual invocation; update references to push/branches in the workflow to use tags or workflow_dispatch accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/build-tests.yml:
- Around line 1-15: Remove the redundant workflow file and fix test-dep config:
delete the deprecated python-support.yml so only build-tests.yml remains, then
either add a [project.optional-dependencies] section in pyproject.toml that
defines a "test" extra (so the reusable workflow's install_extras: 'test' works)
or remove the install_extras: 'test' key from build-tests.yml (keeping
python_versions, test_path, and secrets unchanged) so the workflow no longer
expects a non-existent extra.
In @.github/workflows/conventional-label.yml:
- Around line 3-10: The workflow uses a mutable action pin and leaves token
permissions unrestricted: replace the mutable action reference
bcoe/conventional-release-labels@v1 with a fixed commit SHA (pin the action to a
specific commit) and add an explicit permissions block for the workflow to
restrict GITHUB_TOKEN to only the minimum required scopes (e.g., permissions:
pull-requests: write or contents: read as appropriate), and ensure this is
applied under the pull_request_target job definition so the privileged context
uses the pinned action and limited token.
In @.github/workflows/coverage.yml:
- Line 14: The workflow uses an incorrect coverage_source value; update the
coverage job's coverage_source key from 'HiveMind_cli' to the actual Python
package name 'hivemind_cli_terminal' (as defined in pyproject.toml packages) so
coverage measurement points at the correct module; locate the coverage_source
entry in the coverage.yml workflow and replace its value accordingly.
In @.github/workflows/license_check.yml:
- Around line 10-11: Replace the mutable reference and broad secret inheritance:
change the uses: reference
OpenVoiceOS/gh-automations/.github/workflows/license-check.yml@dev to a specific
immutable commit SHA (the exact commit that was reviewed) and replace secrets:
inherit with explicit secret mappings that only expose the minimal required
secrets (e.g., map only GITHUB_TOKEN or the specific LICENSE_CHECK token)
instead of inheriting all secrets; apply the same pattern for other workflows
that use OpenVoiceOS/gh-automations and any occurrences of secrets: inherit to
ensure each workflow lists only the needed secrets.
In @.github/workflows/pip_audit.yml:
- Around line 10-11: Replace the mutable reusable-workflow reference and blanket
secret inheritance: change the uses reference
"OpenVoiceOS/gh-automations/.github/workflows/pip-audit.yml@dev" to an immutable
commit SHA (pin to a specific commit) and remove "secrets: inherit", then
explicitly pass only the minimal required secrets (e.g., list the specific
secret names) to the reusable workflow instead of inheriting all secrets.
In @.github/workflows/publish_stable.yml:
- Line 14: The reusable workflow invocation "uses:
OpenVoiceOS/gh-automations/.github/workflows/publish-stable.yml@dev" is pinned
to the mutable ref `@dev`; replace the ref with an immutable commit SHA (the full
40-char commit hash) so the call in the publish_stable.yml workflow always
references that exact commit rather than a moving branch.
In @.github/workflows/python-support.yml:
- Around line 1-18: Delete the deprecated workflow file python-support.yml from
.github/workflows to avoid duplicate CI runs; keep the existing build-tests.yml
(the job named build_tests that uses
OpenVoiceOS/gh-automations/.github/workflows/build-tests.yml@dev) as the single
workflow, and ensure there are no remaining references to python-support.yml in
the repo or other workflow configs.
In @.github/workflows/release_workflow.yml:
- Line 16: The reusable workflow reference uses a mutable ref
"OpenVoiceOS/gh-automations/.github/workflows/publish-alpha.yml@dev"; replace
the '@dev' ref with an immutable commit SHA for that repo (e.g., the full
40-char commit hash of the desired commit) so the workflow is pinned; locate the
"uses: OpenVoiceOS/gh-automations/.github/workflows/publish-alpha.yml@dev" line
and update it to use the commit SHA (obtainable via git log/git rev-parse or the
GitHub commit UI) and commit the change.
---
Nitpick comments:
In @.github/workflows/publish_stable.yml:
- Around line 5-6: The workflow currently triggers stable publish on every push
via the push: branches: [master, main] setting; change the trigger to require a
tag or manual approval instead: replace or augment push: branches with push:
tags: [ "v*" ] to only publish on version tags and/or add workflow_dispatch to
allow manual runs (or add a conditional check on github.ref_type == 'tag' in the
job) so releases are only cut from explicit tags or manual invocation; update
references to push/branches in the workflow to use tags or workflow_dispatch
accordingly.
In `@HiveMind_cli.egg-info/dependency_links.txt`:
- Line 1: Remove the generated .egg-info metadata from source control: stop
tracking the empty dependency_links.txt (and other files under the .egg-info
directory) by removing them from the repo and adding the pattern "*.egg-info/"
(or the specific artifact name "dependency_links.txt") to .gitignore; use git rm
--cached to untrack the files and commit the change, and rely on build-time
generation (e.g., via setup.py/poetry/build) to recreate the .egg-info artifacts
as needed.
In `@HiveMind_cli.egg-info/PKG-INFO`:
- Around line 1-18: The repo contains committed build artifacts under
HiveMind_cli.egg-info (seen in PKG-INFO) which should not be tracked; add the
pattern *.egg-info/ to .gitignore and remove the committed directory from git
tracking (e.g., run git rm -r HiveMind_cli.egg-info/ and commit the deletion) so
future builds do not reintroduce these generated metadata files.
In `@HiveMind_cli.egg-info/requires.txt`:
- Around line 1-2: This commit includes generated metadata file
HiveMind_cli.egg-info/requires.txt which should not be versioned; remove
HiveMind_cli.egg-info/* from the repository, add an ignore rule for
HiveMind_cli.egg-info/ (or *.egg-info/) to .gitignore, and ensure dependency
metadata remains authoritative in pyproject.toml; after removing, recreate any
needed build artifacts locally via your normal build step to verify nothing else
depends on the checked-in egg-info.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 53f8f503-d56e-4a2c-84c8-3cb0119ee59b
📒 Files selected for processing (19)
.github/workflows/build-tests.yml.github/workflows/conventional-label.yml.github/workflows/coverage.yml.github/workflows/license_check.yml.github/workflows/lint.yml.github/workflows/pip_audit.yml.github/workflows/publish_stable.yml.github/workflows/python-support.yml.github/workflows/release-preview.yml.github/workflows/release_workflow.yml.github/workflows/repo-health.ymlHiveMind_cli.egg-info/PKG-INFOHiveMind_cli.egg-info/SOURCES.txtHiveMind_cli.egg-info/dependency_links.txtHiveMind_cli.egg-info/entry_points.txtHiveMind_cli.egg-info/requires.txtHiveMind_cli.egg-info/top_level.txthivemind_cli_terminal/version.pypyproject.toml
| name: Build Tests | ||
|
|
||
| on: | ||
| pull_request: | ||
| branches: [dev, master, main] | ||
| workflow_dispatch: | ||
|
|
||
| jobs: | ||
| build: | ||
| uses: OpenVoiceOS/gh-automations/.github/workflows/build-tests.yml@dev | ||
| secrets: inherit | ||
| with: | ||
| python_versions: '["3.10", "3.11", "3.12", "3.13", "3.14"]' | ||
| install_extras: 'test' | ||
| test_path: 'test' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if test extras are defined in pyproject.toml
echo "=== Checking for test extras in pyproject.toml ==="
rg -n 'optional-dependencies|extras' pyproject.toml setup.py || echo "No optional-dependencies found"
echo ""
echo "=== Checking test file imports for required dependencies ==="
rg -n '^import|^from' test/Repository: JarbasHiveMind/HiveMind-cli
Length of output: 365
🏁 Script executed:
#!/bin/bash
# Check if python-support.yml exists and what workflows are defined
echo "=== Checking GitHub workflows ==="
ls -la .github/workflows/
echo ""
echo "=== Checking python-support.yml content ==="
head -30 .github/workflows/python-support.yml
echo ""
echo "=== Checking pyproject.toml for dependencies ==="
head -80 pyproject.toml
echo ""
echo "=== Checking if lichecker is in dependencies ==="
rg -n 'lichecker|test' pyproject.tomlRepository: JarbasHiveMind/HiveMind-cli
Length of output: 2687
🏁 Script executed:
#!/bin/bash
echo "=== Content of build_tests.yml (underscore) ==="
cat .github/workflows/build_tests.yml
echo ""
echo "=== Comparing workflow names ==="
echo "build-tests.yml name:"
rg -A 1 "^name:" .github/workflows/build-tests.yml
echo ""
echo "build_tests.yml name:"
rg -A 1 "^name:" .github/workflows/build_tests.yml
echo ""
echo "python-support.yml name:"
rg -A 1 "^name:" .github/workflows/python-support.ymlRepository: JarbasHiveMind/HiveMind-cli
Length of output: 854
🏁 Script executed:
#!/bin/bash
echo "=== Full build-tests.yml content ==="
cat .github/workflows/build-tests.yml
echo ""
echo "=== Full python-support.yml content ==="
cat .github/workflows/python-support.yml
echo ""
echo "=== Checking build_tests.yml more carefully ==="
cat .github/workflows/build_tests.ymlRepository: JarbasHiveMind/HiveMind-cli
Length of output: 1670
🏁 Script executed:
#!/bin/bash
echo "=== Summary of workflow differences ==="
echo "build-tests.yml triggers: pull_request on [dev, master, main]"
echo "Has install_extras: 'test' - trying to install optional test dependencies"
echo ""
echo "python-support.yml triggers: pull_request on [dev, master, main]"
echo "Does NOT have install_extras"
echo ""
echo "Note from python-support.yml:"
grep "NOTE:" .github/workflows/python-support.yml
echo ""
echo "=== Checking if there's a setup.py or if tests might use different mechanism ==="
ls -la | grep -E "setup.py|setup.cfg|pyproject.toml"
echo ""
echo "=== Checking what pyproject.toml actually defines ==="
cat pyproject.tomlRepository: JarbasHiveMind/HiveMind-cli
Length of output: 1290
Remove duplicate workflow and define test dependencies.
Both build-tests.yml and python-support.yml define workflows named "Build Tests" with identical configurations and triggers. The python-support.yml file's own comment explicitly notes it is deprecated and should be removed.
Additionally, build-tests.yml specifies install_extras: 'test', but no [project.optional-dependencies] section exists in pyproject.toml to define the test extra. This will cause the reusable workflow to fail. Either add the test extra definition to pyproject.toml or remove the install_extras parameter if test dependencies should be installed from a separate mechanism.
Remove the redundant python-support.yml and ensure the remaining workflow can successfully install its dependencies.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/build-tests.yml around lines 1 - 15, Remove the redundant
workflow file and fix test-dep config: delete the deprecated python-support.yml
so only build-tests.yml remains, then either add a
[project.optional-dependencies] section in pyproject.toml that defines a "test"
extra (so the reusable workflow's install_extras: 'test' works) or remove the
install_extras: 'test' key from build-tests.yml (keeping python_versions,
test_path, and secrets unchanged) so the workflow no longer expects a
non-existent extra.
| pull_request_target: | ||
| types: [ opened, edited ] | ||
| name: conventional-release-labels | ||
| jobs: | ||
| label: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: bcoe/conventional-release-labels@v1 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify mutable action refs and pull_request_target usage in workflows
rg -n -C2 'pull_request_target|uses:\s*[^@]+@(main|master|dev|v[0-9]+)$' .github/workflowsRepository: JarbasHiveMind/HiveMind-cli
Length of output: 15390
🏁 Script executed:
cat -n .github/workflows/conventional-label.ymlRepository: JarbasHiveMind/HiveMind-cli
Length of output: 359
Pin action SHA and restrict token permissions in pull_request_target workflow.
Line 10 uses a mutable tag (@v1) in a privileged pull_request_target context, increasing supply-chain risk. Additionally, no explicit permissions are defined, leaving the GITHUB_TOKEN with full default permissions. Pin to a commit SHA and restrict token access.
Suggested fix
on:
pull_request_target:
types: [ opened, edited ]
name: conventional-release-labels
+permissions:
+ contents: read
+ pull-requests: write
jobs:
label:
runs-on: ubuntu-latest
steps:
- - uses: bcoe/conventional-release-labels@v1
+ - uses: bcoe/conventional-release-labels@<full_commit_sha>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/conventional-label.yml around lines 3 - 10, The workflow
uses a mutable action pin and leaves token permissions unrestricted: replace the
mutable action reference bcoe/conventional-release-labels@v1 with a fixed commit
SHA (pin the action to a specific commit) and add an explicit permissions block
for the workflow to restrict GITHUB_TOKEN to only the minimum required scopes
(e.g., permissions: pull-requests: write or contents: read as appropriate), and
ensure this is applied under the pull_request_target job definition so the
privileged context uses the pinned action and limited token.
| secrets: inherit | ||
| with: | ||
| python_version: '3.11' | ||
| coverage_source: 'HiveMind_cli' |
There was a problem hiding this comment.
Incorrect coverage_source value will cause coverage measurement to fail.
The coverage_source should reference the actual Python module directory, not the distribution package name. Based on pyproject.toml (line 21: packages = ["hivemind_cli_terminal"]), the correct value is hivemind_cli_terminal.
Proposed fix
- coverage_source: 'HiveMind_cli'
+ coverage_source: 'hivemind_cli_terminal'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| coverage_source: 'HiveMind_cli' | |
| coverage_source: 'hivemind_cli_terminal' |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/coverage.yml at line 14, The workflow uses an incorrect
coverage_source value; update the coverage job's coverage_source key from
'HiveMind_cli' to the actual Python package name 'hivemind_cli_terminal' (as
defined in pyproject.toml packages) so coverage measurement points at the
correct module; locate the coverage_source entry in the coverage.yml workflow
and replace its value accordingly.
| uses: OpenVoiceOS/gh-automations/.github/workflows/license-check.yml@dev | ||
| secrets: inherit |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd /tmp && git ls-files '.github/workflows/license_check.yml'Repository: JarbasHiveMind/HiveMind-cli
Length of output: 141
🏁 Script executed:
cat -n .github/workflows/license_check.ymlRepository: JarbasHiveMind/HiveMind-cli
Length of output: 351
🏁 Script executed:
# Check for any other workflows with similar patterns
rg -n "secrets:\s*inherit" .github/workflows/ -A 1 -B 1Repository: JarbasHiveMind/HiveMind-cli
Length of output: 1718
🏁 Script executed:
# Look for `@dev` or other branch references in workflows
rg -n "@dev|@main|@master" .github/workflows/ -t yamlRepository: JarbasHiveMind/HiveMind-cli
Length of output: 2009
Pin workflow to immutable commit hash and scope secrets to minimum required permissions.
The @dev reference on line 10 is a branch pointer that can change without notice. Combined with secrets: inherit on line 11, this exposes all inherited secrets to an external workflow that can be modified at any time. Use a specific commit SHA and replace secrets: inherit with explicit secret mapping.
This pattern appears across multiple workflows in .github/workflows/ and should be addressed systematically.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/license_check.yml around lines 10 - 11, Replace the
mutable reference and broad secret inheritance: change the uses: reference
OpenVoiceOS/gh-automations/.github/workflows/license-check.yml@dev to a specific
immutable commit SHA (the exact commit that was reviewed) and replace secrets:
inherit with explicit secret mappings that only expose the minimal required
secrets (e.g., map only GITHUB_TOKEN or the specific LICENSE_CHECK token)
instead of inheriting all secrets; apply the same pattern for other workflows
that use OpenVoiceOS/gh-automations and any occurrences of secrets: inherit to
ensure each workflow lists only the needed secrets.
| uses: OpenVoiceOS/gh-automations/.github/workflows/pip-audit.yml@dev | ||
| secrets: inherit |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/pip_audit.yml | head -20Repository: JarbasHiveMind/HiveMind-cli
Length of output: 339
🌐 Web query:
GitHub Actions reusable workflow security @dev mutable branch secrets inherit best practices
💡 Result:
Summary (secure pattern): when calling a reusable workflow, pass secrets explicitly or use secrets: inherit only when you trust the caller context, and always reference the reusable workflow by an immutable ref (prefer commit SHA over a mutable branch like @dev). Additionally, protect any “production” secret usage with Environment protection rules (deployment branches/tags set to protected branches, required reviewers) so a workflow change on an unapproved ref can’t use those environment secrets. 1) How reusable-workflow secret passing works (including secrets: inherit) - In a reusable workflow invoked via on: workflow_call, the reusable workflow can define secrets under the on.workflow_call.secrets key. - In the caller workflow, you can pass secrets to the reusable workflow under jobs.<job_id>.secrets. - If the caller uses secrets: inherit, the called reusable workflow can reference secrets from the caller workflow even if they aren’t explicitly listed in the called workflow’s on.workflow_call.secrets section. - Example from GitHub Docs: jobs: call-workflow-passing-data: uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main with: config-path: .github/labeler.yml secrets: inherit - GitHub also documents passing secrets in nested workflows: secrets are only passed along the chain when they are explicitly inherited/passed at each step (A → B → C means C receives secrets only if A passed them to B, and B passed them to C). 2) Branch / ref “immutability” and why @dev can be risky - When you reference a reusable workflow as owner/repo/.github/workflows/workflow.yml@{ref}, {ref} can be a SHA, a release tag, or a branch name. - GitHub’s docs explicitly say: “Using the commit SHA is the safest option for stability and security.” - If you reference a reusable workflow from a mutable branch like @dev, then updates pushed to that branch will change the code your caller runs, which can unintentionally expand the trust boundary for anyone who can trigger the caller. Best practice: pin the reusable workflow reference to a commit SHA (or a release tag you control), not a branch name, especially when the caller uses privileged credentials or environment secrets. 3) “@dev mutable branch secrets inherit” best-practice guidance A) Don’t rely on secrets: inherit as your only guardrail - secrets: inherit is a convenience to forward all caller secrets to the called reusable workflow. - Therefore, it increases the blast radius if either: - the reusable workflow reference is mutable (e.g., @dev), or - untrusted callers can run the workflow and reach the job that has access to those secrets. - GitHub’s “Secure use reference” and “Using secrets” guidance emphasizes least privilege: users with write access to the repo can read secrets configured in the repo, and you should grant the minimum required token permissions; and, for sensitive deployment secrets, use environment protections and required reviewers. B) Use Environment protection rules to gate environment secrets - Environment secrets are only available to jobs that reference the environment. - You can restrict which branches can deploy to an environment using “Deployment branches and tags”. One of the options is “Protected branches only” and it also supports restricting to selected patterns. - Example policy direction: set the environment’s deployment branches/tags to “Protected branches only”, and require reviewers for the environment. - GitHub documents that deployment protection rules and environment protection mechanisms can restrict which branch/tag can proceed, preventing unauthorized credential use. 4) Concrete secure template Caller workflow (example): - Pin reusable workflow ref to a commit SHA, not @dev. - Prefer explicit secret mapping for clarity/least privilege, or use secrets: inherit only if all inherited secrets are intended to be available to the called workflow. - For any deployment job that uses environment secrets (production keys), declare environment: production and configure environment protection so only protected branches can deploy. 5) Quick checklist - Reusable workflow reference: - Use @ (safest) instead of @dev / other mutable branches. - Secrets handling: - Use least-privilege token permissions (GITHUB_TOKEN minimal permissions; don’t grant more than needed). - Prefer passing only the secrets you need (explicit mapping) over secrets: inherit. - If you do use secrets: inherit, ensure the caller and reusable workflow ref are trustworthy. - Deployment gating: - Store sensitive credentials as Environment secrets (not plain vars). - Configure environment protection to restrict deployment to protected branches/tags and require reviewers. If you share a snippet of your caller + reusable workflow on: workflow_call definition, I can rewrite it into a hardened version (including the correct jobs..secrets mapping and environment gating).
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://docs.github.com/actions/using-workflows/reusing-workflows
- 3: https://docs.github.com/actions/security-guides/using-secrets-in-github-actions
- 4: https://docs.github.com/en/actions/reference/secure-use-reference
- 5: https://github.blog/security/application-security/implementing-least-privilege-for-secrets-in-github-actions
- 6: https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
- 7: https://github.blog/changelog/2021-02-17-github-actions-limit-which-branches-can-deploy-to-an-environment
Critical: avoid @dev + secrets: inherit on external reusable workflow.
Line 10 uses a mutable branch reference, and Line 11 inherits all secrets. This creates a supply-chain risk: an unauthorized push to the upstream dev branch can inject code that accesses all your repository's secrets. Pin to an immutable commit SHA and pass only required secrets explicitly.
Suggested mitigation
jobs:
pip_audit:
- uses: OpenVoiceOS/gh-automations/.github/workflows/pip-audit.yml@dev
- secrets: inherit
+ uses: OpenVoiceOS/gh-automations/.github/workflows/pip-audit.yml@<full_commit_sha>
+ secrets:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/pip_audit.yml around lines 10 - 11, Replace the mutable
reusable-workflow reference and blanket secret inheritance: change the uses
reference "OpenVoiceOS/gh-automations/.github/workflows/pip-audit.yml@dev" to an
immutable commit SHA (pin to a specific commit) and remove "secrets: inherit",
then explicitly pass only the minimal required secrets (e.g., list the specific
secret names) to the reusable workflow instead of inheriting all secrets.
| jobs: | ||
| publish_stable: | ||
| if: github.actor != 'github-actions[bot]' | ||
| uses: OpenVoiceOS/gh-automations/.github/workflows/publish-stable.yml@dev |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify mutable workflow refs in repo workflows
rg -n 'uses:\s*[^#\n]+@(dev|main|master)\b' .github/workflowsRepository: JarbasHiveMind/HiveMind-cli
Length of output: 1879
Pin reusable workflow to an immutable SHA.
Line 14 uses @dev, which is mutable. This makes release behavior non-reproducible and weakens CI supply-chain integrity. Replace with a specific commit SHA.
Suggested fix
- uses: OpenVoiceOS/gh-automations/.github/workflows/publish-stable.yml@dev
+ uses: OpenVoiceOS/gh-automations/.github/workflows/publish-stable.yml@<pinned-commit-sha>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish_stable.yml at line 14, The reusable workflow
invocation "uses:
OpenVoiceOS/gh-automations/.github/workflows/publish-stable.yml@dev" is pinned
to the mutable ref `@dev`; replace the ref with an immutable commit SHA (the full
40-char commit hash) so the call in the publish_stable.yml workflow always
references that exact commit rather than a moving branch.
| # NOTE: python-support.yml@dev is deprecated. This file calls build-tests.yml@dev instead. | ||
| # You can rename this file to build-tests.yml if you don't already have one. | ||
| name: Build Tests | ||
|
|
||
| on: | ||
| pull_request: | ||
| branches: [dev, master, main] | ||
| workflow_dispatch: | ||
|
|
||
| jobs: | ||
| build_tests: | ||
| uses: OpenVoiceOS/gh-automations/.github/workflows/build-tests.yml@dev | ||
| secrets: inherit | ||
| with: | ||
| package_name: 'HiveMind_cli' | ||
| version_file: 'hivemind_cli_terminal/version.py' | ||
| python_versions: '["3.10", "3.11", "3.12", "3.13", "3.14"]' | ||
| test_path: 'test/' |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Deprecated workflow file should be removed.
The comment on lines 1-2 indicates this file is deprecated and suggests renaming to build-tests.yml, but build-tests.yml already exists in this PR. Having both workflows will result in duplicate CI runs for every PR.
Remove this file and keep only build-tests.yml.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/python-support.yml around lines 1 - 18, Delete the
deprecated workflow file python-support.yml from .github/workflows to avoid
duplicate CI runs; keep the existing build-tests.yml (the job named build_tests
that uses OpenVoiceOS/gh-automations/.github/workflows/build-tests.yml@dev) as
the single workflow, and ensure there are no remaining references to
python-support.yml in the repo or other workflow configs.
| jobs: | ||
| publish_alpha: | ||
| if: github.event.pull_request.merged == true || github.event_name == 'workflow_dispatch' | ||
| uses: OpenVoiceOS/gh-automations/.github/workflows/publish-alpha.yml@dev |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "release_workflow.yml" -type fRepository: JarbasHiveMind/HiveMind-cli
Length of output: 111
🏁 Script executed:
cat -n .github/workflows/release_workflow.yml | head -20Repository: JarbasHiveMind/HiveMind-cli
Length of output: 695
🌐 Web query:
GitHub Actions reusable workflow @dev mutable immutable commit SHA pinning best practice
💡 Result:
Best practice for GitHub Actions reusable workflows is to pin the called workflow reference (uses: .../.github/workflows/@) to a full commit SHA when you want immutability/stability. 1) Reusable workflows: pin to a commit SHA (most secure) - GitHub Docs: when referencing a reusable workflow from another repository, {ref} can be a SHA, tag, or branch; “Using the commit SHA is the safest option for stability and security.” - Example: jobs: call-workflow: uses: owner/repo/.github/workflows/workflow-B.yml@172239021f7ba04fe7327647b213799853a9eb89 2) Actions inside reusable workflows: pin high-risk third-party actions to full commit SHAs - GitHub recommends pinning dependency versions to a specific commit SHA; this prevents malicious code added to a new/updated branch or tag from being automatically used. - GitHub also introduced an admin policy option to “enforce SHA pinning” for actions (workflows fail if an action isn’t pinned to a full commit SHA), which is the practical enforcement mechanism to make “pin immutable” the default. 3) Mutable vs immutable references (how to think about “@dev” vs “@main”) - Tags/branches (mutable) can move to new commits without changing the reference name. - Commit SHAs are immutable references to a specific code snapshot; therefore they best match “immutable commit SHA pinning best practice” for security goals. 4) Central governance pattern - Store reusable workflow code in one repo and have callers reference it by SHA, so you get consistent, reviewable updates. - Enable org/repo policies for allowed actions/reusable workflows to enforce SHA pinning so that any non-SHA references fail CI instead of silently drifting. Notes / common nuance - “Immutable releases/tags” is a capability for action publishers (release/tag management), but as a consumer, the workflow reference you should pin for maximum security is still the called workflow ref (SHA) and any third-party actions used by it (full SHA).
Citations:
- 1: https://docs.github.com/en/actions/using-workflows/reusing-workflows?wt.mc_id=DT-MVP-5000590
- 2: https://docs.github.com/en/actions/concepts/workflows-and-actions/reusing-workflow-configurations
- 3: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 4: https://docs.github.com/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases
Pin publish-alpha reusable workflow to a commit SHA.
Line 16 references @dev (mutable). For release automation, this should be immutable to avoid unexpected behavior changes. GitHub's official documentation recommends pinning reusable workflow references to a commit SHA for maximum stability and security.
Suggested fix
- uses: OpenVoiceOS/gh-automations/.github/workflows/publish-alpha.yml@dev
+ uses: OpenVoiceOS/gh-automations/.github/workflows/publish-alpha.yml@<pinned-commit-sha>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release_workflow.yml at line 16, The reusable workflow
reference uses a mutable ref
"OpenVoiceOS/gh-automations/.github/workflows/publish-alpha.yml@dev"; replace
the '@dev' ref with an immutable commit SHA for that repo (e.g., the full
40-char commit hash of the desired commit) so the workflow is pinned; locate the
"uses: OpenVoiceOS/gh-automations/.github/workflows/publish-alpha.yml@dev" line
and update it to use the commit SHA (obtainable via git log/git rev-parse or the
GitHub commit UI) and commit the change.
1 participant
Add standard CI/CD workflows from shared-gh-workflows skill.
Summary by CodeRabbit
New Features
Chores