* Excellent! All checks pass. Let me provide a summary of what I've implemented:
## Summary
I have successfully added analytics for projects created by the auto setup functionality. Here are the changes made:
### 1. **Auto Project Setup Analytics** (`crates/deployment/src/lib.rs:285-312`)
- Added analytics tracking to the `trigger_auto_project_setup` function
- When projects are successfully auto-created, they now track a `project_created` event with `"source": "auto_setup"`
- The event includes standard project creation properties: `project_id`, `use_existing_repo`, `has_setup_script`, `has_dev_script`
### 2. **Manual Project Creation Analytics** (`crates/server/src/routes/projects.rs:152-164`)
- Updated the existing manual project creation analytics to include `"source": "manual"`
- This maintains the same event name (`project_created`) while distinguishing the source
### 3. **GitHub Project Creation Analytics** (`crates/server/src/routes/github.rs:175-188`)
- Added `"source": "github"` to the existing `project_created_from_github` event for consistency
- This maintains the separate event name while adding source context
### Key Benefits:
- **Same Event Name**: All project creations use `project_created` (except GitHub which has its own specialized event)
- **JSON Source Field**: Easy filtering and analysis by source type (`auto_setup`, `manual`, `github`)
- **Backward Compatible**: Existing analytics queries continue to work
- **Consistent Structure**: All events include the same base properties plus source information
The implementation allows for easy analysis of project creation patterns by source, helping understand user behavior and the effectiveness of the auto setup feature.
* Excellent! The fix has been successfully implemented. Here's what I changed:
## Background Task Fix
**Problem**: The `trigger_auto_project_setup()` was being awaited synchronously in the config update endpoint, which means users had to wait for the entire auto-setup process (filesystem scanning + project creation) to complete before getting their config update response.
**Solution**: Wrapped the auto-setup call in `tokio::spawn()` to run it as a background task:
```rust
// Before (blocking):
deployment.trigger_auto_project_setup().await;
// After (non-blocking):
let deployment_clone = deployment.clone();
tokio::spawn(async move {
deployment_clone.trigger_auto_project_setup().await;
});
```
## Benefits:
1. **Faster Response Times**: Config updates now return immediately instead of waiting for filesystem scanning and project creation
2. **Better User Experience**: Users don't experience delays when acknowledging the disclaimer
3. **Non-blocking**: The auto-setup happens in the background without affecting the main request flow
4. **Same Functionality**: The auto-setup still runs as intended, just asynchronously
The change ensures that when users acknowledge the disclaimer (which triggers auto-setup), they get an immediate response while the system quietly discovers and sets up projects in the background. This is much better UX and prevents timeouts on slower systems with many git repositories.
* Add repo discovery tests (vibe-kanban 17e3a502)
We should add a simple test for git repo discovery
* fmt
* Only compile fs tests for test builds, align project creation event names
6513793b77