Puncte:0

Setări Teamcity Versioned: cum să utilizați Token-urile

drapel il

Când stocați configurația în VCS ca Kotlin DSL, nu ar trebui să codificați parolele și jetoanele, în schimb ar trebui să fie folosite „Jetoanele”. Problema este că nu este documentat corespunzător.

Să ne imaginăm că am un simbol credentialsJSON:78098495-5f8c-4935-82b5-03eafaf2adde care conține expresia de acces cheie VCS. Cum îl folosesc în codul Kotlin DSL?

Am incercat urmatoarele:

parametri {
    parolă ("GitHub-key-passphrase", "credentialsJSON:78098495-5f8c-4935-82b5-03eafaf2adde")
}

Dar, TeamCity se va plânge că parametrul „GitHub-key-passphrase” nu este specificat. Cum să înlocuiți jetoanele?

Puncte:0
drapel aq

Înțeleg că este o afacere în mai multe părți.

  1. Adăugați un token în GUI TeamCity (Setări versiuni > Jetoane)
  2. Faceți referire la acel Token în Kotlinul dvs. (ceea ce ați făcut mai sus)
  3. În configurația dvs. de compilare, utilizați parametrul pe care l-ați definit în Kotlin.

Deci, dacă faci ceva de genul:

parametri{
    adăuga {
        param("system.myGithubPassword)", "credentialsJSON:78098495-5f8c-4935-82b5-03eafaf2adde")
    }
}

Apoi ar trebui să vedeți (în GUI) că proiectul dvs. are acum un parametru de sistem numit myGithubPassword cu o valoare (ascunsă). De asemenea, ar trebui să vedeți (în GUI) proiectele/parametrii pentru care acel Token este utilizat - afișați în pagina „Tokens”. Apoi te poți referi la %system.mygithubpassword% în orice locație de construcție care poate gestiona înlocuirea parametrilor TeamCity și TeamCity ar trebui să se ocupe de înlocuirea parametrilor -> simbol -> înlocuirea parolei.

Din descrierea dvs., este posibil să setați corect simbolul și parametrul, dar apoi să nu utilizați parametrul așa cum doriți/aștepți în configurația Build.

Așa eu gândi că ar trebui să funcționeze, dar, ca și tine, mi s-a părut puțin dificil de urmărit documentele despre asta...

https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Managing+Tokens

drapel il
Problema este că nu am nicio locație care să se ocupe de înlocuirea parametrilor, toate locațiile mele sunt cod Kotlin. Șeful căruia: când declar param ca acesta (nu ar trebui să folosesc parola?), atunci TeamCity se plânge că nu este definit, deși este declarat cu valoare token.
GnomeDePlume avatar
drapel aq
Așadar, setările tale (configurate/exprimate în Kotlin) pot seta valoarea parametrului și apoi configurația ta de compilare o poate folosi. Folosim Kotlin pentru a spune că un parametru va avea o valoare de și apoi, în timpul construirii, TC se ocupă de înlocuire pentru noi.
GnomeDePlume avatar
drapel aq
Ceea ce ar putea fi util (ceea ce am făcut astăzi) este utilizarea GUI pentru a configura configurația dorită și apoi inspectați DSL-ul Kotlin care este generat. Am descoperit că atunci când am creat o intrare de parolă, TC crea automat un nou Token pentru a o gestiona - iar DSL-ul rezultat conținea numele jetonului. Și eu sunt nou în acest sens - utilizarea interfeței grafice pentru a genera câteva exemple de configurație Kotlin se dovedește o cârjă utilă chiar acum.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.