relman CLI: Organizations & Projects

← Zurück zur Übersicht über die relman-CLI-Befehle

Organisationen, Projektgruppen und Projekte

Dies sind die obersten Ebenen der Token-Hierarchie, in deren Rahmen fast jeder andere Befehl ausgeführt wird: Organisation → Projektgruppe → Projekt. Jedes Token unterhalb der Organisationsebene ist nur innerhalb seines unmittelbaren übergeordneten Elements garantiert eindeutig; geben Sie daher die gesamte Kette an, die ein Befehl erfordert.

list organizations

Ruft die ID und den Namen jeder Organisation vom Server ab und gibt sie aus. Dies ist der Ausgangspunkt für alles Weitere – jede weitere Befehlskette beginnt mit einer dieser IDs.

Projektgruppen auflisten <org-token> (Aliase: pg, pgs)

Ruft die ID und den Namen jeder Projektgruppe ab, die der durch <org-token> identifizierten Organisation gehört (wie von „list organizations“ zurückgegeben).

Projekte auflisten <org-token> <pg-token> (Aliase: project, p)

Ruft die ID und den Namen jedes Projekts ab, das der durch <pg-token> identifizierten Projektgruppe gehört (die wiederum dem Bereich <org-token> zugeordnet ist).

describe org <org-token> (Aliase: organization, orgs, organizations)

Ruft die detaillierte Konfiguration der durch <org-token> identifizierten Organisation ab und gibt sie aus.

describe pg <org-token> <pg-token> (Aliase: projectgroup, pgs, projectgroups)

Ruft die detaillierte Konfiguration der durch <pg-token> identifizierten Projektgruppe ab und gibt sie aus (die selbst in den Geltungsbereich von <org-token> fällt).

describe project <org-token> <pg-token> <project-token> (Aliase: p, projects)

Ruft die detaillierte Konfiguration des durch <project-token> identifizierten Projekts ab und gibt sie aus (das Projekt ist selbst dem Bereich <org-token>/<pg-token> zugeordnet) – einschließlich seiner „definitionsOfDone“ und „ticketPhases“, die Bug-Erwartungen nach Namen hinzufügen.

Beispiele

1. Auflistung aller Organisationen

Der Ausgangspunkt für alle weiteren Befehlsketten. Es sind keine Argumente erforderlich – globale Flags (--domain/--cert) werden hier als über die UmgebungsvariablenRELMAN_DOMAIN/RELMAN_CERT gesetzt vorausgesetzt und in allen Beispielen auf dieser Seite weggelassen, siehe Dienstprogramme & globale Flags.

$ relman list organizations
- id: o-4kNc8Q
  name: Example Corp
- id: o-Rz91Wm
  name: Sandbox GmbH

Sonderfall: Wenn Ihr Zertifikat auf ein Konto verweist, das überhaupt keiner Organisation angehört, wird eine leere Liste ([]) ausgegeben und dennoch der Status 0 zurückgegeben – ein leeres Ergebnis ist kein Fehler.

2. Auflisten der Projektgruppen einer Organisation

Geben Sie die ID aus Schritt 1 an.

$ relman list projectgroups o-4kNc8Q
- id: pg-8mZ2Lx
  name: Marketing-Website
- id: pg-Tn5vQ2
  name: Interne Tools

Sonderfall: Die Eindeutigkeit eines Projektgruppen-Tokens ist nur innerhalb der eigenen Organisation garantiert. Die Übergabe eines syntaktisch gültigen Tokens, das zu einer anderen Organisation als der angegebenen gehört, führt zu keinem Ergebnis – der Server antwortet mit HTTP 400, und relman gibt „Fehler: Der Server hat mit HTTP 400 für … geantwortet“ aus.

3. Beschreibung eines Projekts

Die vollständige Kette ist erforderlich, da ein Projekt-Token allein nur innerhalb seiner Projektgruppe eindeutig ist.

$ relman describe project o-4kNc8Q pg-8mZ2Lx p-Qv73Tn
name: Website-Relaunch
definitionsOfDone:
  - Überprüft
  - Auf der Staging-Umgebung getestet
ticketPhases:
  - Backlog
  - In Bearbeitung
  - Qualitätssicherung
  - Fertig

Sonderfall: Die genauen Zeichenfolgen unter `definitionsOfDone `/`ticketPhases ` sind das, was `add bug ` für seine Argumente `<definition-of-done-name>/[<phase-name>] erwartet, wobei die Übereinstimmung nach dem Namen und nicht nach der ID erfolgt – ein Tippfehler oder falsche Groß-/Kleinschreibung führt hier zu einem Fehler ohne genauere Hinweise als eine allgemeine Fehlermeldung; daher lohnt es sich, diesen Befehl direkt vor dem Ausführen von „add bug“ auszuführen, anstatt sich auf einen zuvor gespeicherten Wert zu verlassen.