marcel/familienarchiv
1
0
Fork 0
Code Issues 117 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

devops: fix upload-artifact@v4 incompatibility and stabilise E2E CI #14

New Issue
Closed
opened 2026-03-19 17:11:29 +01:00 by marcel · 0 comments
marcel commented 2026-03-19 17:11:29 +01:00
Owner
Copy Link

Status

E2E networking is fixed — 27 E2E tests pass. However the job still shows as "failed" due to a separate problem with artifact uploading.

Root cause chain

1. upload-artifact@v4 not supported on Gitea (GHES)

Both the unit test and E2E jobs use actions/upload-artifact@v4 to upload screenshots/results. Gitea does not support the v2+ artifacts API:

@actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES.
❌  Failure - Main Upload E2E results

This causes the entire job to be marked as failed even though all tests passed.

2. Playwright cache is never saved

Because the upload step fails, success() evaluates to false for all subsequent steps — including the Playwright browser cache save. This means the cache is never written, and every run re-downloads ~280 MiB of Chromium binaries.

Fix

Option A — Downgrade to upload-artifact@v3 (compatible with Gitea):

uses: actions/upload-artifact@v3

Option B — Add continue-on-error: true to the upload steps:

- name: Upload E2E results
  if: always()
  continue-on-error: true
  uses: actions/upload-artifact@v4

Option A is cleaner. Option B keeps v4 but silences the failure.

Note: if artifact upload is not needed at all (screenshots are mainly for local debugging), the upload steps could simply be removed.

Changes required

  • Fix or remove Upload screenshots step in unit-tests job
  • Fix or remove Upload E2E results step in e2e-tests job
  • Verify Playwright cache is saved correctly after the fix

Acceptance criteria

  • E2E job shows green when all 27 tests pass
  • Unit test job shows green
  • Playwright browser cache is saved and restored on subsequent runs (no 280 MiB download every run)
## Status E2E networking is fixed — **27 E2E tests pass**. However the job still shows as "failed" due to a separate problem with artifact uploading. ## Root cause chain ### 1. `upload-artifact@v4` not supported on Gitea (GHES) Both the unit test and E2E jobs use `actions/upload-artifact@v4` to upload screenshots/results. Gitea does not support the v2+ artifacts API: ``` @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES. ❌ Failure - Main Upload E2E results ``` This causes the entire job to be marked as failed even though all tests passed. ### 2. Playwright cache is never saved Because the upload step fails, `success()` evaluates to `false` for all subsequent steps — including the Playwright browser cache save. This means the cache is never written, and every run re-downloads ~280 MiB of Chromium binaries. ## Fix **Option A — Downgrade to `upload-artifact@v3`** (compatible with Gitea): ```yaml uses: actions/upload-artifact@v3 ``` **Option B — Add `continue-on-error: true`** to the upload steps: ```yaml - name: Upload E2E results if: always() continue-on-error: true uses: actions/upload-artifact@v4 ``` Option A is cleaner. Option B keeps v4 but silences the failure. Note: if artifact upload is not needed at all (screenshots are mainly for local debugging), the upload steps could simply be removed. ## Changes required - Fix or remove `Upload screenshots` step in `unit-tests` job - Fix or remove `Upload E2E results` step in `e2e-tests` job - Verify Playwright cache is saved correctly after the fix ## Acceptance criteria - [ ] E2E job shows green when all 27 tests pass - [ ] Unit test job shows green - [ ] Playwright browser cache is saved and restored on subsequent runs (no 280 MiB download every run)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-critical
Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.
 P1-high
Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.
 P2-medium
Noticeable improvement; doesn't block anything; schedule opportunistically.
 P3-later
Cosmetic or parking-lot work; fine to stay open indefinitely.
 audit
Read-only audit / assessment work; produces a report rather than changing code
 bug
Something isn't working
 cleanup
Removal of dead code, vague comments, naming violations, and scratch artifacts
 collaboration
We want to extend the family archive to have more collaboration tools
 conversation
descoped
We will do that later
 devops
documentation
README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs
 epic
Marker for epic-level issues that group multiple child issues
 feature
file-upload
legibility
Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction
 notification
person
phase-1: security
Security hygiene — must be done first
 phase-2: container-images
Production-ready multi-stage Docker images
 phase-3: prod-compose
Production compose overlay + Caddy reverse proxy
 phase-4: spring-prod-profile
Spring Boot production configuration profile
 phase-5: backups
Database and object storage backup strategy
 phase-6: deployment-docs
.env.example, DEPLOYMENT.md, runbook
 phase-7: monitoring
Prometheus, Loki, Grafana, Alertmanager
 refactor
Code restructuring without behaviour change
 security
test
ui
UI/UX and accessibility issues
 user
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#14
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?