Parallelisierung von GitHub Actions

[hupling]

[hupling]

Leider war @devtobi bei unserem Treffen im August nicht dabei. Wo wir über die Pip geredet haben.
Er möchte meine ganze Pipeline verwerfen und nach dem Abbild oben aufbauen. Er hat hat es schon mit CodeQL versucht Schritte zu parallelisieren. Daher will er nicht meinen MR it-at-m/refarch-templates#361 mergen.

Ich persönlich finde eine sequenzielle Pipeline besser als alles zu parallelisieren. Ich hätte jetzt auch erstmal meine Sachen gemergt und danach einen Umbau angefangen. Besser etwas zu haben als noch gar nichts. Im Refarch-Template haben deswegen einige Sachen nicht funktioniert.

Wie seht ihr das?

[hupling]

@ejcsid Ist es schlimm, wenn sich das externe Refarch Projekt komplett inkompatibel mit der internen Pipeline wird?

[ejcsid]

@ejcsid Ist es schlimm, wenn sich das externe Refarch Projekt komplett inkompatibel mit der internen Pipeline wird?

Nein, finde ich nicht. Diese bauen dann ja eine GitHub Pipeline auf, und verwenden intern die dort erstellten Images bzw. Helm Charts und brauchen also intern dann eine andere Pipeline als die bisherige.

[hupling]

Sachen aus dem Workshop:

• jar auch beim Github-Release
• Keykloak + Postgress auch in Helm Chart.
• nochmal schauen wie das Autorollout bei latest,dev funktioniert, weil man da ja einen Image-Stream braucht

[ejcsid]

@hupling für den ersten Punkt hab ich ein Issue angelegt. Die anderen beiden Punkte verstehe ich nicht. Kannst du dafür Issues anlegen und genauer beschreiben, was gemacht werden muss.

[hupling]

@ejcsid sind jetzt die Issues verständlich.

• Keykloak + Postgress auch in Helm Chart. Keykloak + Postgress auch in Helm Chart hinzufügen #44
• Autorollout Autorollout dev, latest #45

[hupling]

Ich verstehe nicht warum der Titel von hier umbenannt wurde. Ich sehe das eher als Epic.

@devtobi hat gesagt alles ist Modular.

Also brauchen wir Issues für

• linting
• testen
• build jar + image
• make release

Theoretisch kann man die Punkte noch in npm und maven trennen

[ejcsid]

Oben in der Beschreibung steht nur was von der Parallelisierung, deshalb habe ich den Titel geändert. "Neue SPS" finde ich auch zu generisch, das sagt mir gar nichts. Ich würde da eher sowas erwarten wie "OSS Pipeline RefArch" und eine Beschreibung, was da alles dazu gehört. Wenn du weitere Issues brauchst, dann kannst du die natürlich anlegen. Dann bitte zum SPS Projekt hinzufügen.

[ejcsid]

@devtobi wie ist da der stand?

[hupling]

@devtobi wir möchten nicht das npm run linting und npm run build für docs und frontend zentralisieren.

Wir bevorzugen getrennte Schritte für Docs und Refarch-Frontend.

[hupling]

@devtobi wir möchten nicht das npm run linting und npm run build für docs und frontend zentralisieren.

Wir bevorzugen getrennte Schritte für Docs und Refarch-Frontend.

@ejcsid leider weiß ich nicht mehr, was wir heute besprochen haben.

Ich würde halt das in 2 Actions machen und dann kann man es besser verwalten. Jetzt nochmal eine Abstractions-Level zu machen, finde ich unnötig. Das wäre dann -> Workflow Templates -> Reusing Workflows -> Actions.

[ejcsid]

Das wäre dann -> Workflow Templates -> Reusing Workflows -> Actions.

Wir wollten es uns nochmal anschauen. Vorteil für die Anwendungsrepos könnte bei Verwendung der .github/workflows (ich nehme mal an, das sind dann die Reusing WF) sein, dass sie dann eben nicht mit den Actions rumhantieren müssen und weniger Aufwand beim LCM haben. Ich hab mal angefangen mir Gedanken zu machen:

• Pflege von Actions + .github/workflows: Bedeutet mehr Aufwand für das SPS Team. Allerdings werden wir so oder so ein paar workflows anbieten müssen. Die .github/workflows und Actions sollten möglichst generisch sein, so dass die Anwendungsrepos diese über Konfiguration geeignet nutzen können
• Wenn wir neue Funktionalität anbieten, können wir das in die .github-WF einbauen und die Anwendungsrepos können dies dann sofort über Konfiguration nutzen. Wenn wir keine WF haben, dann müssen die Anwendungsrepos ihre WF selbst erweitern.
• Vermutlich wird das LCM für die Anwendungsrepos mit den .github-WF einfacher. Das SPS Team muss weniger dokumentieren und hat dann hoffentlich auch weniger Support
• Parallelisierung der Actions über .github-WF ist anscheinend möglich (Beispiel CodeQL). Bin noch nicht dazu gekommen, mir das anzuschauen. Wenn dem so ist, wäre das natürlich auch ein Vorteil
• Braucht ein Repo einen anderen als von uns angebotenen .github-WF, spricht nichts dagegen, direkt die Actions zu benutzen

Was spricht - außer das wir beim SPS Team etwas mehr Aufwand haben - dagegen, im Normalfall die .github-WF statt direkt der Actions zu verwenden?

[hupling]

@ejcsid

https://github.com/it-at-m/refarch/blob/main/.github/workflows/maven_node_build.yaml also der Simon konnte jetzt auch besser seine Pipeline erstellen, weil er die Actions flexibler anpassen kann, als einen reuseable Workflow

KPS hat mehrere Ausbaustufen, ein Image muss auf dem Branch main und main-1.x gebaut werden. Leider lässt sich mit einem Workflow so eine komplizierte Regel nicht umsetzen. Hier kann man keine Input Variable für einzelne Schritte einsetzen - if: github.ref == 'refs/heads/main Das muss auf der höchsten Ebene sein.

Im Endeffekt sehe ich keine Vorteil eine zusätzliche Abstraktionsebene einzuführen. Die Pipelines werden unflexibler und die ganze Pipeline ist in einem einzigen Schritt verschattet. Bei den einzelnen Actions versteht man, wenigstens noch was gemacht wird. z. B. Bauen jar, bauen Image

[ejcsid]

Ok, I had a look to that. Meanwhile I agree, that we don't need .github/workflows as the refarch-templates/.github folder is copied to the application repo that are created based on refarch-templates repo. We'll create default workflows in refarch-templates/.github which will be convenient for most projects. May be at beginning, projects will have to make some more configuration but like this the workflows hopefully will fit for most projects as the configuration can be done more specific. Projects with special needs still can create their own workflows.

Let's discuss this:

• Renovate Bot of refarch-template-Repo should support automerge for folder refarch-templates/.github/workflows on levels patch and minor
• .github/actions/* must have a version in semantic style. For that we need a workflow in .github that creates a new release for actions.
• There must be a documentation for the .github/actions in .github/docs folder and a documentation of refarch-templates/.github/workflows in refarch-templates/docs folder
• Do we really need repo lhm_actions?

@hupling @devtobi @tobiasholler @ffmuc

[hupling]

.github/actions/* must have a version in semantic style. For that we need a workflow in .github that creates a new release for actions.

#27

There must be a documentation for the .github/actions in .github/docs folder and a documentation of refarch-templates/.github/workflows in refarch-templates/docs folder

#101

Do we really need repo lhm_actions?

yes to avoid dependencies within a repo and have full access to the repo without github-admins as codeowners.

but now we have it in the npm release.
https://github.com/it-at-m/.github/blob/main/.github/actions/action-npm-release/action.yml#L64

the appstore workflows in .github are the same as in the refarch-template repo. Maybe we should only maintain the refarch-template. New projects forked from there.

[ejcsid]

#101

Added description to this issue.

yes to avoid dependencies within a repo and have full access to the repo without github-admins as codeowners.

The reason we created lhm_actionswas to separate workflows and actions, not to avoid github-admins as codeowners. But yes: let*s move the actions as .github is a repo for github-it@m-organization, but actions are used by repos.

but now we have it in the npm release.
https://github.com/it-at-m/.github/blob/main/.github/actions/action-npm-release/action.yml#L64

We'll have to change this. I think action-npm-release shouldn't checkout code nor run a build but only create a npm package. It needs of course other input variables then. Created #109

Maybe we should only maintain the refarch-template. New projects forked from there.

👍 - yes!