mansagroup / gcs-cache-action Goto Github PK

Feature Request

Is your feature request related to a problem? Please describe.

Current logs do not describe how long individual steps are taking.

Describe the solution you'd like

It would be nice if the logs said how long each step took, e.g.

🔍 Searching the best cache archive available (25 seconds)
🌐 Downloading cache archive from bucket (40 seconds)
🗜️ Extracting cache archive (20 seconds)

Teachability, Documentation, Adoption, Migration Strategy

What is the motivation/use case for changing the behavior?

With this information I could seek for opportunities to optimize the process.

Here is how we have it setup:

- uses: actions/setup-node@v2
  with:
    node-version: '16'
- name: Cache node_modules
  id: node-modules-cache
  uses: mansagroup/[email protected]
  with:
    bucket: github-action-runner-cache
    path: node_modules
    key: node_modules-${{ hashFiles('**/yarn.lock') }}
    restore-keys: node_modules-${{ hashFiles('**/yarn.lock') }}

Here is how it fails:

Github runners on Ubuntu 20.04 are prepackaged with zstd v1.5.5 at the time of this writing. The command output of zstd --version has changed and it doesn't quite match the string that this action relies on (see here). As a result, zstd is assumed to be absent and slower gzip is used instead.

Please update the check to detect the presence of zstd.

Bug Report

The gcs-cache-action currently behaves slightly differently than the regular github actions/cache action. According to https://github.com/marketplace/actions/cache#outputs, the cache-hit output only returns true on an exact match hit. I would expect gcs-cache-action to behave the same, but it is currently returning true on exact and partial matches.

Current behavior

gcs-cache-action is returning cache-hit=true on exact and partial matches.

Expected behavior

gcs-cache-action should only return cache-hit=true on exact matches like actions/cache does. Partial matches should return cache-hit=false

Possible Solution

https://github.com/MansaGroup/gcs-cache-action/blob/main/src/main.ts#L169

Should be:

core.setOutput('cache-hit', bestMatchKind=='exact');

instead of

core.setOutput('cache-hit', 'true');

Others:

At the moment, if post action fails, it makes the entire workflow fail too.

While I am unsure what is causing these failures, they are happening often enough for this to be a problem.

Bug Report

Current behavior

In the README example show a v2 version this action, but there is no v2 release

Expected behavior

Should be v2 version or just stick with v1

Bug Report

Current behavior

/usr/bin/tar -x --use-compress-program zstd -d -P -f /tmp/tmp-195888-ch6Z2OTlm0qa -C /home/github/actions-runner/_work/foo/foo
  /*stdin*\ : Decoding error (36) : Frame requires too much memory for decoding 
  /*stdin*\ : Window size larger than maximum : 1073741824 > 1342[17](https://github.com/gajus/foo/runs/5548683535?check_suite_focus=true#step:9:17)728 
  /*stdin*\ : Use --long=30 or --memory=1024MB 
  /usr/bin/tar: Child returned status 1
  /usr/bin/tar: Error is not recoverable: exiting now

Expected behavior

Compress file.

Possible Solution

Use --long=30 or --memory=1024MB