refactor: image update indicator #340
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis change removes the entire image maturity tracking feature from both the backend and frontend, replacing it with a new image update tracking system. All related models, services, API endpoints, UI components, and TypeScript types for maturity are deleted or refactored, and new counterparts for image update checks, version management, and update status display are introduced throughout the codebase. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Frontend
participant ImageUpdateAPIService
participant BackendAPI
participant ImageUpdateHandler
participant ImageUpdateService
participant Registry/Docker
User->>Frontend: Click "Check Updates" or view image table
Frontend->>ImageUpdateAPIService: checkImageUpdateByID(imageId)
ImageUpdateAPIService->>BackendAPI: POST /image-updates/check/:imageId
BackendAPI->>ImageUpdateHandler: CheckImageUpdateByID
ImageUpdateHandler->>ImageUpdateService: CheckImageUpdateByID(imageId)
ImageUpdateService->>Registry/Docker: Inspect local image, query registry for digest/tags
Registry/Docker-->>ImageUpdateService: Return current/latest digest, version info
ImageUpdateService-->>ImageUpdateHandler: Return update status/result
ImageUpdateHandler-->>BackendAPI: Respond with update info
BackendAPI-->>ImageUpdateAPIService: JSON response (update info)
ImageUpdateAPIService-->>Frontend: Return update info
Frontend-->>User: Display update status in UI
Possibly related PRs
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
built with Refined Cloudflare Pages Action⚡ Cloudflare Pages Deployment
|
…filtering/sorting functionality
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🔭 Outside diff range comments (2)
backend/internal/services/image_service.go (2)
455-469: Method name still references "Maturity"The method
GetImagesNeedingMaturityCheckshould be renamed toGetImagesNeedingUpdateCheckto align with the new update-based system.-func (s *ImageService) GetImagesNeedingMaturityCheck(ctx context.Context, olderThan time.Duration) ([]*models.Image, error) { +func (s *ImageService) GetImagesNeedingUpdateCheck(ctx context.Context, olderThan time.Duration) ([]*models.Image, error) {Also update the Preload:
- Preload("MaturityRecord"). + Preload("UpdateRecord").And the table reference:
- Where("id NOT IN (SELECT id FROM image_maturity_table WHERE last_checked > ?)", cutoff) + Where("id NOT IN (SELECT id FROM image_update_table WHERE check_time > ?)", cutoff)
455-469: Remove dead maturity-related methodThe method
GetImagesNeedingMaturityCheck(lines 455-469) still references the old maturity system and should be removed as it's been replaced byGetImagesNeedingUpdateCheck(lines 471-485).This entire method should be deleted as it references non-existent
MaturityRecordandimage_maturity_table.
🧹 Nitpick comments (8)
frontend/src/routes/environments/+page.svelte (3)
43-51: Simplify the redundant id mappingThe environments already have an
idproperty, so mapping{ ...env, id: env.id }is redundant.-let paginatedEnvironments = $derived<Paginated<Environment & { id: string }>>({ - data: environments.map((env) => ({ ...env, id: env.id })), +let paginatedEnvironments = $derived<Paginated<Environment>>({ + data: environments,
53-57: Consider the pagination limit configurationThe
requestOptionssets a pagination limit of 100, but the ArcaneTable is configured withwithoutPagination={true}. This seems inconsistent - consider either removing the pagination configuration or enabling pagination in the table.
234-417: Consider decomposing this large componentThis component is quite large (400+ lines) and handles multiple responsibilities. Consider extracting some parts into smaller, focused components for better maintainability.
Potential extractions:
- Environment list/table section →
<EnvironmentList />- Empty state section (lines 286-304) →
<EnvironmentsEmptyState />- Bulk actions toolbar →
<EnvironmentActions />This would improve:
- Code reusability
- Testing isolation
- Component readability
- Maintenance overhead
.github/copilot-instructions.md (1)
29-29: Add language specifiers to fenced code blocks.The markdown linter indicates that fenced code blocks should have language specifiers for proper syntax highlighting.
-``` +```text backend/ ├── cmd/main.go # Application entry point-``` +```text frontend/src/ ├── routes/ # SvelteKit file-based routingAlso applies to: 73-73
frontend/src/lib/components/meter-metric.svelte (1)
36-79: UI redesign looks good but seems unrelated to the main refactoring.These styling changes modernize the component's appearance but appear unrelated to the image maturity to update refactoring. Consider splitting pure UI updates into separate PRs for clearer change tracking.
backend/internal/services/auto_update_service.go (1)
770-782: Consider extracting registry normalization to a shared utilityThe registry URL normalization logic is duplicated here and in other services. Consider moving this to the
RegistryUtilsto maintain consistency.backend/internal/utils/registry_utils.go (1)
225-268: Consider adding a safety limit for tag retrievalThe method could potentially retrieve an unbounded number of tags, which might cause memory issues for repositories with thousands of tags.
Consider adding a maximum limit parameter or implementing streaming/callback-based processing for large tag lists.
backend/internal/services/image_update_service.go (1)
353-421: Add documentation for complex parsing logicThis method handles many edge cases and formats. Consider adding detailed comments explaining the various formats supported.
Add a method comment like:
// parseImageReference parses various Docker image reference formats: // - Simple name: "nginx" -> docker.io/library/nginx:latest // - With tag: "nginx:1.21" -> docker.io/library/nginx:1.21 // - With registry: "gcr.io/project/image:tag" // - With digest: "image@sha256:..."
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (40)
.github/copilot-instructions.md(1 hunks)backend/internal/api/image_handler.go(2 hunks)backend/internal/api/image_maturity_handler.go(0 hunks)backend/internal/api/image_update_handler.go(1 hunks)backend/internal/api/routes.go(4 hunks)backend/internal/bootstrap/jobs_bootstrap.go(0 hunks)backend/internal/bootstrap/services_bootstrap.go(1 hunks)backend/internal/database/database.go(1 hunks)backend/internal/dto/image_dto.go(0 hunks)backend/internal/dto/image_update_dto.go(1 hunks)backend/internal/job/image_maturity_job.go(0 hunks)backend/internal/models/docker.go(1 hunks)backend/internal/models/image_maturity.go(0 hunks)backend/internal/models/image_update.go(1 hunks)backend/internal/services/auto_update_service.go(2 hunks)backend/internal/services/image_maturity_service.go(0 hunks)backend/internal/services/image_service.go(6 hunks)backend/internal/services/image_update_service.go(1 hunks)backend/internal/utils/registry_utils.go(1 hunks)backend/internal/utils/version.go(1 hunks)frontend/src/lib/components/dropdown-card.svelte(1 hunks)frontend/src/lib/components/image-update-item.svelte(1 hunks)frontend/src/lib/components/maturity-item.svelte(0 hunks)frontend/src/lib/components/meter-metric.svelte(1 hunks)frontend/src/lib/components/universal-table.svelte(0 hunks)frontend/src/lib/models/image.type.ts(1 hunks)frontend/src/lib/services/api/image-maturity-api-service.ts(0 hunks)frontend/src/lib/services/api/image-update-api-service.ts(1 hunks)frontend/src/lib/services/api/index.ts(4 hunks)frontend/src/lib/stores/maturity-store.ts(0 hunks)frontend/src/lib/types/auto-update.type.ts(0 hunks)frontend/src/lib/types/errors.ts(0 hunks)frontend/src/lib/types/errors.type.ts(0 hunks)frontend/src/lib/types/loading-states.type.ts(0 hunks)frontend/src/routes/dashboard/+page.svelte(1 hunks)frontend/src/routes/dashboard/+page.ts(1 hunks)frontend/src/routes/dashboard/dash-image-table.svelte(0 hunks)frontend/src/routes/environments/+page.svelte(11 hunks)frontend/src/routes/images/+page.svelte(4 hunks)frontend/src/routes/images/image-table.svelte(8 hunks)
💤 Files with no reviewable changes (15)
- backend/internal/dto/image_dto.go
- backend/internal/bootstrap/jobs_bootstrap.go
- frontend/src/lib/types/loading-states.type.ts
- backend/internal/job/image_maturity_job.go
- frontend/src/routes/dashboard/dash-image-table.svelte
- frontend/src/lib/types/auto-update.type.ts
- frontend/src/lib/stores/maturity-store.ts
- frontend/src/lib/services/api/image-maturity-api-service.ts
- frontend/src/lib/components/maturity-item.svelte
- frontend/src/lib/types/errors.ts
- frontend/src/lib/components/universal-table.svelte
- backend/internal/models/image_maturity.go
- frontend/src/lib/types/errors.type.ts
- backend/internal/api/image_maturity_handler.go
- backend/internal/services/image_maturity_service.go
🧰 Additional context used
🧠 Learnings (5)
frontend/src/lib/components/dropdown-card.svelte (2)
Learnt from: kmendell
PR: ofkm/arcane#86
File: src/lib/components/table-cells/user-table-actions.svelte:15-15
Timestamp: 2025-04-30T01:20:17.798Z
Learning: This project uses Svelte 5 with the runes syntax, where props are declared using `$props()` rather than the older `export let` pattern.
Learnt from: kmendell
PR: ofkm/arcane#69
File: src/routes/stacks/new/+page.svelte:27-33
Timestamp: 2025-04-26T04:11:03.082Z
Learning: The project uses a custom `preventDefault` wrapper function instead of Svelte event modifiers, and we should respect this pattern in code suggestions.
.github/copilot-instructions.md (1)
Learnt from: kmendell
PR: ofkm/arcane#86
File: src/lib/components/table-cells/user-table-actions.svelte:15-15
Timestamp: 2025-04-30T01:20:17.798Z
Learning: This project uses Svelte 5 with the runes syntax, where props are declared using `$props()` rather than the older `export let` pattern.
frontend/src/routes/environments/+page.svelte (1)
Learnt from: kmendell
PR: ofkm/arcane#86
File: src/lib/components/table-cells/user-table-actions.svelte:15-15
Timestamp: 2025-04-30T01:20:17.798Z
Learning: This project uses Svelte 5 with the runes syntax, where props are declared using `$props()` rather than the older `export let` pattern.
frontend/src/routes/images/+page.svelte (1)
Learnt from: kmendell
PR: ofkm/arcane#86
File: src/lib/components/table-cells/user-table-actions.svelte:15-15
Timestamp: 2025-04-30T01:20:17.798Z
Learning: This project uses Svelte 5 with the runes syntax, where props are declared using `$props()` rather than the older `export let` pattern.
frontend/src/lib/components/image-update-item.svelte (1)
Learnt from: kmendell
PR: ofkm/arcane#86
File: src/lib/components/table-cells/user-table-actions.svelte:15-15
Timestamp: 2025-04-30T01:20:17.798Z
Learning: This project uses Svelte 5 with the runes syntax, where props are declared using `$props()` rather than the older `export let` pattern.
🧬 Code Graph Analysis (11)
backend/internal/database/database.go (1)
backend/internal/models/image_update.go (1)
ImageUpdateRecord(7-24)
backend/internal/models/docker.go (1)
backend/internal/models/image_update.go (1)
ImageUpdateRecord(7-24)
frontend/src/lib/services/api/index.ts (1)
frontend/src/lib/services/api/image-update-api-service.ts (1)
ImageUpdateAPIService(48-83)
backend/internal/api/routes.go (4)
backend/internal/services/image_service.go (1)
ImageService(27-32)backend/internal/services/image_update_service.go (1)
ImageUpdateService(16-21)backend/internal/api/image_update_handler.go (1)
NewImageUpdateHandler(16-20)backend/internal/api/image_handler.go (1)
NewImageHandler(20-25)
frontend/src/lib/services/api/image-update-api-service.ts (2)
backend/internal/services/image_update_service.go (1)
VersionComparison(56-62)backend/internal/dto/image_update_dto.go (2)
BatchImageUpdateRequest(40-42)CompareVersionRequest(46-50)
backend/internal/api/image_handler.go (2)
backend/internal/services/image_service.go (1)
ImageService(27-32)backend/internal/services/image_update_service.go (1)
ImageUpdateService(16-21)
frontend/src/routes/dashboard/+page.ts (2)
frontend/src/lib/types/pagination.type.ts (1)
SearchPaginationSortRequest(13-18)frontend/src/lib/services/api/index.ts (2)
systemAPI(18-18)settingsAPI(21-21)
backend/internal/services/image_service.go (6)
backend/internal/database/database.go (1)
DB(18-20)backend/internal/services/docker_client_service.go (1)
DockerClientService(11-13)backend/internal/services/image_update_service.go (1)
ImageUpdateService(16-21)backend/internal/services/container_registry_service.go (1)
ContainerRegistryService(15-17)backend/internal/models/image_update.go (1)
ImageUpdateRecord(7-24)backend/internal/models/docker.go (1)
Image(74-90)
backend/internal/models/image_update.go (2)
backend/internal/models/docker.go (1)
Image(74-90)backend/internal/models/base.go (1)
BaseModel(11-14)
backend/internal/api/image_update_handler.go (3)
backend/internal/services/image_update_service.go (1)
ImageUpdateService(16-21)backend/internal/dto/image_update_dto.go (7)
ImageUpdateResponse(5-15)BatchImageUpdateRequest(40-42)BatchImageUpdateResponse(44-44)ImageUpdateSummaryResponse(17-23)ImageVersionsResponse(25-30)CompareVersionRequest(46-50)VersionComparisonResponse(32-38)frontend/src/lib/services/api/image-update-api-service.ts (2)
BatchImageUpdateRequest(38-40)CompareVersionRequest(42-46)
backend/internal/services/auto_update_service.go (1)
backend/internal/utils/registry_utils.go (3)
NewRegistryUtils(32-34)RegistryCredentials(16-19)ExtractRegistryDomain(338-347)
🪛 markdownlint-cli2 (0.17.2)
.github/copilot-instructions.md
29-29: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
73-73: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (54)
frontend/src/lib/components/dropdown-card.svelte (1)
66-68: LGTM! Clean formatting improvement.The multi-line formatting of the
LucideChevronDowncomponent improves readability while preserving all functionality and class bindings.frontend/src/routes/dashboard/+page.ts (1)
6-70: LGTM! Improved code formatting and readability.The reformatting enhances code readability with better indentation and line breaks while preserving all existing functionality. The load function continues to properly fetch Docker info, containers, images, and settings with appropriate error handling.
backend/internal/utils/version.go (1)
5-9: LGTM! Well-designed regex patterns for version parsing.The three regex patterns are correctly implemented for their respective version formats:
SemanticVersionRegex: Properly handles semantic versioning with optional pre-release suffixesDateVersionRegex: Accurately matches date-based versions (YYYY.M.D format)NumericVersionRegex: Flexibly handles 1-3 component numeric versionsAll patterns use proper anchoring and capture groups to support the new image update service functionality.
.github/copilot-instructions.md (1)
1-188: Excellent comprehensive project documentation!This is a very well-structured and thorough documentation that covers all essential aspects of the Arcane project including architecture, conventions, patterns, and guidelines. It properly documents Svelte 5 syntax patterns and provides valuable guidance for both backend (Go) and frontend (SvelteKit) development.
backend/internal/database/database.go (1)
93-93: LGTM! Database migration correctly updated for the refactor.The migration from
ImageMaturityRecordtoImageUpdateRecordis properly implemented and aligns with the broader refactor replacing image maturity tracking with image update tracking. TheImageUpdateRecordmodel has a well-defined structure with appropriate fields for tracking update status, versions, digests, and error handling.backend/internal/models/docker.go (1)
87-87: LGTM! Improved field naming and alignment with new update tracking system.The replacement of
MaturityRecordwithUpdateRecordis well-implemented. The JSON tag change from "maturityRecord" to "updateInfo" provides better clarity for API consumers about the field's purpose.frontend/src/lib/services/api/index.ts (1)
2-2: LGTM! Consistent API service refactoring.All references to the image maturity API service have been consistently replaced with the new image update API service. The naming convention is clear and the service integration is properly maintained across imports, exports, interface definitions, and object instantiation.
Also applies to: 17-17, 33-33, 50-50
frontend/src/routes/dashboard/+page.svelte (1)
23-23: Clean removal of maturity functionality
- Removed unused
imageAPIandmaturityStoreimports infrontend/src/routes/dashboard/+page.svelte.- No update‐related logic detected in any dashboard component (e.g.
dash-image-table.svelte).- Update endpoints do exist in services (
image-update-api-service.ts,autoupdate-api-service.ts), but no UI integration is present.Ensure the dashboard still fulfills its monitoring requirements without maturity data, or integrate the appropriate update checks and UI if you intend to surface image‐update information.
backend/internal/bootstrap/services_bootstrap.go (1)
22-23: LGTM! Proper service dependency injection and initialization.The
ImageUpdateServiceinitialization with all required dependencies is correct, and the updatedImageServiceconstructor properly receives the new dependency. The service is appropriately exposed in theapi.Servicesstruct for use by handlers.Also applies to: 49-49
frontend/src/lib/models/image.type.ts (3)
4-32: LGTM! Clean code formatting.The
ServiceImagetype formatting has been improved with consistent indentation while maintaining all existing functionality.
34-44: Excellent comprehensive interface design for image update tracking.The
ImageUpdateInfointerface is well-designed with comprehensive fields covering all aspects of update tracking:
- Update status and type classification
- Version and digest information for comparison
- Timing data for performance monitoring
- Error handling for failed checks
The field names are descriptive and follow TypeScript naming conventions.
47-48: LGTM! Consistent property naming update.The replacement of the
maturityproperty withupdateInfomaintains the same optional structure while aligning with the new update tracking system and improved naming conventions.backend/internal/api/image_handler.go (2)
15-25: LGTM! Clean refactoring of service dependencies.The struct and constructor have been properly updated to replace the maturity service with the update service.
44-44: Method call correctly updated to use update-based listing.The change from maturity-based to update-based image listing is consistent with the refactoring.
backend/internal/api/routes.go (2)
48-48: Route setup correctly updated.The maturity routes have been properly replaced with image update routes.
286-286: ImageHandler instantiation correctly updated.The handler now properly receives both the image service and image update service.
frontend/src/routes/images/image-table.svelte (4)
26-26: Component import and props correctly updated.The import and prop names have been properly refactored to use update terminology instead of maturity.
Also applies to: 41-42, 49-49
52-57: Good addition of update status filters.The new filters for images with/without updates follow the established pattern and provide useful filtering options.
73-85: Well-structured filtering logic.The filtering correctly combines usage and update status with AND logic, providing intuitive filter behavior.
169-173: UI elements correctly updated for image updates.All UI changes are consistent with the refactoring:
- Filter menu properly includes update status options
- Button labels and table columns updated appropriately
- ImageUpdateItem component receives the necessary props
Also applies to: 221-238, 252-253, 273-273, 303-303
backend/internal/dto/image_update_dto.go (1)
1-51: Well-structured DTOs for image update operations.The DTOs are comprehensive and properly designed:
- Appropriate use of validation tags on request structs
- Response structures include error handling and timing information
- Clear separation between different types of operations
backend/internal/models/image_update.go (6)
1-5: Package and imports look good.Clean and minimal imports appropriate for the model definitions.
7-24: Well-designed model structure.The
ImageUpdateRecordstruct is comprehensive and follows Go conventions:
- Appropriate use of GORM tags with proper constraints
- Correct foreign key relationship with the Image model
- Pointer types for optional fields (LatestVersion, LatestDigest, LastError)
- Proper indexing on Repository and Tag fields for query performance
26-28: Table name method implemented correctly.Proper GORM Tabler interface implementation with a clear, descriptive table name.
30-36: Appropriate DTO structure for JSON serialization.The
ImageUpdatestruct is well-designed for API responses with string-based timestamp representation and essential fields.
38-41: Clear and well-defined constants.The update type constants are appropriately named and provide clear semantic meaning for different update scenarios.
43-53: Clean and intuitive convenience methods.The boolean methods provide a clear API for checking update states and properly use the defined constants for type comparisons.
frontend/src/lib/services/api/image-update-api-service.ts (2)
3-46: Well-structured TypeScript interfaces.The interfaces are comprehensive and properly aligned with the backend DTOs:
- Correct optional field declarations using
?syntax- Consistent naming conventions following TypeScript/JavaScript standards
- Complete coverage of all necessary data structures for the API
48-83: Excellent API service implementation.The service follows established patterns and best practices:
- Proper URL encoding for query parameters using
encodeURIComponent- Appropriate HTTP methods for different operations
- Consistent error handling through inherited
handleResponsemethod- Reasonable default values for pagination limits
frontend/src/lib/components/image-update-item.svelte (2)
1-109: Excellent Svelte 5 implementation with proper patterns.The script section demonstrates excellent use of Svelte 5 features:
- Correct use of runes syntax (
$props(),$state(),$derived()) as noted in the learnings- Proper TypeScript typing throughout
- Well-structured derived values with null safety
- Comprehensive error handling in async functions
- Clean separation of concerns between display logic and API interactions
111-403: Rich and well-structured UI implementation.The template provides an excellent user experience:
- Clear visual differentiation between update states using colors and icons
- Comprehensive tooltip information for each scenario
- Proper loading state handling with disabled interactions
- Consistent styling with dark mode support
- Good accessibility with meaningful icons and descriptions
frontend/src/routes/images/+page.svelte (4)
15-15: Consistent API import and state management updates.The changes properly replace maturity functionality with update tracking:
- Import of
imageUpdateAPIaligns with the new service architecture- Addition of
checkingstate follows the established loading state patternAlso applies to: 33-34
88-101: Well-implemented bulk update check function.The function properly replaces maturity functionality with good practices:
- Comprehensive error handling with both logging and user notifications
- Proper loading state management with finally block
- Smart image reference mapping with fallback logic
- Appropriate data refresh on successful completion
107-110: Appropriate simplification of data handling.The function correctly adapts to the new update system by returning raw image data directly, eliminating the need for maturity enhancement logic.
191-191: Consistent component integration updates.The changes properly align the component usage with the new update tracking system:
- Direct
imagesprop passing simplifies data flow- Event handler naming accurately reflects the update check functionality
Also applies to: 197-197
backend/internal/api/image_update_handler.go (8)
12-20: Clean handler structure with proper dependency injection.The handler follows established patterns with a focused single responsibility and clean constructor implementation.
22-57: Robust endpoint implementation with proper validation.The method demonstrates excellent API design practices:
- Clear input validation with descriptive error messages
- Proper context propagation to service layer
- Comprehensive response mapping covering all required fields
- Consistent error handling with appropriate HTTP status codes
59-94: Consistent endpoint implementation following established patterns.The method maintains consistency with other endpoints while properly handling path parameter validation and response mapping.
96-142: Well-implemented batch processing endpoint.The method properly handles batch requests with:
- Appropriate JSON binding and validation
- Additional business logic validation (non-empty array)
- Efficient response mapping preserving the map structure
- Consistent error handling patterns
144-183: Proper parameter handling with sensible defaults.The method correctly handles optional parameters with validation and provides a reasonable default limit value while maintaining response consistency.
185-207: Straightforward summary endpoint with complete field mapping.The method provides a clean interface for retrieving update summaries with comprehensive field coverage and consistent error handling.
209-249: Complete versions endpoint with proper parameter handling.The method effectively handles both required and optional parameters with appropriate defaults and comprehensive response mapping for version data.
251-282: Effective version comparison endpoint with proper request handling.The method correctly handles structured request data and provides comprehensive comparison results through proper DTO mapping and consistent error handling.
backend/internal/services/auto_update_service.go (1)
491-499: LGTM!The digest extraction logic correctly handles the sha256 format and provides a reasonable fallback.
backend/internal/services/image_service.go (4)
27-41: LGTM!The service dependencies are properly updated to use
ImageUpdateServiceinstead of the removedImageMaturityService.
434-453: LGTM!The upsert logic with
OnConflictproperly handles concurrent updates and ensures all relevant fields are updated atomically.
518-565: LGTM!The paginated listing properly includes update information and ensures data freshness by syncing images first.
567-580: LGTM!The cleanup method properly handles orphaned records with appropriate logic for both empty and populated ID lists.
backend/internal/utils/registry_utils.go (2)
12-35: LGTM!The type definitions and constants are well-structured. The stateless design of
RegistryUtilsis appropriate for utility functions.
182-223: LGTM!The digest retrieval implementation is robust with proper header handling and fallback mechanisms.
backend/internal/services/image_update_service.go (4)
80-126: LGTM!The update checking logic is well-structured with proper error handling. Errors are appropriately saved as results rather than propagated, ensuring partial results are preserved.
609-686: LGTM!The database operations properly handle nullable fields and ensure image existence before creating update records.
767-837: LGTM!The version management methods provide comprehensive functionality for listing available versions and comparing them with detailed change level information.
239-239: Regex patterns correctly defined in utils packageConfirmed that the following regex variables are defined in backend/internal/utils/version.go:
- SemanticVersionRegex
- DateVersionRegex
- NumericVersionRegex
No further action required.
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Documentation
Chores