import-dir uploads secondary artifacts before their primary API definition
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 88/100
Hướng nghiên cứu
Bắt đầu trong cmd/importDir.go, tại phần logic phát hiện và tải lên của ImportDirectory, sau đó thêm hoặc chạy cmd/import_order_regression_test.go. Xác nhận rằng openapi.yaml được tải lên trước examples.yaml trong khi vẫn giữ nguyên thứ tự tương đối trong mỗi nhóm có cùng trạng thái chính, và đảm bảo các bài kiểm tra cmd đều thành công.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
import-dir can upload a secondary artifact before its primary API definition. For example, a directory containing examples.yaml and openapi.yaml uploads examples.yaml with primary=false first, then openapi.yaml with primary=true.
ImportDirectory uploads files in their discovery order. RealFileSystem uses filepath.Walk, so lexical filename order determines which artifact is uploaded first; the files are not grouped by primary/secondary status.
The multi-artifact documentation explains that a secondary artifact is ignored when its matching API name/version does not yet exist. On a first import, this ordering can therefore leave the API without the examples from its secondary artifact.
Expected behavior
Upload primary artifacts before secondary artifacts, regardless of filename order, so the API definition exists before its secondary artifacts are imported.
Reproduction test
Tested on upstream master at e54dc4719d1f14085f5bb551a910139628babbbc, with go version go1.26.5 darwin/arm64 (macOS, ARM64).
Save this as cmd/import_order_regression_test.go and run:
go test ./cmd -run '^TestReviewImportDirPrimaryOrder$' -count=1 -v
The test calls the production ImportDirectory with RealFileSystem and records calls to the upload client. Fixture contents are placeholders because the recording client does not parse them.
package cmd
import (
"fmt"
"os"
"path/filepath"
"testing"
)
type reviewUploadClient struct{ calls []string }
func (c *reviewUploadClient) UploadArtifact(path string, primary bool) (string, error) {
c.calls = append(c.calls, fmt.Sprintf("%s primary=%t", filepath.Base(path), primary))
return "accepted", nil
}
func TestReviewImportDirPrimaryOrder(t *testing.T) {
dir := t.TempDir()
for _, name := range []string{"examples.yaml", "openapi.yaml"} {
if err := os.WriteFile(filepath.Join(dir, name), []byte("fixture"), 0600); err != nil {
t.Fatal(err)
}
}
client := &reviewUploadClient{}
result, err := ImportDirectory(client, &RealFileSystem{}, dir, ImportConfig{})
if err != nil {
t.Fatal(err)
}
t.Logf("upload order: %v; success=%d failed=%d", client.calls, result.SuccessCount, result.FailedCount)
if client.calls[0] != "openapi.yaml primary=true" {
t.Errorf("secondary artifact uploaded before the primary API definition")
}
}
Actual test output
For the recorded run, the test file was supplied through a temporary Go overlay to leave the checkout unchanged:
go test -overlay=/tmp/microcks-import-order-overlay.json ./cmd -run '^TestReviewImportDirPrimaryOrder$' -count=1 -v
=== RUN TestReviewImportDirPrimaryOrder
Microcks has completed 'accepted'
Microcks has discovered 'accepted'
import_order_regression_test.go:29: upload order: [examples.yaml primary=false openapi.yaml primary=true]; success=2 failed=0
import_order_regression_test.go:31: secondary artifact uploaded before the primary API definition
--- FAIL: TestReviewImportDirPrimaryOrder (0.00s)
FAIL
FAIL github.com/microcks/microcks-cli/cmd 0.917s
FAIL
Exit status: 1. The secondary artifact was uploaded first.
This test confirms the CLI upload order only. The accepted responses and success counters come from the recording client, not a live Microcks server. The missing-examples impact follows from the documented secondary-artifact behavior; I have not run a live-server reproduction.
A possible fix is to stably group the discovered files by IsPrimary before uploading them, keeping the existing relative order within each group.
I searched existing issues and PRs for import-dir ordering/primary/secondary reports and found no matching report. PR #459 concerns import-url success-message wording, not directory upload ordering.
- Ngôn ngữ chính
- Go
- Star
- 57
- Fork
- 73
- Merge trung bình
- 1 ngày 8 giờ
- Pull request đã merge (30 ngày)
- 28
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microcks/microcks-cli
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
microcks/microcks-cli#573 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug: YAML parse error in config is silently swallowed, login overwrites all other contextsCó thể đã có người làm @Sarthak-Shreshtha01 đã nhận 1 ngày trước. Đang mởcomponent/cli kind/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
microcks/microcks-cli#572 · 5 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
microcks/microcks-cli#559 · 2 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
TEST: `ConnectAndGetToken` Returns Error on Non-200 ResponseCó thể đã có người làm @aniket866 đã nhận 11 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
microcks/microcks-cli#554 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Empty `AuthToken` Causes Cryptic JWT Parse ErrorCó thể đã có người làm @aniket866 đã nhận 11 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
microcks/microcks-cli#551 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của microcks/microcks-cli
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
duplication
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
openvibely/openvibely#1443 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100
canonical/service-mesh#845 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
keyxmakerx/Chronicle#1179 ·
Maintainer thường phản hồi trong vòng 1 ngày