fix(system): ignore already_exists when saving to GitHub Actions cache

[Soner (shyim)]

Problem

Builds using the GitHub Actions cache can fail with:

ERROR	building assets: failed to save folder to GitHub Actions cache: already_exists

Real-world occurrence: FriendsOfShopware/FroshAdminDashboard run #30348425342, where shopware-cli extension zip exited 1 and took down the whole e2e job.

Cause

The GH Actions cache v2 API returns already_exists when an entry for a key has already been uploaded. The asset cache key is deterministic — sw-cli-<shopware-version>-<content-hash> — so this is hit whenever the same commit is re-run, or two jobs build the same extension concurrently.

go-actions-cache maps that response to an error matching os.ErrExist, but Set and StoreFolderCache wrapped every Save error unconditionally. A benign "this is already cached" response therefore propagated up through storeAssetCache → building assets and failed the command.

Worth noting: the cache store runs after the assets are already built successfully, so this aborted builds that had completed all their real work.

Fix

Treat os.ErrExist as success in both save paths, matching the idiom the upstream library already uses internally (cache.go:451).

To make this testable, the client field becomes a small actionsCacheClient interface covering the two methods used. *actionscache.Cache satisfies it as-is, so NewGitHubActionsCache is unchanged and there is no production behaviour change.

Tests

Four new cases in internal/system/cache_github_actions_test.go, using a fake client that returns the exact error shape the library builds from a v2 already_exists response (HTTPError{409, GithubAPIError{TypeKey: "ArtifactCacheItemAlreadyExistsException"}}):

Test	Asserts
SetIgnoresAlreadyExists	Set swallows already-exists
SetReturnsOtherErrors	Set still propagates real failures
StoreFolderCacheIgnoresAlreadyExists	folder save swallows already-exists
StoreFolderCacheReturnsOtherErrors	folder save still propagates real failures

The negative cases pin down that the guard is narrow and genuine cache failures still fail the build.

Verified the tests actually catch the regression: with the errors.Is guards temporarily removed, both positive tests fail with the same message as the CI log, while the two negative tests keep passing.

go build ./..., the full go test ./... suite, and golangci-lint run ./internal/system/... (0 issues) all pass.

🤖 Generated with Claude Code

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.20%. Comparing base (1561f6d) to head (1384a0a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1302      +/-   ##
==========================================
+ Coverage   54.00%   54.20%   +0.19%     
==========================================
  Files         303      303              
  Lines       23453    23457       +4     
==========================================
+ Hits        12666    12715      +49     
+ Misses      10759    10714      -45     
  Partials       28       28              

Flag	Coverage Δ
go-test	54.20% <100.00%> (+0.19%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.