torben
df7ea93060
Files changed: - kb/concepts/INDEX.md - kb/concepts/Mass-Update Gate.md - kb/concepts/Publish-Remote Gate.md - kb/entities/projects/Chemenu.md - kb/entities/tools/wikitool.md - kb/index.md - kb/log.md - kb/provenance.md - kb/sources/INDEX.md - kb/sources/Source - Publish-Remote Gate and Issue Triage Session 2026-09-01.md
73 lines
3.1 KiB
Markdown
73 lines
3.1 KiB
Markdown
---
|
|
type: types/concept.md
|
|
concept_type: workflow
|
|
tags: []
|
|
created: 2026-09-01
|
|
modified: 2026-09-01
|
|
related: [Mass-Update Gate, Chemenu]
|
|
sources: [Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]
|
|
confidence: 0.50
|
|
confidence_base: 0.70
|
|
provenance: sourced
|
|
summary: 'Drittes, im Code durchgesetztes Gate: publish bricht mit Exit 42 ab, wenn die aufgeloeste Push-URL nicht in einer optionalen, gitignoreten Allowlist steht; anders als die anderen Gates gibt es keinen Freigabe-Token.'
|
|
---
|
|
# Publish-Remote Gate
|
|
|
|
**Typ:** Workflow
|
|
|
|
## Definition
|
|
|
|
Ein im Code durchgesetztes Gate, das einen Schreibvorgang (hier: `publish`) auf ein
|
|
deklariertes, per Datei zugelassenes Ziel beschränkt. Der Vorgang bricht ab, wenn das
|
|
aufgelöste Push-Ziel nicht in der Allowlist steht - unabhängig davon, unter welchem Namen der
|
|
Remote lokal konfiguriert ist.
|
|
|
|
## Kernpunkte
|
|
|
|
- **Geprüft wird die aufgelöste URL, nicht der Remote-Name.** Ein namensbasiertes Gate würde
|
|
ein `publish` durchlassen, dessen `origin` zwischenzeitlich auf ein anderes Ziel umgebogen
|
|
wurde - genau der Fall, den das Gate abfangen soll.
|
|
- **Kein Freigabe-Token, anders als vergleichbare Gates.** Ein Gate, dessen Frage per
|
|
Änderungssatz beantwortbar ist ("ist diese konkrete Änderung richtig?"), kann sich mit einem
|
|
Token lösen, den ein Mensch einmalig ausstellt. Ein Gate, dessen Frage eine stehende
|
|
Eigenschaft des Checkouts ist ("gehört dieser Inhalt grundsätzlich in dieses Ziel?"), sollte
|
|
keinen Token haben - der einzige Weg daran vorbei ist ein bewusster Edit der Konfigurationsdatei
|
|
durch den Menschen, nie ein automatisierter Bypass.
|
|
- **Die Allowlist-Datei ist per Checkout, nicht Teil des versionierten Inhalts.** Sie
|
|
beschreibt, wohin *dieser* Checkout schreiben darf - eine committete Kopie würde jedem Klon
|
|
dieselbe Erlaubnis unterschieben, unabhängig davon, ob sie für ihn zutrifft.
|
|
- **Fehlende Datei bedeutet unbeschränkt, kaputte Datei bedeutet Fehler.** Diese Unterscheidung
|
|
ist wichtig: Ein Checkout ohne Beschränkungsbedarf soll nicht gezwungen sein, eine leere
|
|
Konfigurationsdatei zu pflegen; eine beschädigte Datei darf aber nicht wie eine abwesende
|
|
behandelt werden, sonst wird eine defekte Sicherung zu einer stillschweigend abgeschalteten.
|
|
|
|
## Wann zu verwenden
|
|
|
|
- Ein Checkout kann an mehr als ein Remote-Ziel schreiben, und ein Schreibvorgang an das
|
|
falsche Ziel ist teuer oder nicht rückgängig zu machen (z. B. weil das Ziel öffentlich ist).
|
|
- Die Menge der zulässigen Ziele ist eine stabile Eigenschaft des Checkouts, keine
|
|
Einzelfallentscheidung pro Vorgang.
|
|
|
|
## Wann NICHT zu verwenden
|
|
|
|
- Wenn nur ein Remote existiert und kein Risiko einer Zielverwechslung besteht - dort ist die
|
|
Allowlist reine Formalität ohne Schutzwirkung.
|
|
- Für Entscheidungen, die tatsächlich pro Änderungssatz getroffen werden sollen (dafür ist ein
|
|
Token-basiertes Gate wie das Mass-Update-Gate das richtige Muster).
|
|
|
|
## Verwandte Concepts
|
|
|
|
- [[Mass-Update Gate]]
|
|
|
|
## Beziehungen
|
|
|
|
- **gilt fuer:** [[Chemenu]]
|
|
- **verwandtes Gate:** [[Mass-Update Gate]]
|
|
|
|
## Siehe auch
|
|
|
|
- [[Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]]
|
|
- [[Chemenu]]
|
|
- [[Mass-Update Gate]]
|
|
|