Add CI workflows for testing and PyInstaller releases#2
Add CI workflows for testing and PyInstaller releases#2MisterRabbit0w0 wants to merge 5 commits intoKdaiP:mainfrom
Conversation
- Add GitHub Actions test workflow (Python 3.11/3.12 matrix) - Add release workflow with PyInstaller onedir builds (Windows/Linux) - Add PyInstaller spec and entry point for standalone distribution - Support sys._MEIPASS in skill discovery for frozen builds
chore: add pytest to requirements.txt
There was a problem hiding this comment.
Pull request overview
This PR adds CI automation for running tests and producing PyInstaller-based release artifacts (Windows/Linux), plus small runtime/documentation updates to support running EchoBot from bundled executables.
Changes:
- Added GitHub Actions workflows for test runs on PRs/pushes and for tagged release builds with PyInstaller artifacts.
- Added PyInstaller build configuration (
echobot.spec) and a dedicated entry script (pyinstaller_entry.py). - Updated skill discovery to support PyInstaller’s extraction directory and revised README quick-start instructions for prebuilt binaries.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| requirements.txt | Adds pytest dependency for CI test execution. |
| pyinstaller_entry.py | Introduces PyInstaller entrypoint that runs the CLI. |
| echobot/skill_support/registry.py | Adds PyInstaller _MEIPASS search root for bundled skills. |
| echobot.spec | Defines PyInstaller analysis/collect config incl. data files and hidden imports. |
| README.md | Documents using prebuilt executables vs running from source. |
| .github/workflows/test.yml | Adds CI test workflow for Python 3.11/3.12. |
| .github/workflows/release.yml | Adds tag-driven test/build/package/release pipeline for Windows/Linux. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
.github/workflows/release.yml
Outdated
| run: Compress-Archive -Path dist/echobot/* -DestinationPath "${{ matrix.archive }}" | ||
|
|
||
| - name: Package (Linux) | ||
| if: runner.os == 'Linux' | ||
| run: tar -czf "${{ matrix.archive }}" -C dist echobot |
There was a problem hiding this comment.
The Windows zip is created from dist/echobot/* (no top-level folder), while the Linux tarball includes the echobot/ directory. This produces different extraction layouts across platforms and can make the README/run instructions inconsistent; consider packaging both archives with the same top-level directory structure (either include the folder on both, or flatten both).
|
|
||
| jobs: | ||
| test: | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
The release pipeline's test job runs only on ubuntu-latest, but the release builds Windows and Linux executables. This can let platform-specific regressions slip into tagged releases; consider running tests in a matrix that includes Windows (and/or Linux) or adding a minimal smoke-test step on each build OS before packaging.
| runs-on: ubuntu-latest | |
| strategy: | |
| matrix: | |
| os: | |
| - ubuntu-latest | |
| - windows-latest | |
| runs-on: ${{ matrix.os }} |
| - os: windows-latest | ||
| archive: echobot-windows-amd64.zip | ||
| - os: ubuntu-latest | ||
| archive: echobot-linux-amd64.tar.gz | ||
| runs-on: ${{ matrix.os }} |
There was a problem hiding this comment.
The Linux build uses ubuntu-latest, which can change over time (and often advances the minimum required glibc/libstdc++ versions). For downloadable Linux executables, this can reduce compatibility with older distros; consider pinning to a specific runner (e.g., ubuntu-22.04/20.04) or building in a compatibility-focused container image.
| echobot.exe app | ||
|
|
||
| # Linux | ||
| ./echobot app |
There was a problem hiding this comment.
The Linux quick-start command (./echobot app) assumes the echobot executable is in the current directory after extracting the release archive. With the current release workflow, the Linux tarball appears to contain a top-level echobot/ folder, so users may need to cd echobot first (or the packaging should be adjusted to match the documented layout).
| ./echobot app | |
| ./echobot/echobot app |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- add cross-platform testing, switch the system used to build releases to the ubuntu-22.04
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 7 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
.github/workflows/release.yml
Outdated
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
|
|
||
| - name: Set up Python | ||
| uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: "3.11" | ||
|
|
There was a problem hiding this comment.
The release pipeline runs the test job only on ubuntu-latest, but it produces Windows and Linux binaries. To avoid releasing a broken Windows build, consider running the test job as the same OS/Python matrix (or at least include windows-latest) before proceeding to the build job.
| runs-on: ubuntu-latest | |
| steps: | |
| - uses: actions/checkout@v4 | |
| - name: Set up Python | |
| uses: actions/setup-python@v5 | |
| with: | |
| python-version: "3.11" | |
| strategy: | |
| matrix: | |
| os: | |
| - ubuntu-latest | |
| - windows-latest | |
| runs-on: ${{ matrix.os }} | |
| steps: | |
| - uses: actions/checkout@v4 |
| # multipart (used by FastAPI file uploads) | ||
| "multipart", |
There was a problem hiding this comment.
echobot.spec declares a hidden import for the non-stdlib module "multipart", but requirements.txt doesn’t include the dependency that provides it (python-multipart). This will cause the PyInstaller build (and potentially FastAPI startup) to fail with a missing module error; either add python-multipart to the install dependencies or remove this hidden import if uploads aren’t supported in bundled builds.
| # multipart (used by FastAPI file uploads) | |
| "multipart", |
.github/workflows/test.yml
Outdated
|
|
||
| - name: Cache pip packages | ||
| uses: actions/cache@v4 | ||
| with: | ||
| path: ~/.cache/pip | ||
| key: ${{ runner.os }}-pip-${{ matrix.python-version }}-${{ hashFiles('requirements.txt') }} | ||
| restore-keys: | | ||
| ${{ runner.os }}-pip-${{ matrix.python-version }}- | ||
|
|
There was a problem hiding this comment.
The pip cache path (~/.cache/pip) is Linux-specific and won’t cache the Windows pip cache location, so the Windows matrix jobs likely won’t benefit from caching. Prefer actions/setup-python’s built-in pip caching (cache: 'pip' + cache-dependency-path) or compute the cache dir via pip cache dir and cache that path per-OS.
| - name: Cache pip packages | |
| uses: actions/cache@v4 | |
| with: | |
| path: ~/.cache/pip | |
| key: ${{ runner.os }}-pip-${{ matrix.python-version }}-${{ hashFiles('requirements.txt') }} | |
| restore-keys: | | |
| ${{ runner.os }}-pip-${{ matrix.python-version }}- | |
| cache: 'pip' | |
| cache-dependency-path: requirements.txt |
| # PyInstaller: data files are extracted under sys._MEIPASS | ||
| _meipass = getattr(sys, "_MEIPASS", None) | ||
| if _meipass: | ||
| roots.append(Path(_meipass) / "echobot" / "skills") | ||
|
|
There was a problem hiding this comment.
This adds PyInstaller-specific behavior (sys._MEIPASS search root) but there’s no unit test covering it. Since SkillRegistry.discover is already well-tested, consider adding a test that monkeypatches sys._MEIPASS to a temp dir containing an echobot/skills tree and asserts discover finds those skills when the current working directory doesn’t contain them.
- Replace actions/cache with setup-python cache: pip for cross-platform pip caching - Add unit test for PyInstaller sys._MEIPASS skill discovery
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 9 out of 10 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Install dependencies | ||
| run: | | ||
| pip install -r requirements.txt | ||
| pip install pyinstaller |
There was a problem hiding this comment.
pip install pyinstaller is unpinned in the release workflow, which makes release builds non-reproducible and can cause unexpected breakages when PyInstaller updates. Consider pinning PyInstaller to a known-good version (and optionally using constraints/lockfiles) so tag builds remain stable over time.
| pip install pyinstaller | |
| pip install "pyinstaller==6.10.0" |
This pull request introduces a full-featured build and release pipeline for the project, enabling users to download and run pre-built executables without needing a Python environment. It adds cross-platform packaging (Windows and Linux), updates documentation for easier onboarding, and ensures compatibility with PyInstaller. The changes also include continuous integration workflows for both testing and releasing, as well as code adjustments to support running from PyInstaller bundles.
Build & Release Automation:
.github/workflows/release.ymlto automate testing, building, packaging (with PyInstaller), and releasing executables for Windows and Linux, including source archives and GitHub release integration.echobot.specfor PyInstaller, specifying included assets, hidden imports, and exclusions to create standalone executables.pyinstaller_entry.pyas an entry point for PyInstaller-built executables.Testing Improvements:
.github/workflows/test.ymlto run tests on push and pull requests for multiple Python versions, ensuring code quality across environments.PyInstaller Compatibility:
echobot/skill_support/registry.pyto detect and load skills from the PyInstaller extraction directory (sys._MEIPASS), ensuring bundled skills are found at runtime.Documentation Updates:
README.mdto document the new pre-built executable workflow, making it easier for users to get started without Python, and clarified the setup steps for both binary and source-based usage.