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.

[rcoppy]

(edited for emphasis, re @oprypin:)
Hello! As of January 2022 trying to download an artifact via a URL of the format:
https://api.github.com/repos/{user}/{repo}/actions/artifacts/{run_id}/zip

still, two years since this issue's opening, results in the error: "You must have the actions scope to download artifacts."

Having this link be publicly accessible would be the simplest way to distribute nightly builds to my team.

Having read through this and all the related open issues, github has never commented on or officially documented this feature disparity with other CI/CD solutions. I would transition to a different solution, but am on a deadline.

[oprypin]

You're saying "As of January 2022" like it's something new. But it's always been that way. Check for alternatives above in the thread.

[rcoppy]

You're saying "As of January 2022" like it's something new. But it's always been that way. Check for alternatives above in the thread.

Have updated my original comment; my point is it seems a lot of people feel it shouldn't be this way. nightly.link is a wonderful service but it's still ultimately a middleman adding complexity.

[Baklap4]

Any idea when this gets implemented?

[c3rb3ru5d3d53c]

bump?

[JJTech0130]

Bump? It's been 2 3/4 years since this issue was opened, and I still don't understand what GitHub expects us to do for nightly builds. https://nightly.link/ works great (thanks @oprypin), but it's an additional service I have to configure, and adds another middleman. Can someone at GitHub at least give us a statement, and what we are supposed to do?

[MCOfficer]

It's effort on the project's part, but one workaround is to publish artifacts to a nightly tag and update it with every CI run. See for example Endless Sky, AppImageKit

[JJTech0130]

See, the problem I have (for my project) is that I don't just have one nightly build- I want to have builds of every commit.
I'm trying use Swift packages for a Rust project, so I have an action that builds it, uploads it with nightly.link, and then generates a manifest with the URL and hash, which is then committed to swift/originalbranchname. So you can put swift/originalbranchname into Xcode, and it works.

[Slackadays]

Any progress regarding this? nightly.link is an absolute hack and we shouldn't need to use it so that users can get the latest software.

[ghost]

This is still a problem in 2023.

[troglobit]

Here's an alternative that works:

1. Use Releases, create a latest release in your repository (tag + description)
2. Add an upload/release/nightly job to your workflow
3. Use pyTooling/Actions/releaser@main to upload your artifact to the latest tag

Example here: https://github.com/kernelkit/infix/blob/main/.github/workflows/build.yml

For every build your latest release is updated with artifacts from the latest build. The tag will remain where you created it, so slightly confusing, but works and will always be at the top of your Releases listing. Good luck!