import-dir uploads secondary artifacts before their primary API definition
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
Research direction
Start in cmd/importDir.go around the ImportDirectory discovery and upload logic, then add or run cmd/import_order_regression_test.go. Confirm that openapi.yaml is uploaded before examples.yaml while preserving the relative order within each primary-status group, and ensure the cmd tests pass.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Go
- Stars
- 57
- Forks
- 72
- Avg merge
- 1d 35m
- Merged PRs (30d)
- 24
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microcks/microcks-cli
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microcks/microcks-cli#559 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
microcks/microcks-cli#554 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
microcks/microcks-cli#551 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microcks/microcks-cli#545 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
microcks/microcks-cli#536 · 1 comment ·
Maintainers usually reply within 1 day
All issues in microcks/microcks-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
google/differential-privacy#516 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
lightninglabs/lndmon#140 ·
-
documentation good first issue ready-for-triage ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
release-engineering/fbc-update-planner#102 · 3 comments ·
Maintainers usually reply within 5 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yetone/magpie#562 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 4 days