notifications.yml is invoked via workflow_call from the caller
workflow, so inside this job gitea.event_name reports "workflow_call"
rather than the top-level event (push/schedule/...) that actually
started the run. Comparing that against the Actions API's per-run
event field (which reports the real trigger) never matched, so
previous_conclusion always stayed "unknown" and healed notifications
never fired. Now the current run's real event is captured from the API
response itself and used for the comparison, falling back to
gitea.event_name only if the current run isn't found in the scanned
history.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gitea's PyPI registry only resolves /simple/<package>/, not the bare
/simple/ index root, so the v1.11.2 probe added to give visible
diagnostics for the private-index setup step was always 404ing even
when the index and credentials were correct. This broke installs of
private Python packages during builds. The probe now only fails hard
on 401/403 (auth rejected) or an unreachable host; a plain 404 is
logged and left to pip's own resolution to confirm.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
dresberandClaude Sonnet 5