Migrate from Harbor to Gitea Packages registry #270

jason.woltje · 2026-02-03T22:21:09Z

jason.woltje commented

2026-02-03 22:21:09 +00:00

Summary

Migrate container registry from Harbor to Gitea's built-in Packages feature.

Changes

Updated Files

.woodpecker.yml - Changed registry URLs and secret names
docker-compose.prod.yml - Updated image references

Registry Migration

Old	New
`reg.mosaicstack.dev` (Harbor)	`git.mosaicstack.dev` (Gitea Packages)
`reg.diversecanvas.com` (Harbor)	`git.mosaicstack.dev` (Gitea Packages)

Secret Names Changed

Old	New
`harbor_username`	`gitea_username`
`harbor_password`	`gitea_token`

Manual Steps Required

Before merging, you must update Woodpecker secrets:

Create Gitea Personal Access Token
- Go to git.mosaicstack.dev → Settings → Applications → Access Tokens
- Create token with scopes: read:package, write:package
- Save the token
Add Woodpecker Secrets
- Go to ci.mosaicstack.dev → mosaic-stack → Settings → Secrets
- Add gitea_username = your Gitea username
- Add gitea_token = token from step 1
Test Build
- Trigger a build after adding secrets
- Verify images push to Gitea Packages successfully
- Check git.mosaicstack.dev/mosaic/-/packages
Cleanup (after validation)
- Delete old Harbor secrets: harbor_username, harbor_password

Benefits

✅ Simplify infrastructure (one less service)
✅ Unified authentication with Git
✅ Eliminate Harbor 412 errors
✅ Same capabilities for our use case

Decision: jarvis-brain → EVOLUTION.md → ADR-001
Migration Guide: jarvis-brain → docs/migrations/harbor-to-gitea-packages.md
Task: jarvis-brain → harbor-gitea-migration-homelab

🤖 Generated with Claude Code

## Summary Migrate container registry from Harbor to Gitea's built-in Packages feature. ## Changes ### Updated Files - `.woodpecker.yml` - Changed registry URLs and secret names - `docker-compose.prod.yml` - Updated image references ### Registry Migration | Old | New | |-----|-----| | `reg.mosaicstack.dev` (Harbor) | `git.mosaicstack.dev` (Gitea Packages) | | `reg.diversecanvas.com` (Harbor) | `git.mosaicstack.dev` (Gitea Packages) | ### Secret Names Changed | Old | New | |-----|-----| | `harbor_username` | `gitea_username` | | `harbor_password` | `gitea_token` | ## Manual Steps Required Before merging, you must update Woodpecker secrets: 1. **Create Gitea Personal Access Token** - Go to git.mosaicstack.dev → Settings → Applications → Access Tokens - Create token with scopes: `read:package`, `write:package` - Save the token 2. **Add Woodpecker Secrets** - Go to ci.mosaicstack.dev → mosaic-stack → Settings → Secrets - Add `gitea_username` = your Gitea username - Add `gitea_token` = token from step 1 3. **Test Build** - Trigger a build after adding secrets - Verify images push to Gitea Packages successfully - Check git.mosaicstack.dev/mosaic/-/packages 4. **Cleanup (after validation)** - Delete old Harbor secrets: `harbor_username`, `harbor_password` ## Benefits ✅ Simplify infrastructure (one less service) ✅ Unified authentication with Git ✅ Eliminate Harbor 412 errors ✅ Same capabilities for our use case ## Related - **Decision**: jarvis-brain → EVOLUTION.md → ADR-001 - **Migration Guide**: jarvis-brain → docs/migrations/harbor-to-gitea-packages.md - **Task**: jarvis-brain → harbor-gitea-migration-homelab --- 🤖 Generated with Claude Code

jason.woltje added 10 commits 2026-02-03 22:21:09 +00:00

feat(#87 ): implement cross-instance identity linking for federation 70a6bc82e0

Implements FED-004: Cross-Instance Identity Linking, building on the
foundation from FED-001, FED-002, and FED-003.

New Services:
- IdentityLinkingService: Handles identity verification and mapping
  with signature validation and OIDC token verification
- IdentityResolutionService: Resolves identities between local and
  remote instances with support for bulk operations

New API Endpoints (IdentityLinkingController):
- POST /api/v1/federation/identity/verify - Verify remote identity
- POST /api/v1/federation/identity/resolve - Resolve remote to local user
- POST /api/v1/federation/identity/bulk-resolve - Bulk resolution
- GET /api/v1/federation/identity/me - Get current user's identities
- POST /api/v1/federation/identity/link - Create identity mapping
- PATCH /api/v1/federation/identity/:id - Update mapping
- DELETE /api/v1/federation/identity/:id - Revoke mapping
- GET /api/v1/federation/identity/:id/validate - Validate mapping

Security Features:
- Signature verification using remote instance public keys
- OIDC token validation before creating mappings
- Timestamp validation to prevent replay attacks
- Workspace isolation via authentication guards
- Comprehensive audit logging for all identity operations

Enhancements:
- Added SignatureService.verifyMessage() for remote signature verification
- Added FederationService.getConnectionByRemoteInstanceId()
- Extended FederationAuditService with identity logging methods
- Created comprehensive DTOs with class-validator decorators

Testing:
- 38 new tests (19 service + 7 resolution + 12 controller)
- All 132 federation tests passing
- TypeScript compilation passing with no errors
- High test coverage achieved (>85% requirement exceeded)

Technical Details:
- Leverages existing FederatedIdentity model from FED-003
- Uses RSA SHA-256 signatures for cryptographic verification
- Supports one identity mapping per remote instance per user
- Resolution service optimized for read-heavy operations
- Built following TDD principles (Red-Green-Refactor)

Closes #87

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

feat(#88 ): implement QUERY message type for federation 1159ca42a7

Implement complete QUERY message protocol for federated queries between
Mosaic Stack instances, building on existing connection infrastructure.

Database Changes:
- Add FederationMessageType enum (QUERY, COMMAND, EVENT)
- Add FederationMessageStatus enum (PENDING, DELIVERED, FAILED, TIMEOUT)
- Add FederationMessage model for tracking all federation messages
- Add workspace and connection relations

Types & DTOs:
- QueryMessage: Signed query request payload
- QueryResponse: Signed query response payload
- QueryMessageDetails: API response type
- SendQueryDto: Client request DTO
- IncomingQueryDto: Validated incoming query DTO

QueryService:
- sendQuery: Send signed query to remote instance via ACTIVE connection
- handleIncomingQuery: Process and validate incoming queries
- processQueryResponse: Handle and verify query responses
- getQueryMessages: List workspace queries with optional status filter
- getQueryMessage: Get single query message details
- Message deduplication via unique messageId
- Signature verification using SignatureService
- Timestamp validation (5-minute window)

QueryController:
- POST /api/v1/federation/query: Send query (authenticated)
- POST /api/v1/federation/incoming/query: Receive query (public, signature-verified)
- GET /api/v1/federation/queries: List queries (authenticated)
- GET /api/v1/federation/queries/🆔 Get query details (authenticated)

Security:
- All messages signed with instance private key
- All responses verified with remote public key
- Timestamp validation prevents replay attacks
- Connection status validation (must be ACTIVE)
- Workspace isolation enforced via RLS

Testing:
- 15 QueryService tests (100% coverage)
- 9 QueryController tests (100% coverage)
- All tests passing with proper mocking
- TypeScript strict mode compliance

Refs #88

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

feat(#89 ): implement COMMAND message type for federation 9501aa3867

Implements federated command messages following TDD principles and
mirroring the QueryService pattern for consistency.

## Implementation

### Schema Changes
- Added commandType and payload fields to FederationMessage model
- Supports COMMAND message type (already defined in enum)
- Applied schema changes with prisma db push

### Type Definitions
- CommandMessage: Request structure with commandType and payload
- CommandResponse: Response structure with correlation
- CommandMessageDetails: Full message details for API responses

### CommandService
- sendCommand(): Send command to remote instance with signature
- handleIncomingCommand(): Process incoming commands with verification
- processCommandResponse(): Handle command responses
- getCommandMessages(): List commands for workspace
- getCommandMessage(): Get single command details
- Full signature verification and timestamp validation
- Error handling and status tracking

### CommandController
- POST /api/v1/federation/command - Send command (authenticated)
- POST /api/v1/federation/incoming/command - Handle incoming (public)
- GET /api/v1/federation/commands - List commands (authenticated)
- GET /api/v1/federation/commands/:id - Get command (authenticated)

## Testing
- CommandService: 15 tests, 90.21% coverage
- CommandController: 8 tests, 100% coverage
- All 23 tests passing
- Exceeds 85% coverage requirement
- Total 47 tests passing (includes command tests)

## Security
- RSA signature verification for all incoming commands
- Timestamp validation to prevent replay attacks
- Connection status validation
- Authorization checks on command types

## Quality Checks
- TypeScript compilation: PASSED
- All tests: 47 PASSED
- Code coverage: >85% (90.21% for CommandService, 100% for CommandController)
- Linting: PASSED

Fixes #89

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

feat(#90 ): implement EVENT subscriptions for federation ca4f5ec011

Implement event pub/sub messaging for federation to enable real-time
event streaming between federated instances.

Features:
- Event subscription management (subscribe/unsubscribe)
- Event publishing to subscribed instances
- Event acknowledgment protocol
- Server-side event filtering based on subscriptions
- Full signature verification and connection validation

Implementation:
- FederationEventSubscription model for storing subscriptions
- EventService with complete event lifecycle management
- EventController with authenticated and public endpoints
- EventMessage, EventAck, and SubscriptionDetails types
- Comprehensive DTOs for all event operations

API Endpoints:
- POST /api/v1/federation/events/subscribe
- POST /api/v1/federation/events/unsubscribe
- POST /api/v1/federation/events/publish
- GET /api/v1/federation/events/subscriptions
- GET /api/v1/federation/events/messages
- POST /api/v1/federation/incoming/event (public)
- POST /api/v1/federation/incoming/event/ack (public)

Testing:
- 18 unit tests for EventService (89.09% coverage)
- 11 unit tests for EventController (83.87% coverage)
- All 29 tests passing
- Follows TDD red-green-refactor cycle

Technical Notes:
- Reuses existing FederationMessage model with eventType field
- Follows patterns from QueryService and CommandService
- Uses existing signature and connection infrastructure
- Supports hierarchical event type naming (e.g., "task.created")

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

feat(#91 ): implement Connection Manager UI for federation 5cf02e824b

Implemented comprehensive UI for managing federation connections:

Features:
- View existing federation connections grouped by status
- Initiate new connections to remote instances
- Accept/reject pending connection requests
- Disconnect active connections
- Display connection status, metadata, and capabilities
- PDA-friendly design throughout (no demanding language)

Components:
- ConnectionCard: Display individual connections with actions
- ConnectionList: Grouped list view with status sections
- InitiateConnectionDialog: Modal for connecting to new instances
- Connections page: Main management interface

Implementation:
- Full test coverage (42 tests, 100% passing)
- TypeScript strict mode compliance
- ESLint passing with no warnings
- Mock data for development (ready for backend integration)
- Proper error handling and loading states
- PDA-friendly language (calm, supportive, stress-free)

Status indicators:
- 🟢 Active (soft green)
- 🔵 Pending (soft blue)
- ⏸️ Disconnected (soft yellow)
- ⚪ Rejected (light gray)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

feat(#92 ): implement Aggregated Dashboard View 8178617e53

Implement unified dashboard to display tasks and events from multiple
federated Mosaic Stack instances with clear provenance indicators.

Backend Integration:
- Extended federation API client with query support (sendFederatedQuery)
- Added query message fetching functions
- Integrated with existing QUERY message type from Phase 3

Components Created:
- ProvenanceIndicator: Shows which instance data came from
- FederatedTaskCard: Task display with provenance
- FederatedEventCard: Event display with provenance
- AggregatedDataGrid: Unified grid for multiple data types
- Dashboard page at /federation/dashboard

Key Features:
- Query all ACTIVE federated connections on load
- Display aggregated tasks and events in unified view
- Clear provenance indicators (instance name badges)
- PDA-friendly language throughout (no demanding terms)
- Loading states and error handling
- Empty state when no connections available

Technical Implementation:
- Uses POST /api/v1/federation/query to send queries
- Queries each connection for tasks.list and events.list
- Aggregates responses with provenance metadata
- Handles connection failures gracefully
- 86 tests passing with >85% coverage
- TypeScript strict mode compliant
- ESLint compliant

PDA-Friendly Design:
- "Unable to reach" instead of "Connection failed"
- "No data available" instead of "No results"
- "Loading data from instances..." instead of "Fetching..."
- Calm color palette (soft blues, greens, grays)
- Status indicators: 🟢 Active, 📋 No data, ⚠️ Error

Files Added:
- apps/web/src/lib/api/federation-queries.ts
- apps/web/src/lib/api/federation-queries.test.ts
- apps/web/src/components/federation/types.ts
- apps/web/src/components/federation/ProvenanceIndicator.tsx
- apps/web/src/components/federation/ProvenanceIndicator.test.tsx
- apps/web/src/components/federation/FederatedTaskCard.tsx
- apps/web/src/components/federation/FederatedTaskCard.test.tsx
- apps/web/src/components/federation/FederatedEventCard.tsx
- apps/web/src/components/federation/FederatedEventCard.test.tsx
- apps/web/src/components/federation/AggregatedDataGrid.tsx
- apps/web/src/components/federation/AggregatedDataGrid.test.tsx
- apps/web/src/app/(authenticated)/federation/dashboard/page.tsx
- docs/scratchpads/92-aggregated-dashboard.md

Testing:
- 86 total tests passing
- Unit tests for all components
- Integration tests for API client
- PDA-friendly language verified
- TypeScript type checking passing
- ESLint passing

Ready for code review and QA testing.

Related Issues:
- Depends on #85 (FED-005: QUERY Message Type) - COMPLETED
- Depends on #91 (FED-008: Connection Manager UI) - COMPLETED
- Uses #90 (FED-007: EVENT Subscriptions) infrastructure

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

fix(#92 ): use PDA-friendly language (Target instead of Due) a8c8af21e5

Critical PDA-friendly design compliance fix.

Changed forbidden "Due:" to approved "Target:" throughout FederatedTaskCard
component and tests, per DESIGN-PRINCIPLES.md requirements.

Changes:
- FederatedTaskCard.tsx: Changed "Due: {dueDate}" to "Target: {dueDate}"
- FederatedTaskCard.test.tsx: Updated all test expectations from "Due:" to "Target:"
- Updated test names to reflect "target date" terminology

All 11 tests passing.

This ensures full compliance with PDA-friendly language guidelines:
| ❌ NEVER | ✅ ALWAYS   |
| DUE      | Target date |

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

feat(#93 ): implement agent spawn via federation 12abdfe81d

Implements FED-010: Agent Spawn via Federation feature that enables
spawning and managing Claude agents on remote federated Mosaic Stack
instances via COMMAND message type.

Features:
- Federation agent command types (spawn, status, kill)
- FederationAgentService for handling agent operations
- Integration with orchestrator's agent spawner/lifecycle services
- API endpoints for spawning, querying status, and killing agents
- Full command routing through federation COMMAND infrastructure
- Comprehensive test coverage (12/12 tests passing)

Architecture:
- Hub → Spoke: Spawn agents on remote instances
- Command flow: FederationController → FederationAgentService →
  CommandService → Remote Orchestrator
- Response handling: Remote orchestrator returns agent status/results
- Security: Connection validation, signature verification

Files created:
- apps/api/src/federation/types/federation-agent.types.ts
- apps/api/src/federation/federation-agent.service.ts
- apps/api/src/federation/federation-agent.service.spec.ts

Files modified:
- apps/api/src/federation/command.service.ts (agent command routing)
- apps/api/src/federation/federation.controller.ts (agent endpoints)
- apps/api/src/federation/federation.module.ts (service registration)
- apps/orchestrator/src/api/agents/agents.controller.ts (status endpoint)
- apps/orchestrator/src/api/agents/agents.module.ts (lifecycle integration)

Testing:
- 12/12 tests passing for FederationAgentService
- All command service tests passing
- TypeScript compilation successful
- Linting passed

Refs #93

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

feat(#94 ): implement spoke configuration UI 0495f979a7

Implements the final piece of M7-Federation - the spoke configuration UI
that allows administrators to configure their local instance's federation
capabilities and settings.

Backend Changes:
- Add UpdateInstanceDto with validation for name, capabilities, and metadata
- Implement FederationService.updateInstanceConfiguration() method
- Add PATCH /api/v1/federation/instance endpoint to FederationController
- Add audit logging for configuration updates
- Add tests for updateInstanceConfiguration (5 new tests, all passing)

Frontend Changes:
- Create SpokeConfigurationForm component with PDA-friendly design
- Create /federation/settings page with configuration management
- Add regenerate keypair functionality with confirmation dialog
- Extend federation API client with updateInstanceConfiguration and regenerateInstanceKeys
- Add comprehensive tests (10 tests, all passing)

Design Decisions:
- Admin-only access via AdminGuard
- Never expose private key in API responses (security)
- PDA-friendly language throughout (no demanding terms)
- Clear visual hierarchy with read-only and editable fields
- Truncated public key with copy button for usability
- Confirmation dialog for destructive key regeneration

All tests passing:
- Backend: 13/13 federation service tests passing
- Frontend: 10/10 SpokeConfigurationForm tests passing
- TypeScript compilation: passing
- Linting: passing
- PDA-friendliness: verified

This completes M7-Federation. All federation features are now implemented.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

feat(infra): Migrate from Harbor to Gitea Packages registry

ci/woodpecker/push/woodpecker Pipeline failed

Details

ci/woodpecker/pr/woodpecker Pipeline failed

Details

bb144a7d1c

BREAKING CHANGE: Container registry changed from Harbor to Gitea Packages

Changes:
- Update .woodpecker.yml to push to git.mosaicstack.dev instead of reg.mosaicstack.dev
- Change secret names: harbor_username/harbor_password → gitea_username/gitea_token
- Update docker-compose.prod.yml image references
- Update all three images: api, web, postgres

Registry Migration:
- Old: reg.mosaicstack.dev (Harbor)
- New: git.mosaicstack.dev (Gitea Packages)
- Old: reg.diversecanvas.com (Harbor)
- New: git.mosaicstack.dev (Gitea Packages)

Manual Steps Required:
1. Create Gitea personal access token with 'read:package' and 'write:package' scopes
2. Add Woodpecker secrets:
   - gitea_username: Your Gitea username
   - gitea_token: Personal access token from step 1
3. Test build pipeline
4. Delete old Harbor secrets after validation

Related: ADR-001 in jarvis-brain
See: jarvis-brain/docs/migrations/harbor-to-gitea-packages.md

jason.woltje added 1 commit 2026-02-04 01:33:19 +00:00

Merge branch 'develop' into harbor-to-gitea-migration

ci/woodpecker/push/woodpecker Pipeline failed

Details

ci/woodpecker/manual/woodpecker Pipeline failed

Details

ci/woodpecker/pr/woodpecker Pipeline failed

Details

f0be6a31e4

jason.woltje merged commit e31cf89437 into develop

2026-02-04 01:53:21 +00:00

jason.woltje referenced this issue from a commit

2026-02-04 01:53:21 +00:00

Merge pull request 'Migrate from Harbor to Gitea Packages registry' (#270) from harbor-to-gitea-migration into develop

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mosaic/stack#270