import-dir uploads secondary artifacts before their primary API definition
维护者通常 1 天内回复
评估
调研方向
从 cmd/importDir.go 中 ImportDirectory 的发现和上传逻辑附近开始，然后添加或运行 cmd/import_order_regression_test.go。确认 openapi.yaml 在 examples.yaml 之前上传，同时保留每个主状态组内的相对顺序，并确保 cmd 测试通过。
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- Go
- 星标
- 57
- 派生
- 73
- 平均合并
- 1 天 8 小时
- 30 天内合并 PR
- 28
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microcks/microcks-cli 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 88/100
microcks/microcks-cli#573 ·
维护者通常 1 天内回复
-
bug: YAML parse error in config is silently swallowed, login overwrites all other contexts可能已有人在做 @Sarthak-Shreshtha01 于 1 天前认领。 未关闭component/cli kind/bug
难度 2/5 1-3 小时 新手友好度 76/100
microcks/microcks-cli#572 · 5 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
microcks/microcks-cli#559 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
TEST: `ConnectAndGetToken` Returns Error on Non-200 Response可能已有人在做 @aniket866 于 11 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
microcks/microcks-cli#554 ·
维护者通常 1 天内回复
-
Empty `AuthToken` Causes Cryptic JWT Parse Error可能已有人在做 @aniket866 于 11 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 86/100
microcks/microcks-cli#551 ·
维护者通常 1 天内回复
查看 microcks/microcks-cli 的全部 Issue
相似的 Issue
-
raised-by:worker
难度 2/5 1-3 小时 新手友好度 68/100
medici-finance/assay#2486 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
openimsdk/openim-sdk-core#1127 ·
-
github_actions
难度 2/5 1-3 小时 新手友好度 65/100
Hochfrequenz/aibap.mcp#578 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
mvanhorn/cli-printing-press#4980 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
lenaxia/LLMSafeSpaces#1644 · 3 条评论 · 1 个 reaction ·
维护者通常 1 天内回复