Aktuell definiert das reusable Workflow zwei parallele Jobs (semgrep + trivy). act_runner v0.6.1 startet beide gleichzeitig im selben Task und beide machen chown -R 1001:1001 /workspace/... parallel — Race-Condition. Einer der Container (in der Praxis Semgrep) bekommt /var/run/act/ nie korrekt provisioniert und failed silent (Job-API zeigt steps: [], nur Trivy-Logs sichtbar). Der gesamte Run wird als failure markiert obwohl Trivy 0 Vulns findet.
Beobachtet auf hellion-initiative-v3 (alle Runs seit Forge-Cutover am 9. Mai failen), erwartbar für alle 8 Repos die das reusable Workflow nutzen.
Fix
Ein einziger scan-Job mit beiden Tools sequenziell als Steps:
Checkout
Setup Python
Install Semgrep
Install Trivy
Run Semgrep SAST
Run Trivy filesystem scan (if: always() damit Trivy auch bei Semgrep-Fail läuft)
Kein paralleles Workspace-Sharing mehr, klarer Log-Stream, ein Lifecycle.
Nach Merge
In jedem Consumer-Repo den nächsten Push abwarten oder Workflow manuell re-runnen
hellion-initiative-v3 zuerst verifizieren — alle bisherigen Runs failed dort
## Was und warum
Aktuell definiert das reusable Workflow zwei parallele Jobs (`semgrep` + `trivy`). act_runner v0.6.1 startet beide gleichzeitig im selben Task und beide machen `chown -R 1001:1001 /workspace/...` parallel — Race-Condition. Einer der Container (in der Praxis Semgrep) bekommt `/var/run/act/` nie korrekt provisioniert und failed silent (Job-API zeigt `steps: []`, nur Trivy-Logs sichtbar). Der gesamte Run wird als failure markiert obwohl Trivy 0 Vulns findet.
Beobachtet auf hellion-initiative-v3 (alle Runs seit Forge-Cutover am 9. Mai failen), erwartbar für alle 8 Repos die das reusable Workflow nutzen.
## Fix
Ein einziger `scan`-Job mit beiden Tools sequenziell als Steps:
1. Checkout
2. Setup Python
3. Install Semgrep
4. Install Trivy
5. Run Semgrep SAST
6. Run Trivy filesystem scan (`if: always()` damit Trivy auch bei Semgrep-Fail läuft)
Kein paralleles Workspace-Sharing mehr, klarer Log-Stream, ein Lifecycle.
## Nach Merge
- [ ] In jedem Consumer-Repo den nächsten Push abwarten oder Workflow manuell re-runnen
- [ ] hellion-initiative-v3 zuerst verifizieren — alle bisherigen Runs failed dort
act_runner v0.6.1 fails when 2 jobs in the same task chown the shared workspace in parallel. Sequential steps inside one job sidestep the issue.
Trivy step uses if: always() so both tools surface findings in a single run.
act_runner v0.6.1 fails when 2 jobs in the same task chown the shared workspace in parallel. Sequential steps inside one job sidestep the issue.
Trivy step uses if: always() so both tools surface findings in a single run.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Was und warum
Aktuell definiert das reusable Workflow zwei parallele Jobs (
semgrep+trivy). act_runner v0.6.1 startet beide gleichzeitig im selben Task und beide machenchown -R 1001:1001 /workspace/...parallel — Race-Condition. Einer der Container (in der Praxis Semgrep) bekommt/var/run/act/nie korrekt provisioniert und failed silent (Job-API zeigtsteps: [], nur Trivy-Logs sichtbar). Der gesamte Run wird als failure markiert obwohl Trivy 0 Vulns findet.Beobachtet auf hellion-initiative-v3 (alle Runs seit Forge-Cutover am 9. Mai failen), erwartbar für alle 8 Repos die das reusable Workflow nutzen.
Fix
Ein einziger
scan-Job mit beiden Tools sequenziell als Steps:if: always()damit Trivy auch bei Semgrep-Fail läuft)Kein paralleles Workspace-Sharing mehr, klarer Log-Stream, ein Lifecycle.
Nach Merge