Mirror Plugin: Fix link resolution

[ikaneshiro]

• Adds additional link reference field
• Adds file deletion by mode

Summary by CodeRabbit

• New Features

  • Introduced the ability to delete repository files based on a specified mode, enhancing file management capabilities.
  • Added support for linking references to repository files for improved file tracking and integrity.

• Bug Fixes

  • Improved symbolic link handling in storage operations to ensure more reliable file synchronization.

• Documentation

  • Updated API documentation to include new endpoints and methods for deleting files by mode and handling link references.

[coderabbitai]

Walkthrough

This update introduces the ability to delete repository files based on a specified mode, enriching the plugin's functionality. A significant addition is the LinkReference field across various components, enhancing the handling of symbolic links. The changes span across API definitions, database interactions, and internal logic adjustments, aimed at improving the plugin's robustness and flexibility in managing repository files.

Changes

File Path	Change Summary
internal/plugins/mirror/api.go	Added DeleteRepositoryFilesByMode method.
.../mirror/pkg/mirrordb/repository.go	Added LinkReference field and DeleteFilesByMode method. Updated AddFile method.
.../mirror/pkg/mirrordb/schema/repository/...	Added SQL script to add link_reference column.
.../mirror/pkg/mirrorrepository/	Updated multiple files to include LinkReference field and handle deletion by mode.
internal/plugins/mirror/web.go	Improved symlink resolution logic.
pkg/plugins/mirror/api/v1/...	Renamed Link to LinkReference, added deletion by mode functionality across API and HTTP layers.

🐇✨
In the realm of code, where the mirrors align,
A rabbit hops through, making links intertwine.
With a flick and a hop, files vanish by mode,
In the database fields, new references are stowed.
Through APIs and routes, the changes take flight,
A digital burrow, gleaming bright in the night.
🌟🐾

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

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 as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[coderabbitai]

Actionable comments posted: 1

Review Status

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 7aa3f24 and 6694bc2.

Files selected for processing (13)

• internal/plugins/mirror/api.go (1 hunks)
• internal/plugins/mirror/pkg/mirrordb/repository.go (3 hunks)
• internal/plugins/mirror/pkg/mirrordb/schema/repository/000001_add_link_reference_column.sql (1 hunks)
• internal/plugins/mirror/pkg/mirrorrepository/api.go (2 hunks)
• internal/plugins/mirror/pkg/mirrorrepository/mirrorsync.go (3 hunks)
• internal/plugins/mirror/pkg/mirrorrepository/plansync.go (4 hunks)
• internal/plugins/mirror/pkg/mirrorrepository/rsyncstorage.go (2 hunks)
• internal/plugins/mirror/web.go (3 hunks)
• pkg/plugins/mirror/api/v1/api.go (2 hunks)
• pkg/plugins/mirror/api/v1/endpoint.go (1 hunks)
• pkg/plugins/mirror/api/v1/http.go (2 hunks)
• pkg/plugins/mirror/api/v1/http_client.go (1 hunks)
• pkg/plugins/mirror/api/v1/oas2.go (3 hunks)

Additional Context Used

Additional comments not posted (22)

internal/plugins/mirror/pkg/mirrordb/schema/repository/000001_add_link_reference_column.sql (1)

1-1: The SQL script correctly adds the link_reference column to the files table with a default empty string value. This change supports the enhancement of link resolution in the Mirror Plugin by allowing for more detailed link management.

internal/plugins/mirror/web.go (2)

19-30: The hasPathPrefix function correctly checks if a given path starts with a specified prefix by comparing each segment. This method is a reliable way to ensure path prefix matching, which is crucial for symlink resolution.

---

47-54: The modifications to resolveSymlinks correctly utilize the hasPathPrefix function for more accurate symlink resolution. This change improves the logic for handling symbolic links within the plugin.

internal/plugins/mirror/pkg/mirrorrepository/rsyncstorage.go (1)

114-125: The updates to the Put method correctly introduce and utilize the linkReference variable for enhanced symbolic link handling. Adding LinkReference to the RepositoryFile struct allows for more detailed link management, aligning with the PR's objectives to improve link resolution.

Also applies to: 136-145

internal/plugins/mirror/api.go (1)

118-124: The addition of the DeleteRepositoryFilesByMode method to the Plugin struct correctly implements the functionality to delete repository files based on a specified mode. This enhancement aligns with the PR's objectives to provide advanced file deletion capabilities.

pkg/plugins/mirror/api/v1/api.go (2)

65-74: The changes to the RepositoryFile struct, including the renaming of the Link field to LinkReference, support the PR's objectives to enhance link resolution within the plugin.

---

163-167: The addition of the DeleteRepositoryFilesByMode method to the Mirror interface correctly implements the functionality to delete files by mode, aligning with the PR's objectives to introduce advanced file deletion capabilities.

internal/plugins/mirror/pkg/mirrorrepository/plansync.go (1)

122-131: The updates to the PlanSyncer struct's filePush and Sync methods correctly introduce and utilize the LinkReference field in the RepositoryFile struct. These changes support the PR's objectives to enhance link resolution by providing a more detailed link management mechanism.

Also applies to: 188-197, 223-232

internal/plugins/mirror/pkg/mirrordb/repository.go (3)

21-30: The addition of the LinkReference field to the RepositoryFile struct supports the PR's objectives to enhance link resolution within the plugin by allowing for more detailed link management.

---

70-71: The update to the AddFile method to include link_reference in the SQL query correctly aligns with the addition of the LinkReference field to the RepositoryFile struct, ensuring that link references are properly managed in the database.

---

216-238: The addition of the DeleteFilesByMode method correctly implements the functionality to delete files based on a specified mode. This enhancement aligns with the PR's objectives to introduce advanced file deletion capabilities, providing users with more control over file management.

internal/plugins/mirror/pkg/mirrorrepository/mirrorsync.go (1)

196-205: The updates to the MirrorSyncer type's filePush and Sync functions correctly introduce and utilize the LinkReference field in the mirrordb.RepositoryFile struct. These changes support the PR's objectives to enhance link resolution by providing a more detailed link management mechanism.

Also applies to: 264-273, 296-305

pkg/plugins/mirror/api/v1/oas2.go (3)

100-111: The addition of a new endpoint /repository/file:mode for deleting files by mode is a significant enhancement. Ensure that the corresponding backend logic properly handles the mode parameter to perform the expected file deletion operations.

---

219-219: The update to include response handling for DeleteRepositoryFilesByMode in the getResponses function is crucial for ensuring that the API can correctly communicate the outcome of the delete operation. It's important to verify that the response structure aligns with the expected results and error handling scenarios.

---

252-256: The modifications to the getDefinitions function to add definitions for the request and response of the DeleteRepositoryFilesByMode operation are essential for API documentation and client generation. Ensure that these definitions accurately reflect the request parameters and the possible response structures, including any error messages.

pkg/plugins/mirror/api/v1/http.go (2)

69-81: The addition of a new HTTP route for deleting repository files by mode is a key enhancement. It's important to ensure that the route /repository/file:mode is correctly configured and that the backend service logic accurately processes the mode parameter for file deletion.

---

288-302: Implementing decoding logic for deleting repository files by mode requests is crucial for correctly parsing incoming requests. Ensure that the decoding function properly extracts and validates the mode parameter from the request body, handling any potential errors or invalid inputs gracefully.

internal/plugins/mirror/pkg/mirrorrepository/api.go (3)

549-566: The addition of the DeleteRepositoryFilesByMode method is a significant feature that allows for the deletion of repository files based on a specified mode. It's important to ensure that the method correctly interprets the mode parameter and performs the deletion operation as expected, including proper error handling for any issues encountered during the process.

---

593-602: Updating the toRepositoryFileAPI function to include the LinkReference field is crucial for ensuring that the API correctly handles and exposes link references for repository files. Verify that the LinkReference field is correctly populated from the database and accurately represented in the API response.

---

608-617: The modification to the toRepositoryFileDB function to include the LinkReference field ensures that API requests containing link references are correctly mapped to the database model. It's important to verify that the LinkReference field is properly extracted from the request and stored in the database, facilitating accurate link resolution.

pkg/plugins/mirror/api/v1/http_client.go (1)

184-231: The implementation of DeleteRepositoryFilesByMode method follows the established pattern seen in other methods of the HTTPClient struct. However, there are a few areas where improvements can be made:

1. Error Handling Consistency: The error handling after the HTTP request is made checks if the status code is not within the successful range but does not explicitly handle different classes of errors (e.g., client errors vs. server errors). It might be beneficial to log or handle these categories differently for better debugging and error tracking.

2. Resource Cleanup: The use of defer _resp.Body.Close() is good practice for resource cleanup. However, it's important to ensure that this pattern is consistently applied across all HTTP client methods to prevent resource leaks.

3. HTTP Method Verbosity: The method uses "DELETE" as the HTTP method, which is correct for this operation. Ensure that the API design adheres to REST principles, using the appropriate HTTP methods for the action being performed.

4. Path Construction: The path "/repository/file:mode" is used to construct the URL. Ensure that this path correctly maps to the intended API endpoint and follows RESTful URL design principles.

5. Request Body Structure: The request body includes Repository and Mode fields, which aligns with the operation's requirements. Ensure that the Mode field is adequately documented to clarify the modes supported and their effects.

Overall, the method is well-implemented but could benefit from more detailed error handling and consistent resource management practices.

pkg/plugins/mirror/api/v1/endpoint.go (1)

125-160: The addition of DeleteRepositoryFilesByModeRequest, DeleteRepositoryFilesByModeResponse, and related functions is consistent with the design patterns used in the rest of the file. A few considerations for refinement:

1. Validation Logic: The ValidateDeleteRepositoryFilesByModeRequest function provides a framework for request validation but does not implement specific validation rules. It's important to ensure that the Repository and Mode fields are validated for correctness (e.g., non-empty repository name, valid mode values). Consider implementing specific validation rules to prevent invalid requests from being processed.

2. Error Handling in Response: The DeleteRepositoryFilesByModeResponse struct implements the Failed method to return errors. Ensure that errors are adequately logged or handled upstream to provide clear feedback to the client in case of failure.

3. Endpoint Function Documentation: The MakeEndpointOfDeleteRepositoryFilesByMode function creates an endpoint for the new feature. While the implementation follows the established pattern, adding documentation comments explaining the function's purpose, parameters, and return values would improve code readability and maintainability.

4. Request and Response Structs: The request and response structs are minimal and focused, which is good. However, consider if there are any additional fields or metadata that might be useful to include in the response to provide more context about the operation's outcome.

Overall, the new components are well-integrated into the existing codebase. Enhancing validation logic and documentation can further improve the code quality.