Support non-zipped artifacts

[xPaw]

Github now supports these: https://github.blog/changelog/2026-02-26-github-actions-now-supports-uploading-and-downloading-non-zipped-artifacts/

Example url: https://nightly.link/ValveResourceFormat/ValveResourceFormat/workflows/build/master/Source2Viewer.exe

it seems that to get a proper way to get a working url is to have .exe.zip, which isn't quite true.

[oprypin]

Oh boy, what a can of worms.

So the downloads do work but just the URL is misleading.
They started to work by themselves, retroactively. Which, maybe I don't even want to support - don't want to take responsibility for redirecting people to directly viewable files - arbitrary executables, images, webpages and anything.

[oprypin]

Then there's the aspect of the API. It doesn't look like anything whatsoever was updated in the API for accessing artifacts.

https://docs.github.com/en/rest/actions/artifacts#download-an-artifact
The only API URL is: https://api.github.com/repos/OWNER/REPO/actions/artifacts/ARTIFACT_ID/zip - the zip part is mandatory!

Consider the output of just listing a run's artifacts:

$ curl -s -H "Authorization: token $GITHUB_TOKEN" 'https://api.github.com/repos/ValveResourceFormat/ValveResourceFormat/actions/runs/22481305216/artifacts' | grep -Ev '"(node_id|size_in_bytes|expired|digest|created_at|updated_at|expires_at|head_sha|head_branch|head_repository_id|repository_id)"'
{
  "total_count": 10,
  "artifacts": [
...
    {
      "id": 5688000425,
      "name": "Source2Viewer.exe",
      "url": "https://api.github.com/repos/ValveResourceFormat/ValveResourceFormat/actions/artifacts/5688000425",
      "archive_download_url": "https://api.github.com/repos/ValveResourceFormat/ValveResourceFormat/actions/artifacts/5688000425/zip",
      "workflow_run": {
        "id": 22481305216,
      }
    },
    {
      "id": 5688001359,
      "name": "cli-windows-x64",
      "url": "https://api.github.com/repos/ValveResourceFormat/ValveResourceFormat/actions/artifacts/5688001359",
      "archive_download_url": "https://api.github.com/repos/ValveResourceFormat/ValveResourceFormat/actions/artifacts/5688001359/zip",
      "workflow_run": {
        "id": 22481305216,
      }
    }
  ]
}

• "Source2Viewer.exe" is a *.exe download
• "cli-windows-x64" is a *.zip download

But they seem to be indistinguishable per the API. Everything is /zip.

The archive_download_url will just redirect you to some obfuscated URL without an extension suffix, which will serve the correct filename only through the response headers. Which, since recently, may or may not actually be zip.

You can observe the "ephemeral direct download link" that is being obtained through the /zip endpoint for:

• https://nightly.link/ValveResourceFormat/ValveResourceFormat/workflows/build/master/cli-linux-arm
• https://nightly.link/ValveResourceFormat/ValveResourceFormat/workflows/build/master/Source2Viewer.exe

All this being said: the ephemeral URL does happen to directly tell you which file extension it's going to be - it has these predictable substrings that are possible to extract:

• 3f47ac1bc1474879ca9518fc805ae3c53cac6c830fb98d41d936c978c18aec5d.zip?rscd=attachment%3B+filename%3D%22cli-linux-arm.zip%22&rsct=application%2Fzip
• d193e3b6a7a63c76dfb6801687aa496d6c1fa65589940aad325b35a125b9a3d3?rscd=attachment%3B+filename%3D%22Source2Viewer.exe%22&rsct=application%2Foctet-stream

It's just that this becomes known only at the very last step in the process, making it hard to reason about. And also undocumented and possibly unstable.

[oprypin]

Sorry, for now I explicitly disabled support for these :(

This is to have time to think about this and so that people don't start to rely on these wrong URLs that happened to work.

[xPaw]

github themselves rely on the content type header (or the url ending with .zip actually) https://github.com/actions/toolkit/blob/85466c0f54d41d862e6e00e9b66e15a0ef70e562/packages/artifact/src/internal/download/download-artifact.ts#L89

[oprypin]

Right, I've just also started to rely on it ending with .zip. I was just saying that this .zip appears only at the very last step of the process - in the ephemeral redirect URL, after leaving the realms of the API and anything documented.

[xPaw]

FWIW, the azure blob urls do have documented parameters: https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#construct-a-user-delegation-sas

Content-Type response header - rsct, but yes this is annoying considering github doesn't actually say they use azure for this.

It would be good if github added the type to the api response.

[MulverineX]

Which, maybe I don't even want to support - don't want to take responsibility for redirecting people to directly viewable files - arbitrary executables, images, webpages and anything.

Hopefully you can reconsider this. A zip is the same thing just obscured, you're still serving the same content. When I saw the announcement I immediately hoped that people could start serving nightly app installers from nightly.link, it would be quite a shame if the improvement is only available for people with a github account

[gitfool]

I'm also hitting this for tar.gz and dmg artifacts. 😕

[jeertmans]

Jumping in with a small suggestion: why not add an optional archive=true parameter to the URL query (similar to how the action now behaves), and only allow downloading non-zipped artifacts if archive=false is explicitly provided?