Skip to content

Add gh run download option to skip unpacking zip files #12435

Open

Description

@iTrooz

Describe the feature or problem you’d like to solve

Sometimes, uploaded artifacts are folders containing a lot of files. This doesn't cause problems since the files are zipped automatically, and the zip can be downloaded from the Github website.
I would like the github CLI to have the feature to download the artifact zip without extracting it, for cases where you want to use it as a zip

Proposed solution

Add a --skip-unpack flag to the command, which would write the zip file directly instead of extracting it

Additional context

Here is such an usage of programmatic download of the zip file without unzipping it: https://github.com/WerWolv/ImHex/blob/6eedb469e97ba630f75e6e8c2a79b262e85f9043/.github/workflows/release.yml#L111

Activity

  1. github-actions commented on Jan 7, 2026

    @github-actions
    Contributor

    Thank you for your issue! We have categorized it as a feature request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.

    Unless you see the help wanted Contributions welcome label, we are not currently looking for external contributions for this feature.

    If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.

  2. iTrooz commented on Jan 7, 2026

    @iTrooz
    Author

    I will soon submit a PR as an example implementation

  3. babakks commented on Jan 7, 2026

    @babakks
    Member

    Thanks for your feedback, @iTrooz! 🙏

    Important

    According to our contribution guideline, the standard flow for new features is to first discuss them over an issue (here). Once the team decides it's a legit addition, we may mark the issue as help wanted Contributions welcome to accept a PR from community, if the complexity of the changes is within certain limits. So, I'm going to close your PR for now, as an open PR means something that should be reviewed by the team. When we have a clear decision, we may reopen your PR.

    I can see why one would need such an option, and IMHO it's a reasonable addition. But, there are edge cases to this that I need to clarify before taking this into the team's decision making process.

    Please let me know WDYT, @iTrooz.

    1. Name collision (minor, yet worth noting)

    Currently, gh would create multiple subdirs to unzip artifacts, if more than one artifact can be downloaded. In special cases where there are multiple artifacts with the same name (esp. when gh run download is invoked without run ID, which is to cover all runs), extracted files will be mixed, if not overwritten. This can happen because gh does not check for name collisions, and also uses os.MkdirAll (similar to mkdir -p) while extracting files, which will never bail out if the directory chain is already created (probably with files already extracted in it).

    But, with a --skip-unpack flag, artifacts with the same name will overwrite each other.

    I'm not saying the current behaviour is a nice thing, though. One can argue this should at least be a deterministic behaviour (i.e. regardless of any orderings in raw data), but that's one separate discussion. 🫤

    2. Interactive UX

    Do we want to have this new option available as part of the interactive flow as well? I mean, when a user runs gh run download, they'll see a list of available artifacts to download. Do we want to add a new question/prompt to let them enable --skip-unpack?

    IMHO, we might not need it, at least for starter. I'm assuming your use case is purely non-interactive.

  4. iTrooz commented on Jan 7, 2026

    @iTrooz
    Author

    Hello !
    No problem, I just made the PR to get more insight about potential blockers and because it was quick, I knew it wouldn't be accepted (directly)

    1. I think Github does not allow multiple artifacts with the same name to co-exist: https://github.com/actions/upload-artifact/blob/b7c566a772e6b6bfb58ed0dc250532a479d7789f/action.yml#L40. I get a 409 error when trying to re-upload an artifact with the same name. Did I understand something wrong ?

    2. I don't think it is needed as yes, my use case is non-interactive, and the interaction flow seem to be about simplifying common needs (Which I don't think mine is ?)

  5. iTrooz commented on Jan 9, 2026

    @iTrooz
    Author

    Oops, re-reading your comment I realized what you meant, we can download the same artifact name from multiple workflows at the same time.
    I think that when downloading the same artifact name from multiple workflows, the run ID should be appended to the file/directory created, but that should probably be discussed/implemented as a separate feature to this, yeah

    Also, I wasn't able to download artifacts from multiple workflows at the same time, even when using commands provided in gh run download --help

    For example, GH_DEBUG=1 gh --repo iTrooz/ImHex run download -n "macOS DMG arm64" will only download one artifact, I think this is because of https://github.com/iTrooz/cli/blob/e7b6f9908795ddbf3eab70c2596556a8203343bb/pkg/cmd/run/download/download.go#L161

    I'd be ready to submit a PR to fix that behaviour after this feature is merged

  6. iTrooz commented on Jan 20, 2026

    @iTrooz
    Author

    @babakks Hello ! Anything new from your side ? Do you need more user/team input ?

  7. babakks commented on Feb 19, 2026

    @babakks
    Member

    Hi @iTrooz, thanks for the heads up! 🙏

    I'm not very happy about appending IDs/numbers to file names as it can be a source of confusion to users, especially automations.

    Regarding the addition of the --skip-unpack, we need to discuss this internally, and I'll keep you posted.

  8. Hillshum commented on Mar 1, 2026

    @Hillshum

    I'll add that this feels even more relevant now that standalone files can be uploaded as artifacts. I've got a case where I've got a Python wheel file as an artifact. While that wheel is a zip file under the hood, I don't ever want to unzip that directly.

  9. NSPC911 commented on Apr 14, 2026

    @NSPC911

    Came here after this incident

    ╰─❯ gh run download
    ? Select artifacts to download: report.xml
    error downloading report.xml: error extracting zip archive: zip: not a valid zip file
    

    This would definitely be beneficial, at least make it skip if it cannot unpack the archive.

  10. iTrooz commented on Apr 15, 2026

    @iTrooz
    Author

    @babakks Hello ! Any news for this ? I'd love to submit a PR

  11. dkfellows commented on Jun 8, 2026

    @dkfellows

    Surely the "what to do if there's a name conflict" is essentially the same problem you'd have if a file or files extracted from the downloaded ZIP collides with an existing file. There's a potential for collision in both cases.

    (My use case for this is downloading builds of binaries to deploy to a machine — a development board for custom hardware in my case — that doesn't have direct access to the internet, let alone a Github token for reaching the actions of the private repository where I'm working. I just want the ZIP so that I can transfer it to where it's really going to be unpacked, and it's surprising that gh run download doesn't make it easy.)

  12. iTrooz commented on Jun 8, 2026

    @iTrooz
    Author

    Yeah, that's a bit problematic
    I feel like it would be useful to create a custom script to query the API directly

  13. iTrooz commented on Oct 29, 2026

    @iTrooz
    Author

    Hi @babakks , any news about this ? I'm ready to add fixup commits to the last PR I submitted concerning this

  14. heaths commented on Nov 2, 2026

    @heaths
    Contributor

    Why not solve this like the actions/download-artifact action does: artifacts are downloaded to a directory with the same name of the artifact so there is no chance of a collision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementa request to improve CLIgh-runrelating to the gh run command

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions