Comenius-Institut/FOERBICO_und_rpi-virtuell
Comenius-Institut/FOERBICO_und_rpi-virtuell
14
6
Fork 3
Code Issues136 Pull requests10 Projects8 Releases Wiki Activity

Webseite: Deployment per "Actions" #139

New issue
Closed
opened 2024-11-20 08:51:57 +00:00 by sicking · 7 comments
sicking commented 2024-11-20 08:51:57 +00:00
Owner

Webseite beim Mergen in Branch "main" (über einen Pull Request) veröffentlichen

  • Woodpecker Anbindung an neue Server-Infrastruktur
  • Rechtemanagment (wer darf pushen, mergen) - Gefährdung von CI-Infos? (CI = Continuous Integration 😄)
**Webseite beim Mergen in Branch "main" (über einen Pull Request) veröffentlichen** - Woodpecker Anbindung an neue Server-Infrastruktur - Rechtemanagment (wer darf pushen, mergen) - Gefährdung von CI-Infos? (CI = Continuous Integration 😄)
😆 1
sicking added this to the AP 9-2 Techn. Infrastruktur weiterentwickeln (CI) milestone 2024-11-20 08:51:57 +00:00
sicking added the
technik
 label 2024-11-20 08:51:57 +00:00
sicking added this to the Projekt-Technik (das, was in APs "IT" genannt wird) project 2024-11-20 08:51:57 +00:00
sicking commented 2024-12-03 12:07:53 +00:00
Author
Owner

Bei einer beliebigen Änderung im Unterordner "sb" und einem Push auf den Branch "main" wird nun ein Webseiten-Deployment angestoßen.

Siehe Build-Lauf Nr. 107.

Bei einer beliebigen _Änderung im Unterordner "sb"_ **und** einem _Push auf den Branch "main"_ wird nun ein Webseiten-Deployment angestoßen. Siehe Build-Lauf Nr. 107.
blogartikel-bibel-oer-mit-autorenschaft.png
243 KiB
blogartikel-bibel-oer-mit-autorenschaft.png
👍 1
sicking commented 2024-12-03 12:16:24 +00:00
Author
Owner

Soll das Anstoßen eines Webseiten-Deployments nur erfolgen, wenn in den main-Branch über einen gemergten Pull Request gepushed wird?

Bei größeren ("gefährlichen") Änderungen macht es Sinn, nicht direkt auf "main" zu arbeiten bzw. zu pushen. Im ungünstigsten Fall könnte es bedeuten, dass die Webseite (auf irgendeine Art) zerschossen wird.

Soll das Anstoßen eines Webseiten-Deployments nur erfolgen, wenn in den main-Branch über einen gemergten Pull Request gepushed wird? Bei größeren ("gefährlichen") Änderungen macht es Sinn, _**nicht** direkt auf "main" zu arbeiten_ bzw. zu pushen. Im ungünstigsten Fall könnte es bedeuten, dass die Webseite (auf irgendeine Art) zerschossen wird.
👍 1
sicking commented 2024-12-17 08:39:24 +00:00
Author
Owner

[...] Im ungünstigsten Fall könnte es bedeuten, dass die Webseite (auf irgendeine Art) zerschossen wird.

Diesen Fall hatten wir anscheinend bereits am 4.12. (vgl. Chat-Nachricht)
Dort waren dann auf der Startseite Blogbeiträge zu sehen.

Leider habe ich bislang nicht reproduzierbar ermitteln können, wann unter welchen Bedingungen Hugo wie solche "kaputten" Seiten erstellt.

Deswegen ist der Veröffentlichungs-Automatismus per Woodpecker vorerst deaktiviert. (auf drei Arten ;-)

  • der Start von Pipelines muss in Woodpecker per Extra-Klick (manuell) erlaubt werden
  • der Ordner, in dem für dieses Repository nach Pipelines gesucht wird, ist in der Woodpecker-Konfig geändert (auf einen nicht existierenden Ordner)
  • die Pipeline-Definition (*.yaml) wurde umbenannt, so dass Woodpecker keine Pipeline-Definition mehr findet
> [...] Im ungünstigsten Fall könnte es bedeuten, dass die Webseite (auf irgendeine Art) zerschossen wird. Diesen Fall hatten wir anscheinend bereits am 4.12. (vgl. Chat-Nachricht) Dort waren dann auf der Startseite Blogbeiträge zu sehen. Leider habe ich bislang nicht **reproduzierbar** ermitteln können, wann unter welchen Bedingungen Hugo wie solche "kaputten" Seiten erstellt. Deswegen ist der Veröffentlichungs-Automatismus per Woodpecker vorerst deaktiviert. (auf _drei_ Arten ;-) - der Start von Pipelines muss in Woodpecker per Extra-Klick (manuell) erlaubt werden - der Ordner, in dem für dieses Repository nach Pipelines gesucht wird, ist in der Woodpecker-Konfig geändert (auf einen nicht existierenden Ordner) - die Pipeline-Definition (*.yaml) wurde umbenannt, so dass Woodpecker keine Pipeline-Definition mehr findet
sicking added the
oer.community
 label 2025-02-11 14:08:05 +00:00
sicking modified the project from Projekt-Technik (das, was in APs "IT" genannt wird) to Webseite oer.community 2025-02-11 14:08:10 +00:00
sicking changed title from Webseite beim Mergen in Branch "main" (über einen Pull Request) veröffentlichen to Webseite: beim Mergen in Branch "main" (über einen Pull Request) veröffentlichen 2025-02-11 14:08:18 +00:00
sicking changed title from Webseite: beim Mergen in Branch "main" (über einen Pull Request) veröffentlichen to Webseite: Deployment per "Actions" 2025-02-11 14:43:04 +00:00
sicking commented 2025-02-11 14:48:48 +00:00
Author
Owner

Die Commit- / Merge- ... Disziplin lässt etwas nach. ;-)
Kleine (kleinste) Änderungen werden öfter direkt in den Branch "main" gepushed. Damit verlieren wir eine Möglichkeit, einen Review-Workflow auf Basis von Branches zu etablieren.

U. a. das neue Issue "Webseite: Workflow für die Aktualisierung der Webseite durch jede*n (LS) " will sich dem annehmen.

Am besten nach hierhin () "migrieren".

Die Commit- / Merge- ... Disziplin lässt etwas nach. ;-) Kleine (kleinste) Änderungen werden öfter direkt in den Branch "main" gepushed. Damit verlieren wir eine Möglichkeit, einen Review-Workflow auf Basis von Branches zu etablieren. U. a. das neue Issue "Webseite: Workflow für die Aktualisierung der Webseite _durch jede*n_ (LS) #218" will sich dem annehmen. Am besten #218 nach hierhin (#139) "migrieren".
sicking commented 2025-04-14 13:55:39 +00:00
Author
Owner

Nicht nur wegen sollten wir beim Deployen markieren, welchen Stand wir genau veröffentlicht haben.

erste Idee für einen Deyployment-Workflow hatte ich hier notiert:

Das Issue bitte nicht mehr bearbeiten. Stattdessen hier weiter.

Aktuelle Idee für Deployment:

  • Actions manuell
  • Deployment nach "INT"
    • int ist virtuell und zeigt auf rpi
    • Test-Veröffentlichung pro Branch
  • Deployment nach PROD: aus "main"? , aber manuell angestoßen
Nicht nur wegen https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/pulls/316#issuecomment-3940 sollten wir beim Deployen markieren, welchen Stand wir **genau** veröffentlicht haben. erste Idee für einen Deyployment-Workflow hatte ich hier notiert: https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/issues/218#issuecomment-2782 Das Issue #218 bitte nicht mehr bearbeiten. Stattdessen hier weiter. ---- Aktuelle Idee für Deployment: - Actions manuell - Deployment nach "INT" - int ist virtuell und zeigt auf rpi - Test-Veröffentlichung pro Branch - Deployment nach PROD: aus "main"? , aber manuell angestoßen
sicking commented 2025-05-26 10:18:29 +00:00
Author
Owner

Aktueller Stand

  • (für mich gefühlter) großer Unmut über fehlenden Fortschritt
  • um weiter zu kommen, wird die bisherige Entwicklung "einfach" produktiv gesetzt
  • weiterhin: genauer Workflow nicht (exakt) definiert, kein Fallback-Plan, wenn das Deployment "etwas kaputtes" generiert
Aktueller Stand - (für mich gefühlter) großer Unmut über fehlenden Fortschritt - um weiter zu kommen, wird die [bisherige Entwicklung](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/commit/778fb1d6944362418c62f071aef376faeb2389b9) "einfach" produktiv gesetzt - weiterhin: genauer Workflow nicht (exakt) definiert, kein Fallback-Plan, wenn das Deployment "etwas kaputtes" generiert
sicking commented 2025-05-26 11:55:06 +00:00
Author
Owner

in den letzten Tagen erstellte zugehörige Pull-Requests:

erfolgreicher Build für main:

in den letzten Tagen erstellte zugehörige Pull-Requests: - [Webseite soll per Woodpecker Action deployed werden #364](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/pulls/364) - [Woodpecker Build bricht ab wegen unterschiedlichem Stand des Themes #366](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/pulls/366) erfolgreicher Build für main: - https://woody.git.rpi-virtuell.de/repos/3/pipeline/161 - Änderungen, die dadurch (automatisch) deployed wurden: https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/pulls/365/files#diff-cd76759418212cbad7c55e408148cf3b74ed8c6f
Sign in to join this conversation.
No labels
Blog
CI
Community-Hub
Duplikat
Events
FAU
Fehler / Bug
GU
Hilfe gesucht
Offene Frage
Terminiert
Verbesserung
gutes erstes Issue
invalid
oer.community
technik
No milestone
AP 9-2 Techn. Infrastruktur weiterentwickeln (CI)
No project
Webseite oer.community
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#218 Webseite: Workflow für die Aktualisierung der Webseite _durch jede*n_ (LS)
Comenius-Institut/FOERBICO_und_rpi-virtuell
Reference: Comenius-Institut/FOERBICO_und_rpi-virtuell#139
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?