Artifact download URL only work for registered users (404 for guests)

[JayFoxRox]

We used to copy the URL from https://github.com/actions/upload-artifact#where-does-the-upload-go to our website for nightly builds (which have short retention and frequent updates, and don't warrant a GitHub Releases push).

We intended to replace this with programmable download URLs that have been discussed in many issues on the repositories (either a latest/release.zip or a third party service which asks the Actions API for the latest URL and redirects the user).

This stopped working very recently.

---

Until recently, the actions tab was only viewable for logged in users (confusing 404 HTTP error for guests), but the artifact download URLs were still public (working for logged in users and also guests).

Likewise, when the Actions API was released, API requests worked without any authentication. One could simply query the API for an artifact download URL and redirect the guests to it. - All of that worked without GitHub account and could have worked from JavaScript or a small lightweight webservice which redirects the end-user to the latest artifact download through HTTP redirects (I wrote https://github.com/JayFoxRox/GitHub-artifact-URL for this purpose).

However, within the last days these artifact download URLs were suddenly made private - they only work for registered GitHub users now. Everyone clicking the download button on our website (who isn't logged into GitHub) gets a confusing 404 error for direct artifact download URLs now.

Even my tool to redirect users doesn't work anymore because the Actions API also requires the API client to be authenticated now (also getting a confusing "not found" error otherwise). See JayFoxRox/GitHub-artifact-URL#4 ; even if I implemented authentication now, the download URL (we redirect to) would likely not work for guest users (such as end-users of our software, who don't have a GitHub account).

It really starts to feel like we are working against how GitHub Actions is intended to work (now, and in the future - none of which seems to be documented very well). It is clearly different from any other CI I have ever worked with; because Travis and AppVeyor had public artifact URLs with simple URLs, which could be easily linked from our website (Compare AppVeyor).

The GitHub documentation for artifacts says

Artifacts allow you to share data between jobs in a workflow and store data once that workflow has completed.

The first part is obvious; but the second part is really vague. Who shall access this stored data? Why? - My thinking has been (from experience with other CI systems): to share temporary builds, with users for early-testing ("continuous integration"), without pushing a release.

• Please make GitHub Actions artifact URLs work for guest users. If this is a non-goal, it should be documented.
• Please document how things are supposed to work for real world applications (How to best handle nightly builds - currently neither GitHub Releases or GitHub Actions artifacts seem suitable).

[dagheyman]

This broke our workflow for us as well, used to use this feature to test automated builds in virtual machines where we don't want to login.

[MCOfficer]

@oprypin i've had success with
Authorization: token $PERSONAL_TOKEN

Edit: that works with a personal token with no permissions, for any public repo.

[oprypin]

@MCOfficer I am not able to reproduce your success there. I get the exact same results as with my example (and this doesn't seem to apply to the browser-based URL either).

[MCOfficer]

@oprypin try this:

$ curl -v -H "Authorization: token $SOME_TOKEN_WITHOUT_PERMISSIONS" https://api.github.com/repos/endless-sky/endless-sky/actions/artifacts/5036752/zip

you should get a Location header, among others. I don't have any special permissions to endless-sky/endless-sky, and this works for me.

[oprypin]

OK so it works but the token must have public_repo access.

[digitalcircuit]

It's worthwhile noting other continuous-integration platforms such as AppVeyor allow guests to download artifacts.

Quassel IRC, an open source IRC client, made use of this to allow for non-developers in the community to test new builds and new features, and since moving to GitHub Actions guests can no longer download artifacts.

If GitHub does not want to universally allow guests to download artifacts, an option on a per-repository or per-organization level would sufficiently address this issue.

Note: I am a community contributor to Quassel IRC. I am not speaking officially on behalf of the Quassel project.

[barakugav]

bump?

[Kagami]

Solution similar to proposed by @troglobit

- name: Release nightly
  uses: softprops/action-gh-release@v1
  with:
    prerelease: true
    name: nightly
    tag_name: nightly
    files: file.txt
    fail_on_unmatched_files: true

And instruct your users to download from https://github.com/OWNER/REPO/releases/download/nightly/file.txt
Example here.

That file.txt will be updated on every commit, keeping single pre-release release without cluttering with other releases and latest stable release.

As a bonus it won't disappear if you don't commit for 90 days (as with artifacts).

[psiberfunk]

Gosh this really kinda sucks. Ran into this today and can't believe this hasn't been fixed... Github team... why do we do this and make it hard for users?

@konradpabjan , is this bandwidth limiting or other abuse issue ? Letting users turn it on per-repo at least would be maybe ok ?

[Lenni-builder]

@psiberfunk I don't think that GH will do anything about this and services like nightly.link will be the only alternative sadly.

[mralusw]

I... don't get it. You can maintain a CD pre-release, update it continuously, and the download link works not just for logged-of users, but with plain wget. For example #51 (comment) or: https://github.com/AppImage/type2-runtime/releases/download/continuous/runtime-x86_64

Does this problem actually exist?

[Baklap4]

@mralusw this is for downloading artifacts from the Action Runners. Sure you can attach them to a pre-release.. but that's not wanted in every usecase.

The problem that the artifacts are only downloadable when logged into Github is still an issue.

Try to get the artifact when logged in vs when in Incognito mode: https://github.com/performous/performous/actions/runs/8774492740/artifacts/1433575543

When in incognito mode you'll be presented a 404.

[MCOfficer]

If you want a legit usecase, i'm maintaining a launcher for endless-sky, which allows users to test new features (i.e. download builds of PRs before they are merged). We do maintain a pre-release for the latest master build, but there are also 3 builds (Win/Linux/MacOS) for each of the 156 current open PRs - shoving all those into the release section would be madness.

Sure, we could create an extra repo for the sole purpose of holding hundreds of releases, but at that point we are just monkeypatching together a service that github themselves could - should - provide themselves. So yes, this is an issue.

[Lenni-builder]

I don't think this will ever change, even if a thousand users complain, GitHub is just too big. You could either use a hacky solution like nightly.link which might break at any point in time or use another CI platform (for example a selfhosted one like Jenkins, or you could mirror your repo to GitLab and use their CI maybe)

[Titus-von-Koeller]

For anyone struggling with this issue, I think the approach implemented in this tool solves this pretty well, might be worth giving it a try:

https://github.com/TheAssassin/pyuploadtool

I found about about this after quite extensive research and wanted to leave it here as bread crumb for others to find the short cut :)