Cum să folosiți Artifactory ca depozit local pentru modulele Go (Programare, Du-Te, Artifactory)

Larry a intrebat.
  • Am Artifactory configurat și funcționează, servind alte artefacte (RPM, etc.)
  • Aș dori să am copii locale ale programelor și bibliotecilor Go publice și private
    • pentru a asigura coerența versiunilor
    • pentru a permite depozitelor publice să elimine erorile.
    • pentru ca depozitele publice să fie protejate împotriva modificărilor neautorizate
  • Am creat un depozit Go în Artifactory și l-am populat cu, ca exemplu, spf13/viper folosind frog-cli (care a creat un fișier zip și un fișier mod)

Întrebări:

  1. Este fișierul zip modalitatea corectă de a stoca module Go în Artifactory?
  2. Cum se utilizează fișierul zip într-un program Go? De exemplu, URL-ul pentru a obține fișierul zip este http://hostname/artifactory/reponame/github.com/spf13/viper/@v/v1.6.1.zip (și .mod pentru fișierul mod) De exemplu, trebuie să setez GOPATH la o anumită valoare?
  3. Există o modalitate de a vă asigura că toate cerințele sunt incluse automat în depozitul local Artifactory? În momentul includerii pachetului principal (de exemplu, viper) în depozitul local Artifactory?

Comentarii

1 răspunsuri
Ankush Chadha

Răspunzând mai întâi la a treia întrebare –

Iată un alt articol care vă va ajuta – https://jfrog.com/blog/why-goproxy-matters-and-which-to-pick/. Există două modalități de a publica module go private în Artifactory. Primul este un mod tradițional, adică prin JFrog CLI, care este evidențiat într-un alt articol, și anume articol.

O altă modalitate este de a îndrepta un depozit la distanță către un depozit GitHub privat. Această capacitate a fost adăugată recent. În acest caz, un depozit virtual va avea două relocări la distanță. Primul depozit la distanță este implicit la GoCenter prin intermediul căruia sunt preluate modulele go publice. Al doilea depozit la distanță indică sistemele VCS private.

Setarea GOPROXY la NUMAI depozitul virtual de module go se va asigura că Artifactory continuă să fie o sursă de adevăr atât pentru modulele go publice, cât și pentru cele private. Dacă doriți să stocați binare go compilate, puteți utiliza un depozit generic local, dar vă sfătuim să folosiți un aspect personalizat pentru a structura conținutul unui depozit generic.

Răspunzând la primele 2 întrebări –

Modulul go este un manager de pachete în Golang, similar cu ceea ce este maven pentru Java. În Artifactory, pentru fiecare modul go, există 3 fișiere pentru fiecare versiune de modul go: go.mod, .info și fișierul de arhivă.

Artifactory urmează protocolul GOPROXY, prin urmare, dependențele menționate în go.mod vor fi preluate automat din depozitul virtual. Acesta va include și fișierul de arhivă, care este o colecție de pachete (fișiere sursă).

Există metadate suplimentare care sunt stocate pentru modulele go publice, cum ar fi solicitările de tip tile și de căutare, deoarece solicitările GoSumDB sunt stocate în memoria cache pentru a se asigura că Artifactory rămâne sursa adevărului pentru module și metadate chiar și într-un mediu de tip air-gapped.

Comentarii

  • Uau, perfect. Nu sunt sigur că am înțeles totul, totuși. Răspunsul la a 3-a întrebare pare simplu. DACĂ (și înțeleg că încă nu este așa, pentru că nu am configurat-o) „reponame” ar fi un virtual cu două telecomenzi, cum ați face referire la „hostname/artifactory/reponame/github.com/spf13/viper/@v/…” într-un modul go, și cu ce GOPATH? De exemplu, GOPATH=hostname/artifactory/api/go și în go „import „spf13/viper””? –  > Por Larry.