Describe the feature or problem you’d like to solve

A clear and concise description of what the feature or problem is.

Proposed solution

How will it benefit Actions Cache CLI extension and its users?

Additional context

Add any other context like screenshots or mockups are helpful, if applicable.

Describe the bug

gh actions-cache list show Total caches size. It seems not to be updated after gh actions-cache delete.

Steps to reproduce the behavior

$ gh extension install actions/gh-actions-cache 
✓ Installed extension actions/gh-actions-cache
$ gh actions-cache list
Total caches size 319.32 MB

Showing 1 of 1 cache entries in peaceiris/private-repo

setup-go-Linux-go--3b25b2e3990931c5fa648090fe97a4fdaf9b42dba07ace5b62ec0b9b2d4751a3                                                [319.32 MB]     refs/pull/530/merge                       an hour ago        
$ gh actions-cache delete setup-go-Linux-go--3b25b2e3990931c5fa648090fe97a4fdaf9b42dba07ace5b62ec0b9b2d4751a3
You're going to delete 1 cache entry

setup-go-Linux-go--3b25b2e3990931c5fa648090fe97a4fdaf9b42dba07ace5b62ec0b9b2d4751a3                                                [319.32 MB]     refs/pull/530/merge                       an hour ago        

? Are you sure you want to delete the cache entries? Delete

✓ Deleted 1 cache entry with key 'setup-go-Linux-go--3b25b2e3990931c5fa648090fe97a4fdaf9b42dba07ace5b62ec0b9b2d4751a3'
$ gh actions-cache list
Total caches size 319.32 MB

There are no Actions caches currently present in this repo or for the provided filters

Expected vs actual behavior

gh actions-cache list shows the following message after deleting the cache.

Total caches size 0.0 MB

Describe the feature or problem you’d like to solve

The same kind of tool but for artifacts instead of cache

Proposed solution

How will it benefit Actions Cache CLI extension and its users?
Probably will be a new repo, but could be here too I guess.

Describe the bug

Right now, the plugin prints out There are no Actions caches currently present in this repo or for the provided filters when there are no caches.
If you pipe this into another command, there's no differentiation between this and a normal cache entry output. The message should either not be printed or be printed to the error log when in a non-interactive context.

Steps to reproduce the behavior

1. Execute gh actions-cache list -B refs/heads/doesnotexist

Logs

Using the recommended action to delete caches from actions/cache#981 leads to this log

Error: Cache with input key 'There' does not exist
Error: Cache with input key 'are' does not exist
Error: Cache with input key 'no' does not exist
Error: Cache with input key 'Actions' does not exist
Error: Cache with input key 'caches' does not exist
Error: Cache with input key 'currently' does not exist
Error: Cache with input key 'present' does not exist
Error: Cache with input key 'in' does not exist
Error: Cache with input key 'this' does not exist
Error: Cache with input key 'repo' does not exist
Error: Cache with input key 'or' does not exist
Error: Cache with input key 'for' does not exist
Error: Cache with input key 'the' does not exist
Error: Cache with input key 'provided' does not exist
Error: Cache with input key 'filters' does not exist

Describe the bug

When running gh actions-cache list under the root of a private repo I get:

Error: unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host

The origin is set as [email protected]:<user>/<repo>.git for fetch and push

It has come to our notice that even for usage API, the user-agent is getting populated as gh-actions-cache/0.0.1/delete in Splunk query for usage API.

Similarly on checking for list gh-actions-cache/0.0.1/list nothing is getting populated.

The expectation is to have both list and delete user agents in headers corresponding to appropriate queries.

Branch column is show even when user has specified a --branch flag. Should we not show that column to save space?

cc @heyamie

Describe the bug

When invoking gh actions-cache list, upon specifying --branch, the filter only works for specific references. In this case, when specifying master for --branch, the command returns with: There are no Actions caches currently present in this repo or for the provided filters, despite there being caches that have master references. However, with any other reference, the command works as expected.

gh cli version

gh version 2.20.2 (2022-11-15)
https://github.com/cli/cli/releases/tag/v2.20.2

gh extension version

gh actions-cache  actions/gh-actions-cache  v1.0.2

Steps to reproduce the behavior

1. Run gh actions-cache list --branch master in a repository that contains caches for master branch

Expected vs actual behavior

When running command normally in a repository

$ gh actions-cache list --sort last-used --order desc -R  myorg/myrepo
Total caches size 3.36 GB

Showing 5 of 5 cache entries in  myorg/myrepo

Library-XXXX-linuxrunner-unittests-3834242185  665.69 MB  refs/pull/422/merge  17 hours ago
Library-XXXX-linuxrunner-build-3833728933      721.74 MB  master               19 hours ago
Library-XXXX-linuxrunner-build-3833399789      722.02 MB  master               19 hours ago
Library-XXXX-linuxrunner-unittests-3833438332  665.34 MB  refs/pull/393/merge  19 hours ago
Library-XXXX-linuxrunner-unittests-3833399507  665.27 MB  refs/pull/429/merge  20 hours ago

What should happen

$ gh actions-cache list --branch master
Showing 1 of 1 cache entries in myorg/myrepo

Library-XXXX-linuxrunner-build-3833728933      721.74 MB  master               19 hours ago
Library-XXXX-linuxrunner-build-3833399789      722.02 MB  master               19 hours ago

What happens instead

$ gh actions-cache list --branch master
There are no Actions caches currently present in this repo or for the provided filters

When using a different reference

$ gh actions-cache list --branch refs/pull/393/merge
Showing 1 of 1 cache entries in  myorg/myrepo

Library-XXXX-linuxrunner-unittests-3833438332  665.34 MB  refs/pull/393/merge  19 hours ago

Logs

See above output.

Describe the bug

I am unsure if this tool can be used on desktops, but I tried to install the extension on Debian bullseye, and when running an actions cache command, the command fails with the following logs:

$ gh actions-cache list                             
/home/jo/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/jo/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache)
/home/jo/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/jo/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache)

And it seems Debian bullseye have a previous version of glibc:

$ sudo apt-cache policy libc6 libc-bin
libc6:
  Installed: 2.31-13+deb11u5
  Candidate: 2.31-13+deb11u5
  Version table:
 *** 2.31-13+deb11u5 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        500 http://deb.debian.org/debian bullseye-updates/main amd64 Packages
        100 /var/lib/dpkg/status
libc-bin:
  Installed: 2.31-13+deb11u5
  Candidate: 2.31-13+deb11u5
  Version table:
 *** 2.31-13+deb11u5 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        500 http://deb.debian.org/debian bullseye-updates/main amd64 Packages
        100 /var/lib/dpkg/status

Steps to reproduce the behavior

1. Install the extension on Debian bullseye
2. Run gh actions-cache list
3. See error

Expected vs actual behavior

I would expect the extension to work on Debian bullseye.

I just installed gh on Ubuntu 22.04:

$ gh --version
gh version 2.32.1 (2023-07-24)
https://github.com/cli/cli/releases/tag/v2.32.1

I ran the auth login command:

$ gh auth login
? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations? SSH
? Upload your SSH public key to your GitHub account? /home/hakon/.ssh/id_rsa.pub
? Title for your SSH key: GitHub CLI
? How would you like to authenticate GitHub CLI? Login with a web browser
[...]
Opening in existing browser session.
✓ Authentication complete.
- gh config set -h github.com git_protocol ssh
✓ Configured git protocol
✓ SSH key already existed on your GitHub account: /home/hakon/.ssh/id_rsa.pub
✓ Logged in as hakonhagland

I did some short tests, like setting the default repository for my current directory gh repo set-default and verified that I could run gh pr status for example.

Then I installed actions-cache:

$ gh extension install actions/gh-actions-cache
✓ Installed extension actions/gh-actions-cache

$ gh extension list
gh actions-cache  actions/gh-actions-cache  v1.0.3

If I now run actions-cache list I get an error:

$ gh actions-cache list
Error: authentication token not found for host github.com

Error message is not shown in red color

Describe the feature or problem you’d like to solve

While debugging cache it would be of extremely helpful to know what went into the cache, so we would know if the right files are cached and if the cache size did not grow by caching wrong files.

Proposed solution

We need a command to list files from the cache and their size.

Additional context

Describe the feature or problem you’d like to solve

Offer an option to only print the cache entry key

Proposed solution

It will benefit the users as one of the common use case is to list the keys, then to delete them.
In order to execute that step we pipe the output of the command to cut -f 1 which will only select the first column.
gh-action-cache can easily do it using some flags like --output keys which only prints the keys of each cache entry instead of the whole line.

this is how it is advertised on github documentation: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#force-deleting-cache-entries

Additional context

Listing cache entries is very useful, in my case it was for deleting the cache entries, I am sure for most people it is too but possibly the listing is used for other reasons.

If that's open for external contribution I wish to give it a try and propose a pull requests.

Describe the feature or problem you’d like to solve

Thank you for this great extension to the GitHub CLI. Currently the list command is limited to 100 caches (30 by default), which can easily be reached on monorepo PRs (for example a PR that updates dependencies in multiple monorepo components).

Proposed solution

Have the list command paginate over the results, the code is already there 😄

Additional context

As a workaround I could use gh api directly

Describe the feature or problem you’d like to solve

I would like to see all cache's created before or after a certain date.

Proposed solution

add a flag such as:

--age <string> Return caches older than age (1m/2m/1d/2d/xd/1h/6h/xh)

Where the number of months/days/hours is variable and there are options for month/day/hours of age (perhaps minutes)

Additional context

It would benefit users so that we can list old caches and then delete them in a script or understand which branch or branches are aging. This could be combined with a bulk delete operation, as discussed in #20 but would also be useful on the list and delete command.

As I have been configuring cache cleanup jobs, I would like to clean up only caches older than a certain number of days/hours so that branches with high current activity levels do not have their caches deleted unnecessarily. This requires unnecessarily complex pipes to external utilities such as awk/grep etc.

We currently get this type of answer back and need to parse that and cut it down - sometimes it says minutes, hours, or days making it awkward to write a simple script.

gh actions-cache list --order asc --sort last-used -R https://github.com/organization1234/repo8765

Linux-build-cache-node-modules-d627a4016d488c214...  149.00 MB  refs/heads/development  21 hours ago
Linux-build-cache-node-modules-d627a4016d488c214...  149.16 MB  refs/heads/staging      21 hours ago

Describe the bug

Running gh actions-cache list yields correct information about cache size but then immediately outputs 'Error: The given repo does not exist'.

❯ gh --version
gh version 2.8.0 (2022-04-13)
https://github.com/cli/cli/releases/tag/v2.8.0

❯ gh extensions list
gh actions-cache  actions/gh-actions-cache  v1.0.1

Steps to reproduce the behavior

❯ gh actions-cache list                                             
Total caches size 1.69 GB

Error: The given repo does not exist.

This is for a private repo running on Github Enterprise Server.

Describe the feature or problem you’d like to solve

It would be cool to add a flag if we want to delete all cache from a repo or with some filters like older than x, bigger than x, and so on.

Proposed solution

The solution would help to gain time between the list command and the delete command.

Regards :)

If no caches exist in a repo, we still output Showing 0 of 0 cache entries. Seems redundant.

Can we replace with a more friendly text - like There are not Actions caches being used in this repo

cc @heyamie

delete will fail if the passed --key isn't found

delete --ignore-not-found could still succeed if there isn't a matched key, this would be useful in situations where we only want to make sure a given --key doesn't exist, instead of first parsing list before running a delete

The below mentioned three instances of code can be reused by creating a separate function for handling error from api responses.

list.go

delete.go

Describe the feature or problem you’d like to solve

We had a weird Maven failure in GHA that I suspected was due to a corrupted cache. I wanted to delete all of the caches for Maven. Doing this was more work than expected, since I had to write a shell loop to list the cache keys, parse out the key, then call delete.

Proposed solution

Adding an option to delete multiple keys would be helpful:

gh actions-cache delete --glob 'setup-java-Linux-maven-*'

Or even adding a --all flag to delete everything.

Describe the feature or problem you’d like to solve

Return a list of caches not associated to a branch or branches specified by the user.

Proposed solution

-x <string> Exclude branches from result set

ex:
gh actions-cache list --order asc --sort last-used -x staging,development,main

this would return all caches except those on the 3 branches staging,development,main

This would allow a user to find all non-critical branch caches and clean them up. Combined with a date filter, as requested in #51 would make cache query and cleanup more flexible. This new flag could be specified in conjunction with either the list or delete commands.

CLI Feedback

What have you loved?

It's an easy-to-read list view.

Thanks to the easy-to-read list, I was able to find a mistake in the cache key I set.
https://github.com/hankei6km/xquo/pull/24/files

What was confusing or gave you pause?

delete command requires full-length key to delete the cache.

$ gh actions-cache delete Linux-cargo-test_debug-745cab0288fc37d8864b0178ed01e0dc115354d51702a55b62bc511f28d37ef6
You're going to delete 2 cache entries

Linux-cargo-test_debug-745cab0288fc37d8864b0178ed0... [170.82 MB]     refs/heads/main   a day ago          
Linux-cargo-test_debug-745cab0288fc37d8864b0178ed0... [170.82 MB]     refs/heads/to...  2 days ago         

? Are you sure you want to delete the cache entries?  [Use arrows to move, type to filter]
> Delete
  Cancel

Therefore, I run list command.
However, keys in list are abbreviated in narrow wide terminal.

$ gh actions-cache list --branch topic/fix-wrong-cache-key
Showing 3 of 3 cache entries in hankei6km/xquo

Linux-cargo-test_release_jemalloc-745cab0288fc37d8... [203.50 MB]     refs/heads/to...  2 days ago         
Linux-cargo-test_release-745cab0288fc37d8864b0178e... [136.02 MB]     refs/heads/to...  2 days ago         
Linux-cargo-test_debug-745cab0288fc37d8864b0178ed0... [170.82 MB]     refs/heads/to...  2 days ago  

$ gh actions-cache delete "Linux-cargo-test_debug-745cab0288fc37d8864b0178ed0..."
Error: Cache with input key 'Linux-cargo-test_debug-745cab0288fc37d8864b0178ed0...' does not exist

$ gh actions-cache delete "Linux-cargo-test_debug-745cab0288fc37d8864b0178ed0"
Error: Cache with input key 'Linux-cargo-test_debug-745cab0288fc37d8864b0178ed0' does not exist

$ gh actions-cache delete "Linux-cargo-test_debug"
Error: Cache with input key 'Linux-cargo-test_debug' does not exist

I couldn't find a way to always display the full-length keys in list command.

The full-length key can be displayed by using the API, but it is inconvenient.

$ gh api -H "Accept: application/vnd.github+json" "/repos/{owner}/{repo}/actions/caches?ref=refs/heads/topic/fix-wrong-cache-key" --jq ".actions_caches[] | {id, key}"
{"id":91,"key":"Linux-cargo-test_release_jemalloc-745cab0288fc37d8864b0178ed01e0dc115354d51702a55b62bc511f28d37ef6"}
{"id":89,"key":"Linux-cargo-test_release-745cab0288fc37d8864b0178ed01e0dc115354d51702a55b62bc511f28d37ef6"}
{"id":88,"key":"Linux-cargo-test_debug-745cab0288fc37d8864b0178ed01e0dc115354d51702a55b62bc511f28d37ef6"}

This extension currently uses the go-gh module's CurrentRepository function to determine the current repo. This function returns the first element of the list returned by the git.Remotes() internal function, which sorts remotes such that upstream precedes github, which precedes origin. As such, if an upstream remote is present, this extension's default behavior is to return its caches, and the user must add --repo <owner>/<name> to select their fork's caches.

Maybe it's worthwhile to clarify this in the readme? A user might for instance run gh repo view and select their own fork in the interactive prompt, corresponding to remote origin, then assume the CLI will propagate that choice down to any extensions.

Reproduction steps:

1. Create a Github workflow with a job running on ubuntu-latest
2. Install the gh-actions-cache as a step in this job
3. Executegh actions-cache list

Expected behavior: My caches are listed.

Actual behavior:

/home/runner/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/runner/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache)
/home/runner/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/runner/.local/share/gh/extensions/gh-actions-cache/gh-actions-cache)

Workaround:

I changed my job to use the ubuntu-22.04 runner explicitly, and the problem resolved. It does seem that Github-provided extensions should work on the default runners though.

Commentary:

It looks like Github is updating ubuntu-latest to 22.04 slowly:

https://github.blog/changelog/2022-11-09-github-actions-ubuntu-latest-workflows-will-use-ubuntu-22-04/

My repo has not yet been updated yet, but the gh-actions-cache repo has (see OS info within):

https://github.com/actions/gh-actions-cache/actions/runs/3567634871/jobs/5995563551

I suspect that the change to the glibc required version might be due to v1.0.2 being compiled on 22.04 while v1.01 likely was compiled on 20.04. A blog entry I found (note that I'm not a Go developer and can't evaluate this):

https://utcc.utoronto.ca/~cks/space/blog/programming/GoAndGlibcVersioning

Diagnostics:

I did my best to collect useful information below. However, I'm outside of my areas of expertise here, so please correct me!

v1.0.2 seemingly was compiled to require a newer version (2.3.2/2.3.4) of glibc (for some additional functions?) than was required by v1.0.1. This was problematic for us because the "ubuntu-latest" Github runner image is ubuntu-20.04 which supplies 2.3.1:

https://launchpad.net/ubuntu/focal/+source/glibc

Ubuntu 22.04 supplies version 2.3.5:

https://launchpad.net/ubuntu/jammy/+source/glibc

Output from my dev machine (against v1.0.1):

mybox:~/.local/share/gh/extensions/gh-actions-cache$ objdump -T gh-actions-cache

gh-actions-cache:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
00000000005ea660 g    DF .text  0000000000000063  Base        crosscall2
00000000005ea620 g    DF .text  0000000000000037  Base        _cgo_panic
0000000000464760 g    DF .text  0000000000000019  Base        _cgo_topofstack
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) __errno_location
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) getaddrinfo
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) freeaddrinfo
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) gai_strerror
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) stderr
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) fwrite
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.4) __vfprintf_chk
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) fputc
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) abort
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_mutex_lock
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.2) pthread_cond_wait
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_mutex_unlock
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.4)  __stack_chk_fail
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.2) pthread_cond_broadcast
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_create
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) nanosleep
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_detach
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) strerror
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.4) __fprintf_chk
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) free
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) malloc
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_attr_init
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_attr_getstacksize
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_attr_destroy
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigfillset
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_sigmask
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) mmap
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) munmap
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) setenv
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) unsetenv
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigemptyset
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigaddset
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigaction
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigismember

Output from my dev machine (against 1.0.2):

mybox:~/.local/share/gh/extensions/gh-actions-cache$ objdump -T gh-actions-cache

gh-actions-cache:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
00000000005eac40 g    DF .text  0000000000000063  Base        crosscall2
00000000005eac00 g    DF .text  0000000000000037  Base        _cgo_panic
00000000004647a0 g    DF .text  0000000000000019  Base        _cgo_topofstack
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) __errno_location
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) getaddrinfo
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) freeaddrinfo
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) gai_strerror
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) stderr
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) fwrite
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.4) __vfprintf_chk
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) fputc
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) abort
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_mutex_lock
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.2) pthread_cond_wait
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_mutex_unlock
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.4)  __stack_chk_fail
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.2) pthread_cond_broadcast
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.34) pthread_create
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) nanosleep
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.34) pthread_detach
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) strerror
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.3.4) __fprintf_chk
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) free
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) malloc
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_attr_init
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.34) pthread_attr_getstacksize
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) pthread_attr_destroy
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigfillset
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.32) pthread_sigmask
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) mmap
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) munmap
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) setenv
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) unsetenv
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigemptyset
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigaddset
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigaction
0000000000000000      DO *UND*  0000000000000000 (GLIBC_2.2.5) sigismember

It appears that the version of glibc required for certain function invocations (pthread_create, etc.) increased in v1.0.2.

gh-actions-cache Feedback

The support for "GitHub Enterprise Server" is a bit unclear. On the one side the README of this repository states:

Note: This extension currently supports github.com only, GitHub Enterprise Server is not supported currently.

On the other hand, the release notes of "GitHub Enterprise Server 3.7" states as follows:

GitHub Actions users who use dependency caching to speed up workflows can now use the GitHub CLI to manage the GitHub Actions cache for a repository. To manage caches using the GitHub CLI, install the gh-actions-cache extension. For more information, see the [gh-actions-cache documentation](https://github.com/actions/gh-actions-cache#readme).

Is there maybe an update of the README missing, or is there a missunderstanding on my side in regards to the documentation?

Thanks in advance for your answer!

Describe the bug

Tests don't pass when executed from tarball.

Steps to reproduce the behavior

docker run --rm -it golang:1.20.0-alpine3.17 sh -c 'wget -O- https://github.com/actions/gh-actions-cache/archive/refs/tags/v1.0.3.tar.gz | tar xzvC /tmp && cd /tmp/gh-actions* && go test -v ./...' 2>&1 > result.txt

There are quite some test failures.

Expected vs actual behavior

The tests pass. This is typically the way that package maintainers build/test binaries, so it would be beneficial if tests would pass.

Logs

result.txt

Describe the bug

gh version: gh version 2.15.0 (2022-09-06)
gh extensions list | grep actions-cache: gh actions-cache actions/gh-actions-cache v1.0.1

-L shorthand is not working for the list command

Steps to reproduce the behavior

1. Execute this command gh actions-cache list -R developer-guy/buildg -L 100
2. View the output Error: unknown shorthand flag: 'L' in -L
3. Then run _ gh actions-cache list --help_
4. You will notice that the output says you can use the -L shorthand for the --limit flag.

Expected vs actual behavior

It should accept the -L shorthand for the --limit flag.

Logs

Paste the activity from your command line. Redact if needed.

Describe the feature or problem you’d like to solve

It is good to have an option to delete all cache entries.

Proposed solution

I think passing --all argument is a good solution:

gh actions-cache delete --all

Additional context

None.

Describe the bug

A clear and concise description of what the bug is. Include CLI version by typing gh --version and the extension version gh extensions list | grep actions-cache.

Steps to reproduce the behavior

1. Execute this command '...'
2. View the output '....'
3. See error

Expected vs actual behavior

A clear and concise description of what you expected to happen and what actually happened.

Logs

Paste the activity from your command line. Redact if needed.

I tried to use gh-actions-cache in a Github action.

It failed with:

Error: Resource not accessible by integration.

It's not immediately clear which permission I needed to give to the action so it works.

After consulting the docs at https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions I figured out, I needed to give:

permissions:
  actions: write

but this wasn't documented anywhere explicitly.

Would be great to add this to the README.

Originally posted by @violethaze74 in violethaze74/gh-cli#1

Token storage change in latest release of gh

This is a message from the GitHub CLI team, maintainers of gh, writing to inform you that the most recent release of gh contains changes which may affect your extension. The latest release introduces the feature of storing authentication tokens in the system keyring (encrypted storage) instead of in a plain text file.
The keyrings that are supported are:

• Keychain on macOS

• GNOME Keyring on Linux (Secret Service dbus interface)

• Wincred on Windows

This has huge security benefits for the users of our tool and was one of our oldest outstanding issues. Unfortunately this change has the potential to break extensions that rely on utilizing the users authentication token to work.

In order to have continued compatibility with gh there are some actions you, as an extension author, need to take. These actions will depend on the implementation of your extension.

Extensions built in Go using go-gh:

1. Upgrade your go-gh version to v1.2.1, the latest version.

   • This can be done using go get github.com/cli/[email protected]

2. Verify that in your extension retrieval of the user authentication token is done using the auth.TokenForHost function.

   • If you were previously accessing the authentication token using any other method it will no longer work.
   • Automatic resolution of the authentication token when using the API clients will continue to work without changes.

All other extensions:

1. Verify that in your extension retrieval of the user authentication token is done by shelling out to the gh auth token command.

   • If you were previously accessing the authentication token using the gh config get command, reading the configuration file directly, or any other methods it will no longer work.

As of right now storing the authentication token in the system keyring is an opt-in feature, but in the near future it will be required and at that point if the changes above are not made then your extension will be broken for all users. If you have any questions/concerns about this change please feel free to open a discussion in the gh repo.

Thanks,
The GitHub CLI Team