Commit Graph

5 Commits

Author SHA1 Message Date
Eric Ratliff
8cb799d378 Working on a create command to add features 2026-02-02 19:14:50 -06:00
Eric Ratliff
e605b1cd3e Updating project to v1.1.0-beta.2.
- Project is running very well on Linux
- Project needs to be tested fully in Windows
2026-02-01 21:36:20 -06:00
Eric Ratliff
58f7962a2a v1.1.0-beta.1: add proxy integration tests (62 tests, all green)
Nine end-to-end tests for the proxy feature: 6 network tests exercising
every proxy code path through a real hyper forward proxy (TestProxy) and
a mockito origin, plus 3 CLI tests verifying flag parsing and error handling.

TestProxy binds to 127.0.0.1:0, forwards in absolute-form, counts requests
via an atomic so we can assert traffic actually traversed the proxy.

Key issues resolved during implementation:

- ENV_MUTEX serializes all tests that mutate HTTPS_PROXY/HTTP_PROXY in both
  the unit test module and the integration suite. Without it, parallel test
  execution within a single binary produces nondeterministic failures.

- reqwest's blocking::Client owns an internal tokio Runtime. Dropping it
  inside a #[tokio::test] async fn panics on tokio >= 1.49. All reqwest
  work runs inside spawn_blocking so the Client drops on a thread-pool
  thread where that's permitted.

- service_fn's closure can't carry a return-type annotation, and async
  blocks don't support one either. The handler is extracted to a named
  async fn (proxy_handler) so the compiler can see the concrete
  Result<Response, Infallible> and satisfy serve_connection's Error bound.
2026-02-01 10:21:11 -06:00
Eric Ratliff
5596f5bade fix: single source of truth for version across crate and tests
Replace all hardcoded "1.1.0" version strings with env!("CARGO_PKG_VERSION")
in src/, so Cargo.toml is the sole source for the built binary. Tests
intentionally use a separate hardcoded constant in tests/common.rs to act
as a canary — they will fail on a version bump until manually updated.

- src/project/mod.rs: add WEEVIL_VERSION const, wire into Tera context,
  generated README, and .weevil-version marker
- tests/common.rs: new file, holds EXPECTED_VERSION for all test crates
- tests/{integration,project_lifecycle,unit/config_tests}.rs: pull from
  common instead of env! or inline literals
2026-01-31 18:45:29 -06:00
Eric Ratliff
70a1acc2a1 feat: Weevil v1.0.0-beta1 - FTC Project Generator
Cross-platform tool for generating clean, testable FTC robot projects
without editing the SDK installation.

Features:
- Standalone project generation with proper separation from SDK
- Per-project SDK configuration via .weevil.toml
- Local unit testing support (no robot required)
- Cross-platform build/deploy scripts (Linux/macOS/Windows)
- Project upgrade system preserving user code
- Configuration management commands
- Comprehensive test suite (11 passing tests)
- Zero-warning builds

Architecture:
- Pure Rust implementation with embedded Gradle wrapper
- Projects use deployToSDK task to copy code to FTC SDK TeamCode
- Git-ready projects with automatic initialization
- USB and WiFi deployment with auto-detection

Commands:
- weevil new <name> - Create new project
- weevil upgrade <path> - Update project infrastructure
- weevil config <path> - View/modify project configuration
- weevil sdk status/install/update - Manage SDKs

Addresses the core problem: FTC's SDK structure forces students to
edit framework internals instead of separating concerns like industry
standard practices. Weevil enables proper software engineering workflows
for robotics education.
2026-01-25 00:17:51 -06:00