Archive the cached dir relative, not by its absolute path

Each run gets a fresh per-run workspace (~/.cache/act/<hash>/hostexecutor),
so embedding the absolute path meant the next run restored into a stale
workspace and the cache never actually sped up a build. Save with
-C <parent> <basename> so entries are <basename>/... and restores can
extract into the run's own path input location.

README.md

@@ -23,6 +23,9 @@ A Gitea Action that caches build files as `tar.xz` archives on the runner filesy
 2. Stores archives at `~/.cache/.cache-store/<key>.tar.xz`
 3. Restores by extracting the archive to `/`, saves by creating one
 4. Saves atomically (write to `<key>.tar.xz.tmp`, then rename)
+5. Archives store the cached directory **relative** (`<basename>/...`), not its
+   absolute path — a later run restores into its own `path` location, so the
+   cache works across runs even though each run gets a fresh workspace
 
 ## Cache Retention
 

action.yaml

@@ -37,9 +37,13 @@ runs:
         fi
 
         echo "Saving cache: ${CACHE_KEY}"
-        REL_PATH="$(echo "$EXPANDED_PATH" | sed 's|^/||')"
+        # Archive only the directory itself (entries: <basename>/...), not its
+        # absolute path, so a later run can restore it into its own (per-run)
+        # workspace location. Restores use the same `path` input to find it.
+        PARENT="$(dirname "$EXPANDED_PATH")"
+        BASE="$(basename "$EXPANDED_PATH")"
         TMP_ARCHIVE="${ARCHIVE}.tmp"
-        if tar -cJf "$TMP_ARCHIVE" -C "/" "$REL_PATH" 2>/dev/null && mv -f "$TMP_ARCHIVE" "$ARCHIVE"; then
+        if tar -cJf "$TMP_ARCHIVE" -C "$PARENT" "$BASE" 2>/dev/null && mv -f "$TMP_ARCHIVE" "$ARCHIVE"; then
           echo "Cache saved"
         else
           rm -f "$TMP_ARCHIVE"