Upload-artifact: 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 https://github.com/JayFoxRox/GitHub-artifact-URL/issues/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.

[oprypin]

Fun fact: for the API even authenticating is not enough! So, through the API you can't do what you can do through the browser (i.e. with cookies).

This works (assuming logged in):
https://github.com/oprypin/crystal/suites/626035583/artifacts/5010746

This doesn't (using a personal access token for authentication):

$ curl -u "$USER:$PERSONAL_TOKEN" https://api.github.com/repos/oprypin/crystal/actions/artifacts/5010746/zip
{
  "message": "Must have admin rights to Repository.",
  "documentation_url": "https://developer.github.com/v3/actions/artifacts/#download-an-artifact"
}

Which goes directly against the documentation (linked in the response itself!!!):

Anyone with read access to the repository can use this endpoint.

But yes, it does work when I use the API to download from my own repository and only if the token has repo access. And no, my repository isn't private.

[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.

[oprypin]

I have developed a service that lets anyone download an artifact without logging in.
It can also automatically find the currently-latest artifact of any branch.
This is exposed as permanent, shareable URLs, including direct ZIP download URLs.

https://nightly.link/

https://github.com/oprypin/nightly.link

This is implemented a GitHub App, and communication with GitHub is authenticated, but users that only download don't need to deal with that at all.

[keirf]

I just implemented CI/Actions on all my main repositories but I hadn't realised there's a blanket policy to deny public access to artifacts. This seriously cripples the artifact mechanism for some obvious use cases. At least the policy should be modifiable at some granularity via the API??