DE 

//Cloudogu EcoSystem Docs

  1. docs.cloudogu.com
  2. Benutzerhandbuch
  3. Baseline
  4. Konfiguration der Projekte
Getting Started
Benutzerhandbuch
Entwicklerdokumentation

Konfiguration der Projekte

In einer JSON-Datei können verschiedene Einstellungen für Projekte, zu denen Baselines gehören, vorgenommen werden. Der Ablageort dieser Projektkonfigurationsdatei ist konfigurierbar (siehe Konfiguration des Baseline-Dogus)

Der Admin-Benutzer ist berechtigt, die Projektkonfiguration auf der Projektseite im Baseline-Tool zu ändern, indem er auf die Schaltfläche Projekte verwalten klickt.

Die Konfiguration der einzelnen Projekte erfolgt als Array.

1. Beispiel einer vollständigen Projektkonfiguration mit zwei Projekten

Das folgende Beispiel zeigt eine vollständige Projektkonfiguration mit den zwei Projekten petclinic und cas.

Das Projekt petclinic stellt eine Projektkonfiguration mit allen optionalen Attributen dar. In diesem Projekt sind für das Sammeln von Baseline-Elementen zusätzliche SCM-Repositorys, ein Nexus-Artefakt und eine Jenkins-Build-Logdatei konfiguriert.

Das Projekt cas gibt eine simple Projektkonfiguration wieder, in dem eine Baseline jeweils nur aus einem einzigen SCM-Tag besteht.

[
  {
    "id": "petclinic",
    "scm_url": "https://baseline.cloudogu.net/scm",
    "full_qualified_repository_name": "baselineTest/spring-petclinic",
    "additional_repository_names": [
      "baselineTest/summer-petclinic",
      "baselineTest/fall-petclinic",
      "baselineTest/winter-petclinic"
    ],
    "tag_regex": "^.*",
    "nexus": {
      "url": "https://baseline.cloudogu.net/nexus",
      "nexus_artefacts": [
        {
          "repository": "maven-releases",
          "name": "Petclinic JAR",
          "location": "org/springframework/samples/spring-petclinic/${tag}/spring-petclinic-${tag}.jar"
        }
      ]
    },
    "jenkins": {
      "nexus_url": "https://baseline.cloudogu.net/nexus",
      "repository": "maven-releases"
    },
    "app_version": "0.5.0-1"
  },
  {
    "id": "cas",
    "scm_url": "https://baseline.cloudogu.net/scm",
    "full_qualified_repository_name": "baselineTest/cas",
    "tag_regex": "^.*",
    "app_version": "0.5.0-1"
  }
]

2. Konfiguration eines einzelnen Projekts

The individual configuration options of a single project are described in more detail below.

2.1 Konfiguration der Projekt-ID

Jedes Projekt hat eine eindeutige ID. Die ID des Projekts entspricht gleichzeitig dem Namen des Projekts. Alle konfigurierten Projekte werden in der Projekte-Übersicht angezeigt.

  • Attribut-Key: id
  • Datentyp: String
  • Beispiel: "id": "petclinic"

2.2 Konfiguration der SCM-Repositorys

Für jedes Projekt müssen Einstellungen für den Zugriff auf den SCM-Manager konfiguriert werden. Potenzielle Baselines werden im SCM-Manager ermittelt.

2.2.1 Konfiguration der SCM-URL

In der Projektkonfigurationsdatei muss die URL zu dem SCM-Manager, in dem die konfigurierten Repositorys zu finden sind, angegeben werden.

  • Attribut-Key: scm-url
  • Datentyp: String
  • Beispiel: "scm_url": "https://ecosystem.cloudogu.com/scm"
2.2.2 Konfiguration des SCM-Repositorys mit den potenziellen Baselines

In der Projektkonfigurationsdatei muss ein SCM-Repository angegeben werden, in dem die SCM-Tags der potenziellen Baselines zu finden sind. Bei der Ermittlung der potenziellen Baselines wird dieses Repository nach den Tags durchsucht, die dem konfigurierten Tag-Pattern entsprechen.

Beim Sammeln der Elemente einer Baseline wird der entsprechende SCM-Tag mit eingesammelt und in der Baseline-Detailansicht unter SCM-Manager angezeigt.

Das SCM-Repository muss mit seinem Namespace angegeben werden: <namespace>/<repository name>.

  • Attribut-Key: full_qualified_repository_name
  • Datentyp: String
  • Beispiel: full_qualified_repository_name": "demo/spring-petclinic"
2.2.3 Konfiguration von weiteren SCM-Repositorys für das Sammeln von SCM-Tags

Für das Sammeln von Baseline-Elementen ist es optional möglich, weitere SCM-Repositorys anzugeben. Beim Sammeln der Baseline-Elemente werden diese Repositorys dann mit berücksichtigt. Dabei wird in diesem Repositorys nach SCM-Tags mit gleichem Namen wie die Baseline gesucht. Die Tags, die aus den hier konfigurierten Repositorys gesammelt werden, werden in der Baseline-Detailansicht unter SCM-Manager angezeigt.

Die SCM-Repositorys müssen jeweils mit Namespace angegeben werden: <namespace>/<repository name>.

  • Attribut-Key: additional_repository_names
  • Datentyp: Array mit Strings
  • Optional
  • Beispiel:
"additional_repository_names": [
  "demo/spring-petclinic-clone",
  "demo/spring-petclinic-additionals"
]
2.2.4 Konfiguration des Patterns für die SCM-Tags

In der Projektkonfigurationsdatei muss ein Pattern (regulärer Ausdruck) für die zu berücksichtigen SCM-Tags angegeben werden. Bei der Ermittlung der potenziellen Baselines werden nur diejenigen Tags berücksichtigt, die dem konfigurierten Pattern entsprechen.

  • Attribut-Key:
  • Datentyp: String
  • Beispiel: "tag_regex": "^.*"

2.3 Konfiguration zum Sammeln von Artefakten aus Nexus

Für das Sammeln von weiteren Baseline-Elementen ist es optional möglich, ein Nexus mit einem oder mehreren zu sammelnden Artefakten zu konfigurieren. Beim Sammeln der Baseline-Elemente werden diese Artefakte dann mit berücksichtigt. Die hier gesammelten Artefakte werden in der Baseline-Detailansicht unter Nexus angezeigt.

Die Konfiguration erfolgt unter dem Punkt "nexus": { ... }

  • Attribut-Key: nexus
  • Datentyp: Struct
  • Optional
  • Beispiel:
"nexus": {
  "url": "https://baseline.cloudogu.net/nexus",
  "nexus_artefacts": [
    {
      "repository": "maven-releases",
      "name": "Petclinic JAR",
      "location": "org/springframework/samples/spring-petclinic/${tag}/spring-petclinic-${tag}.jar"
    }
  ]
}
2.3.1 Konfiguration der Nexus-URL

Wenn Artefakte aus Nexus gesammelt werden sollen, muss in dem Nexus-Struct die URL zu der Nexus-Instanz konfiguriert werden.

  • Attribut-Key: url
  • Datentyp: String
  • Beispiel: "url": "https://baseline.cloudogu.net/nexus"
2.3.2 Konfiguration von Nexus-Artefakten

Es können ein oder mehrere Artefakte angegeben werden, die aus Nexus gesammelt werden. Die Konfiguration der Artefakte erfolgt dabei als ein Array von Nexus-Artefakt-Objekten.

  • Attribut-Key: nexus_artefacts
  • Datentyp: Array
  • Beispiel:
"nexus_artefacts": [
  {
    "repository": "maven-releases",
    "name": "Petclinic JAR",
    "location": "org/springframework/samples/spring-petclinic/${tag}/spring-petclinic-${tag}.jar"
  }
]
2.3.2.1 Konfiguration eines Nexus-Artefakts

Für die Konfiguration eines Nexus-Artefakts müssen das Repository, der Name und der Ort des Artefakts angegeben des werden.

2.3.2.2 Konfiguration des Artefakt-Repositorys

Das Artefakt-Repository gibt das Repository an, in dem nach dem bestimmten Artefakt gesucht wird.

  • Attribut-Key: repository
  • Datentyp: String
  • Beispiel: "repository": "maven-releases"
2.3.2.3 Konfiguration des Artefakt-Namens

Der Artefakt-Name gibt den Namen an, unter dem das Artefakt an der Baseline gespeichert wird.

  • Attribut-Key: name
  • Datentyp: String
  • Beispiel: "name": "Petclinic JAR"
2.3.2.4 Konfiguration des Artefakt-Ortes

Der Ort gibt den Namen an, unter dem das zu sammelnde Artefakt gefunden werden kann. Die Lokation kann andere Werte aus der Projektkonfiguration als Platzhalter verwenden.

  • Attribut-Key: location
  • Datentyp: String
  • Beispiel: "location": "org/springframework/samples/spring-petclinic/${tag}/spring-petclinic-${tag}.jar"

2.4 Konfiguration zum Sammeln einer Jenkins-Build-Logdatei

Die Jenkins-Build-Logdatei wird - anders als der Name vielleicht vermuten lässt - nicht direkt aus dem Jenkins selbst, sondern aus Nexus gesammelt. Dort wird die Build-Logdatei vom Jenkins abgelegt.

Konkret wird beim Jenkins-Build über eine Jenkins-Library ein Step zur Verfügung gestellt, über den ein sogenannter Build-Report erzeugt wird. Dieser extrahiert die für den Build relevanten Informationen und lädt sie nach dem deployment des eben generierten Artefakts in den Nexus.

Beim Sammeln der Baseline-Elemente wird für die Jenkins-Build-Logdatei im unter jenkins konfigurierten Nexus-Repository nach einer Jenkins-Build-Logdatei (maven.extension=log) gesucht, die anhand der Revision (Commit-ID) des Baseline-Tags ermittelt wird. Die Commit-ID ist der classifier der Maven-Dependency.

Die Konfiguration erfolgt unter dem Punkt "jenkins": { ... }

  • Attribut-Key: jenkins
  • Datentyp: Struct
  • Optional
  • Beispiel:
"jenkins": {
  "nexus_url": "https://baseline.cloudogu.net/nexus",
  "repository": "maven-releases"
},
2.4.1 Konfiguration eines Nexus-Repositorys für das Sammeln der Jenkins-Build-Logdatei

Wenn eine Jenkins-Build-Logdatei aus Nexus gesammelt werden soll, müssen in dem Jenkins-Struct die URL zu der Nexus-Instanz und das Repository konfiguriert werden.

2.4.1.1 Konfiguration der Nexus-URL

Die Nexus-URL gibt die URL zum Nexus an, in dem sich das Repository mit den Jenkins-Build-Logdateien befindet.

  • Attribut-Key: nexus_url
  • Datentyp: String
  • Beispiel: "nexus_url": "https://baseline.cloudogu.net/nexus"
2.4.1.2 Konfiguration des Repositorys

Das Repository gibt das Repository an, in dem nach der Jenkins-Build-Logdatei gesucht wird.

  • Attribut-Key: repository
  • Datentyp: String
  • Beispiel: "repository": "maven-releases"
2.4.2 Beispiel-Abfrage zum Sammeln der Jenkins-Build-Log-Datei

Die vom Baseline-Dogu an Nexus gesendete Abfrage zum Sammeln der Jenkins-Build-Log-Datei sieht dann beispielsweise so aus: https://baseline.cloudogu.net/nexus/service/rest/v1/search/assets?repository=maven-releases&maven.extension=log&maven.classifier=eb6b0757d6c24727417b417247f73805ad60c0e6

Erläuterung zur Zusammensetzung der URL:

  • https://baseline.cloudogu.net/nexus ist die konfigurierte nexus_url
  • repository=maven-releases: maven-releases ist das konfigurierte repository
  • maven.extension=log gibt an, dass sich um ein Maven-Artefakt mit der Erweiterung log handelt.
  • maven.classifier=eb6b0757d6c24727417b417247f73805ad60c0e6 gibt den Klassizifierer des Maven-Artefakts an. eb6b0757d6c24727417b417247f73805ad60c0e6 ist die zum Commit des Tags zugehörige Commit-ID (Revision).

2.5 App-Version

Im Textfeld für das Verwalten von Projekten wird pro Projekt auch ein Feld app_version angezeigt. Dieser Wert wird vom System automatisch geschrieben und ist lediglich für interne, technische Details erforderlich und kann auch nicht verändert werden.