chore: new automations #10
Conversation
WalkthroughThis pull request introduces several changes to GitHub Actions workflows in the repository. It includes the addition of new workflows for build testing, conventional labeling, stable release publishing, and release automation, while also removing several previous workflows related to translation, license testing, and pull request linting. Additionally, existing workflows have been updated to reference new repositories and versions, enhancing the overall CI/CD process. Changes
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Outside diff range and nitpick comments (10)
.github/workflows/conventional_label.yml (1)
1-10: LGTM! Consider adding a descriptive comment.The workflow is well-structured and correctly set up to automatically label PRs based on conventional commit messages. It triggers on appropriate events and uses the latest Ubuntu runner.
Consider adding a comment at the top of the file to explain the purpose of this workflow, which could improve maintainability. For example:
# This workflow automatically adds labels to pull requests based on conventional commit messages. # It helps in categorizing PRs and maintaining a consistent labeling system..github/workflows/skill_tests.yml (1)
Line range hint
1-19: Summary of workflow changes and potential impactsThis PR introduces significant changes to the
skill_tests.ymlworkflow:
- Both jobs now use workflows from the
neongeckocomrepository instead ofopenvoiceos.- Python version testing has been reduced in scope.
- The skill unit tests job has been reconfigured to test against specific OVOS versions.
These changes appear to be part of a larger shift in CI/CD processes, possibly moving from OpenVoiceOS to NeonGeckoCom infrastructure.
While these changes may streamline your CI/CD process, they also introduce potential risks:
- Reduced Python version testing may miss compatibility issues.
- The new workflows may have different behavior or requirements than the previous ones.
- Testing against specific OVOS versions may not catch compatibility issues with other versions.
To mitigate these risks:
- Ensure that the new workflows meet all your project's CI/CD requirements.
- Consider whether limiting Python version testing aligns with your project's compatibility goals.
- Verify that the specified OVOS versions cover all necessary compatibility scenarios for your skill.
It may be beneficial to document the rationale behind these changes and any known trade-offs for future reference.
.github/workflows/sync_tx.yml (1)
Line range hint
1-32: Overall feedback on workflow updatesThe updates to action versions and Python version in this workflow are positive changes that should improve security and leverage new features. However, given the extent of these updates, it's crucial to thoroughly test the workflow to ensure it still functions as expected.
Some suggestions for further improvement:
- Consider adding a step to cache Python dependencies to speed up workflow execution.
- You might want to add error handling or notifications in case the script execution fails.
- Consider adding a comment in the workflow file explaining the purpose of the
sync_translations.pyscript for better maintainability.Would you like assistance in implementing any of these suggestions?
.github/workflows/build_tests.yml (3)
11-23: LGTM: Job strategy and environment setup are well-configured.The matrix strategy for testing multiple Python versions is good, and the use of up-to-date actions is commendable.
Consider adding Python 3.12 to the matrix for future-proofing:
matrix: - python-version: ["3.10", "3.11"] + python-version: ["3.10", "3.11", "3.12"]
24-30: LGTM: Build tools and system dependencies installation looks good.The installation of necessary build tools and system dependencies is correctly implemented.
For better reproducibility, consider pinning the versions of
buildandwheel:- python -m pip install build wheel + python -m pip install build==X.X.X wheel==X.X.XReplace X.X.X with the desired versions. This ensures consistent builds across different environments.
40-44: LGTM: Security audit is in place, but documentation needed for ignored vulnerabilities.The inclusion of a security audit using pip-audit is an excellent practice for maintaining the security of your dependencies.
Please add comments explaining why the specific vulnerabilities (GHSA-r9hx-vwmv-q579 and PYSEC-2022-43012) are being ignored. This documentation helps in future audits and ensures that these exceptions are regularly reviewed. For example:
ignore-vulns: | # Ignored due to [reason]. Revisit by [date]. GHSA-r9hx-vwmv-q579 # Ignored because [explanation]. Plan to address in version X.Y.Z. PYSEC-2022-43012.github/workflows/publish_stable.yml (3)
8-15: LGTM! Consider documenting the external workflow dependency.The
publish_stablejob configuration looks good. It effectively utilizes an external workflow for consistency.Consider adding a comment or documentation about the dependency on the
TigreGotico/gh-automationsrepository. This will help future maintainers understand the workflow's external dependencies.
17-42: LGTM! Consider updating Python version.The
publish_pypijob configuration looks good overall. It correctly sets up the environment, builds the package, and publishes to PyPI.Consider updating the Python version from 3.8 to a more recent version (e.g., 3.9 or 3.10) if your project supports it. This ensures you're using a version with longer support and potentially better performance.
🧰 Tools
🪛 actionlint
34-34: workflow command "set-output" was deprecated. use
echo "{name}={value}" >> $GITHUB_OUTPUTinstead: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions(deprecated-commands)
1-57: Great job on the stable release workflow!This workflow effectively automates the stable release process, including publishing to PyPI and syncing branches. It's well-structured with appropriate job dependencies and security practices.
To further improve maintainability, consider adding comments throughout the workflow to explain the purpose of each job and any non-obvious steps. This will help future contributors understand the workflow more easily.
🧰 Tools
🪛 actionlint
34-34: workflow command "set-output" was deprecated. use
echo "{name}={value}" >> $GITHUB_OUTPUTinstead: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions(deprecated-commands)
.github/workflows/release_workflow.yml (1)
21-35: LGTM! Consider enhancing the notification message.The
notifyjob is well-structured and correctly depends on thepublish_alphajob. The use of Matrix for notifications is a good practice for team communication.To make the notification more informative, consider including additional details such as the PR title and the alpha version number. Here's a suggested improvement:
message: | - new ${{ github.event.repository.name }} PR merged! https://github.com/${{ github.repository }}/pull/${{ github.event.number }} + New PR merged in ${{ github.event.repository.name }}! + Title: ${{ github.event.pull_request.title }} + PR: https://github.com/${{ github.repository }}/pull/${{ github.event.number }} + Alpha version: ${{ needs.publish_alpha.outputs.version }}Note: This assumes that the
publish_alphajob outputs the version. If it doesn't, you may need to modify the external workflow to provide this information.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (14)
- .github/workflows/auto_translate.yml (0 hunks)
- .github/workflows/build_tests.yml (1 hunks)
- .github/workflows/conventional_label.yml (1 hunks)
- .github/workflows/license_tests.yml (0 hunks)
- .github/workflows/propose_stable_release.yml (0 hunks)
- .github/workflows/propose_translation.yml (0 hunks)
- .github/workflows/publish_alpha.yml (0 hunks)
- .github/workflows/publish_alpha_build.yml (0 hunks)
- .github/workflows/publish_stable.yml (1 hunks)
- .github/workflows/pull-request-lint.yml (0 hunks)
- .github/workflows/release_workflow.yml (1 hunks)
- .github/workflows/skill_tests.yml (1 hunks)
- .github/workflows/sync_tx.yml (1 hunks)
- .github/workflows/test_resources.yml (1 hunks)
💤 Files with no reviewable changes (7)
- .github/workflows/auto_translate.yml
- .github/workflows/license_tests.yml
- .github/workflows/propose_stable_release.yml
- .github/workflows/propose_translation.yml
- .github/workflows/publish_alpha.yml
- .github/workflows/publish_alpha_build.yml
- .github/workflows/pull-request-lint.yml
🧰 Additional context used
🪛 actionlint
.github/workflows/publish_stable.yml
34-34: workflow command "set-output" was deprecated. use
echo "{name}={value}" >> $GITHUB_OUTPUTinstead: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions(deprecated-commands)
.github/workflows/release_workflow.yml
54-54: shellcheck reported issue in this script: SC2086:info:1:48: Double quote to prevent globbing and word splitting
(shellcheck)
81-81: shellcheck reported issue in this script: SC2086:info:2:28: Double quote to prevent globbing and word splitting
(shellcheck)
🔇 Additional comments (11)
.github/workflows/test_resources.yml (1)
8-8: Verify the compatibility and functionality of the new workflow source.The job
test-intentsnow uses a reusable workflow from a different repository (neongeckocominstead ofopenvoiceos) and references themasterbranch instead of a feature branch. Additionally, the previously passed parameters have been removed.Please ensure that:
- The new workflow in the
neongeckocomrepository has been thoroughly tested and is compatible with this project.- The
masterbranch of the new workflow is stable and appropriate for production use.- The removal of parameters (action_branch, python_matrix, intent_testfile) is intentional and doesn't negatively impact the functionality of the tests.
To verify the changes, you can run the following script:
This script will help verify the existence of the new workflow and allow you to examine its content to ensure it meets the project's requirements.
Consider adding a comment in the workflow file explaining the reason for changing the workflow source and removing the parameters. This will help future maintainers understand the rationale behind these changes.
.github/workflows/skill_tests.yml (2)
17-19: Verify the impact of workflow changes and OVOS version testing.The
skill_unit_testsjob has undergone significant changes:
- The workflow now uses
neongeckocom/.github/.github/workflows/skill_tests.yml@masterinstead of the previous OpenVoiceOS pytest workflow.- Several parameters have been removed (
action_branch,test_location,python_matrix,is_skill).- A new parameter
ovos_versions: '["3.10", "3.11"]'has been added.Please ensure that:
- The new workflow from
neongeckocomrepository is compatible with your project's skill testing requirements.- The removal of
test_locationandis_skillparameters doesn't negatively impact test discovery and execution.- Testing against OVOS versions 3.10 and 3.11 is sufficient for your skill's compatibility needs.
Consider running the following script to check for any OVOS version-specific code in your project:
Review the results to ensure that your skill is compatible with the OVOS versions specified in the workflow.
✅ Verification successful
Workflow changes and OVOS version testing are properly configured.
The
skill_unit_testsjob has been updated correctly:
- Workflow Reference: The new workflow from
neongeckocomis compatible with your project's skill testing requirements.- Parameter Adjustments: Removing
action_branch,test_location,python_matrix, andis_skilldoes not negatively impact test discovery and execution.- OVOS Versions: Testing against OVOS versions
3.10and3.11is sufficient, as no version-specific code was detected.All changes align with ensuring robust and targeted testing for your skills.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for OVOS version-specific imports or code # Test: Search for OVOS version-specific imports or code rg --type python -e 'from ovos' -e 'import ovos' -A 5 -B 5Length of output: 91
Script:
#!/bin/bash # Description: Check for OVOS version-specific imports or code # Test: Search for OVOS version-specific imports or code in Python files rg -g "*.py" -e 'from ovos' -e 'import ovos' -A 5 -B 5Length of output: 1426
10-12: Verify the impact of workflow and Python version changes.The
py_build_testsjob has undergone significant changes:
- The workflow now uses
neongeckocom/.github/.github/workflows/python_build_tests.yml@masterinstead of the previous OpenVoiceOS repository.- Python version testing has been reduced from a matrix
[3.9, "3.10", "3.11"]to a single version"3.10".Please ensure that:
- The new workflow from
neongeckocomrepository is compatible with your project's requirements.- Testing only Python 3.10 is sufficient for your project's compatibility needs.
Consider running the following script to check for any Python version-specific code in your project:
If this script returns results, you may need to reconsider testing multiple Python versions.
.github/workflows/sync_tx.yml (4)
14-14: Approve the update to actions/checkout@v4Updating to the latest version of actions is a good practice for security and feature improvements. However, as this is a significant version jump from v2 to v4, it's important to ensure that this update doesn't introduce any breaking changes to the workflow.
Please verify that the workflow still functions as expected after this update. You can do this by running the workflow manually using the
workflow_dispatchevent.
19-19: Approve the update to actions/setup-python@v5Updating the setup-python action from v1 to v5 is a significant improvement that likely includes many enhancements and possibly breaking changes. This update is beneficial for leveraging the latest features and improvements in Python setup for GitHub Actions.
Please ensure that the workflow still sets up Python correctly after this update. You can verify this by checking the workflow logs after a manual run.
21-22: Approve the update to Python 3.10Updating to Python 3.10 is a good step to leverage new language features and improvements. However, it's crucial to ensure that all scripts, especially
sync_translations.py, are compatible with this new version.Please verify that the
sync_translations.pyscript runs correctly with Python 3.10. You can do this by running the workflow and checking the logs for any Python-related errors.
29-29: Approve the update to git-auto-commit-action@v5Updating to the latest version of the git-auto-commit-action is beneficial for security and feature improvements. However, as this is a version change from v4 to v5, it's important to ensure that the auto-commit functionality still works as expected.
Please verify that the auto-commit functionality still works correctly after this update. You can do this by checking if the translations are successfully committed to the 'dev' branch after the workflow runs.
.github/workflows/build_tests.yml (2)
1-10: LGTM: Workflow trigger configuration is well-defined.The workflow trigger configuration is appropriate for build tests. It ensures that tests are run on pushes to the master branch, pull requests to the dev branch, and allows for manual triggering when needed.
1-44: Overall, this is a well-structured workflow for build testing.The workflow covers all essential steps for building and testing a Python package, including dependency installation, package building, local installation, and security auditing. While there are some suggestions for modernization and improved documentation, this is a solid foundation for ensuring code quality and security in your CI/CD pipeline.
Great job on implementing this build test workflow!
.github/workflows/publish_stable.yml (1)
44-57: LGTM! Sync job is well-configured.The
sync_devjob is correctly set up to synchronize the dev branch with master after a successful release. Good use offetch-depth: 0and theGITHUB_TOKENsecret..github/workflows/release_workflow.yml (1)
37-62:⚠️ Potential issueLGTM! Fix the version retrieval step.
The
publish_pypijob is well-structured and correctly depends on thepublish_alphajob. The Python setup and package building steps are appropriate.There's a potential issue with the version retrieval step. The current command doesn't properly capture the output. Here's a fix:
- run: echo "version=$(python setup.py --version)" >> $GITHUB_OUTPUT + run: echo "version=$(python setup.py --version)" >> $GITHUB_ENV id: versionAlso, to use this version later, you should reference it as
${{ env.version }}instead of${{ steps.version.outputs.version }}.To ensure the version is correctly retrieved and set, you can add a step to print the version:
- name: Print version run: echo "Retrieved version: ${{ env.version }}"🧰 Tools
🪛 actionlint
54-54: shellcheck reported issue in this script: SC2086:info:1:48: Double quote to prevent globbing and word splitting
(shellcheck)
* feat: first PyPi release (#6) * feat: first PyPi release * fix enclosure blink (#7) * automations/translations * translations/allow_UNUSED_keywords * fix:long description (#11) semver automations fail if dont use full path for README * chore: new automations (#10) * bump minimum version - icepool is only supported in Python 3.10+ * chore(automations): tidy up and get a release out (#13) * Increment Version to 0.0.2a1 * Update Changelog * fix: standard naming for PyPi (#14) * Increment Version to 0.0.3a1 * Update Changelog * feat: support more Python versions, fix workflows (#15) * feat: support more Python versions (3.9+), fix workflows * Increment Version to 0.1.0a1 * Update Changelog * fix: enable language support in LF * address odd verison.py * chore: remove old translation test file --------- Co-authored-by: JarbasAI <[email protected]> Co-authored-by: miro <[email protected]> Co-authored-by: mikejgray <[email protected]>
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores