import-dir uploads secondary artifacts before their primary API definition
Les mainteneurs répondent en général sous 1 jour
Évaluation
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 88/100
Piste de recherche
Commencez dans cmd/importDir.go, autour de la logique de découverte et de téléversement de ImportDirectory, puis ajoutez ou exécutez cmd/import_order_regression_test.go. Vérifiez que openapi.yaml est téléversé avant examples.yaml tout en préservant l’ordre relatif au sein de chaque groupe de statut primaire, et assurez-vous que les tests de cmd passent.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
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.
- Langage dominant
- Go
- Étoiles
- 58
- Forks
- 72
- Merge moyen
- 1 j 7 h
- PR mergées (30 j)
- 22
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de microcks/microcks-cli
-
Wrong link to test resultsPeut-être à nouveau libre @SajanBisht l’a pris il y a 10 jours, et aucune pull request n’est ouverte. Ouvertecomponent/cli keep-open kind/bug
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
microcks/microcks-cli#589 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Default configuration path falls back to the current directory when the home directory cannot be determinedPeut-être pris @Sarthak-Shreshtha01 l’a pris il y a 14 jours. Ouvertecomponent/cli kind/bug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
microcks/microcks-cli#583 · 5 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
microcks test exits with code 1 (contract failure) instead of code 11 (connection) when polling loop times outPeut-être pris @ish-g09 l’a pris il y a 12 jours. Ouvertecomponent/cli kind/bug
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
microcks/microcks-cli#573 · 6 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
bug: YAML parse error in config is silently swallowed, login overwrites all other contextsPeut-être pris @Sarthak-Shreshtha01 l’a pris il y a 19 jours. Ouvertecomponent/cli kind/bug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
microcks/microcks-cli#572 · 6 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
TEST: `ConnectAndGetToken` Returns Error on Non-200 ResponsePeut-être pris @aniket866 l’a pris il y a 29 jours. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
microcks/microcks-cli#554 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de microcks/microcks-cli
Issues similaires
-
[doc-healer] DDUw improvement: retry integrity-filtered issue reads with direct single-item lookupsOuverteautomation documentation
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
-
bug needs-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 80/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
containerd/containerd#14476 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 1-3 heures Accessibilité débutants 82/100
Infisical/infisical#8987 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
scan framework and scan control accept empty and whitespace-only policy names in Args validationPeut-être pris @WKr1shna l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour