oliver
I'm new here

Package Pool und Tags / Revisionen

Hallo Community,

ich verwende die Paketverwaltung, um Content aus einem Masterprojekt in ein Zielprojekt auszurollen. Im Zielprojekt möchte ich in einem Workflow die durch den Rollout entstandenen Änderungen analysieren. Hierfür habe ich an das Ereignis "Freigabe" einen Workflow gehängt, in dessen erster Aktivität ein Skript ausgeführt wird. Die Idee war nun, anhand der durch den Package Pool erzeugten Tags die relevanten Revisionen zu finden. Das Problem ist, dass im Skript ein Tag nicht gefunden wird, welches jedoch bei einer folgenden Abfrage über die Beanshell-Konsole vorhanden ist.

Der Aufruf:

context.project.getTags(null, 10);

innerhalb des Skriptes im Workflow liefert z. B.:

<[de.espirit.firstspirit.storage.TagImpl@6e5, de.espirit.firstspirit.storage.TagImpl@6e4, ...

wohingegen der Aufruf auf der Beanshell-Console ein Tag mehr liefert (das neueste):

<[de.espirit.firstspirit.storage.TagImpl@6e6, de.espirit.firstspirit.storage.TagImpl@6e5, de.espirit.firstspirit.storage.TagImpl@6e4, ...

Das zusätzliche Tag ist eindeutig durch den Paket-Rollout entstanden, was ich anhand der Tag-Properties "PackageName" und "PackageVersionNumber" validiere.

Die erste Frage wäre, worin das Verhalten des Skriptes innerhalb des Workflows begründet ist. Warum fehlt das zusätzliche Tag beim Aufruf aus dem Skript, obwohl es durch den Paket-Rollout erzeugt wurde?

Die nächste Frage wäre, ob es einen anderen Weg gibt, verlässlich *alle* Revisionen zu finden, die durch einen Package-Rollout erzeugt wurden. Ich gehe über die Tags, da anhand der Tag-Properties eindeutige Kriterien vorhanden sind, worüber ein Tag dem Package-Rollout zugeordnet werden kann (Properties "PackageVersionNumber" und "PackageName"). Gibt es ein anderes Vorgehen?

Für jedwede Hilfe bedanke ich mich im Vorraus. Grüße,

Tilman Linden

Labels (1)
0 Kudos
4 Replies
tklein
I'm new here

Re: Package Pool und Tags / Revisionen

Was soll den dadurch erreicht werden?

Generell kann man über das "ImportInfo" arbeiten hier gibt es dann 4 Arten von Knoten (neu, gelöscht, geändert, Konflikt). Für "neu" und "gelöscht" und "Konflikt" ist damit schon klar was verändert wurde. Auf den Objekten, die "geändert" wurden kann man jetzt die Änderungen analysieren (Stichwort: HistoryProvider).

0 Kudos
oliver
I'm new here

Re: Package Pool und Tags / Revisionen

Hallo Tobias,

der Ansatz mit den Tags ist wie beschrieben darin begründet, dass sich anscheinend Tags über die Properties "PackageVersionNumber" und "PackageName" eindeutig einem Paket-Rollout zuordnen lassen. Ein solches Kriterium habe ich bei Revisionen nicht finden können. Zwar finden sich im Kommentar der Revisionen ebenfalls Hinweise auf den Paket-Rollout, jedoch nach meinem Wissensstand verpackt in einem einzigen String. Dieses Kriterium war mir "zu weich"(anders gesagt: aVersionNumber.equals(Tag.getProperty("PackageVersionNumber")) finde ich belastbarer als Revision.getComment().indexOf(aVersionNumber) >= 0). Ich lasse mich aber gerne eines besseren belehren.

Mein erster Ansatz war übrigens, über ImportInfo zu gehen und mir nur die neueste Revision der neuen/geänderten Knoten geben zu lassen und diese zu analysieren. Mir ist dann jedoch aufgefallen, dass es unter (mir unbekannten) Umständen anscheinend mehrere Revisionen für einen Knoten pro Paket-Rollout geben kann. Daher suche ich eben nach einem Kriterium, diese Revisionen verlässlich finden zu können.

Weitere Hilfe gerne! Gruß,

Tilman

0 Kudos
oliver
I'm new here

Re: Package Pool und Tags / Revisionen

Gibt es hier noch weitere Erkenntnisse?

Danke und Grüße

0 Kudos
oliver
I'm new here

Re: Package Pool und Tags / Revisionen

Hier hat sich nun über andere Kanäle einiges klären lassen, was ich hier nochmal kurz zusammenfasse:

  1. Die durch einen Paketrollout gesetzten Tags werden tatsächlich erst *nach* der Ausführung von mit Paket-Ereignissen verbundenen Workflows vollständig gesetzt.
  2. Ich verwende nun folgenden Ansatz, um die relevanten Revisionen zu finden:
    1. Die untere Grenze der zu analysierenden Revisionen ist durch die Revision gegeben, die mit einem "Restore-Tag" versehen ist. Dieses Tag wird durch die Paketverwaltung gesetzt, bevor irgendwelche Änderungen im Zielprojekt vorgenommen werden, und lässt sich folgendermaßen identifizieren:

      Arrays.asList("RestoreImportPackage", "RestoreInstallUpdate").contains(theTag.getName()) && theNameOfThePackage.equals(theTag.getProperty("PackageName") &&

      theVersionNumberOfThePackage.equals(theTag.getProperty("PackageVersionNumber")

    2. Für alle geänderten / neuen Knoten sind jetzt die Revisionen nach der Revision des Restore-Tags bis zur aktuellen Revision relevant. (Die Revision mit dem Restore-Tag selber ist nicht zu betrachten.)
0 Kudos