Is there any way to get the link to the uploaded artifact?

[jaslyn-siliconjungles]

Is there any way to programmatically retrieve the link to download the artifact?

eg. https://github.com/SiliconJungles/app/suites/574454195/artifacts/5483355

When I used CircleCI, I would build an Android APK, retrieve the download link & download token, then post the link onto discord so other members of the team could directly download the APK file without having to open the CI webpage and without having to log in.

Is there any way to achieve this with GitHub Actions?

[joshmgross]

@jaslyn-siliconjungles There is no current way to retrieve this URL via any APIs.

[SaadArdati]

Adding to this, perhaps predictable links like "github.com/user/repo/artifacts/latest"

[JayFoxRox]

If the actions tab wouldn't generate 404 error for anonymous users (why 404 anyway? why not 403?), then one could easily scrape for the latest artifact. It wouldn't be ideal, but an okay workaround.

There is no current way to retrieve this URL via any APIs.

@joshmgross Are there any plans to support this in the near future? This is blocking migration to GitHub Actions for us.

We'd like to avoid setting up GitHub Releases for nightly builds (which we'd like to reserve for stable builds + we don't want the additional administrative overhead).
Our web-frontend used to link to AppVeyor / Travis artifacts (in the style of /master/latest/release-build.zip); this is not possible for GitHub artifacts and would require hacks in our CI scripts or website code.

[joshmgross]

@JayFoxRox Yes, we are working on a full public API for Actions to support this and other scenarios.

[JayFoxRox]

Any update on this? ETA?

[joshmgross]

@JayFoxRox No ETA at this time. We're still actively working on these APIs.

[its-dibo]

- uses: actions/upload-artifact@master
  with:
    name: my-artifact
    path: path/to/artifact
   target: my-artifact 

target: refers to the target path for uploaded artifacts (by default target = name)
so the link is available at /$branch/artifacts/$target

[PLBegay]

Target does not seem to work with me. My workflow can be found here, with upload-artifact at the end. When I push anything to the "PLBegay-auto-pdf" branch, the workflows goes fine and I do get the correct artifact in the GUI, but https://github.com/PLBegay/BFTAL_sym/tree/PLBegay-auto-pdf/artifacts/poly leads to a 404 error. Am I missing something?

[joshmgross]

@PLBegay I believe @eng-dibo was making a feature suggestion, as there's no target input that we support

[joshmgross]

The Actions API has just been released, and this can be used to retrieve an artifact download URL.

See https://developer.github.com/v3/actions/artifacts/

[JayFoxRox]

This actually still didn't do what we needed (also see response by @SwissCheese5 in this thread), so I had to write a script to do this: https://github.com/JayFoxRox/GitHub-artifact-URL

This small HTTP server will make it possible to redirect to the latest artifact URL. Pull requests and issues welcome!

If anyone could host a public version of this, that would be appreciated.

[joshmgross]

@JayFoxRox This issue was tracking a way to get a link to an uploaded artifact. If you want some way to fetch the latest artifact, please file a new issue.

[JayFoxRox]

I'll add that the new API might not even deliver what @jaslyn-siliconjungles asked for, due to #51. So even if the API is used to fetch the URL, that URL might not work for all "members of the team" because "without having to log in" is currently no longer true - they'll at least need a GitHub account (at the moment).

The new API design does also not appear to be able to provide what the issue description asks for. According to the documentation:

Gets a redirect URL to download an archive for a repository. This URL expires after 1 minute.

This is probably not useful for a post in a Discord chat.

[joshmgross]

👋 Hey @JayFoxRox,

Depending on your use-case (such as distributing some zip or build artifact), you might be better off creating a GitHub Release and uploading any assets to that.

See https://github.com/actions/create-release and https://github.com/actions/upload-release-asset

[JayFoxRox]

(I feel like we are going off-topic. Ideally this discussion would take place on #51)

We (and by we, I mean a handful of projects I'm involved with) have always decided against GitHub Releases for nightly builds for a couple of reasons:

• The need for tags leads to daily tag spam in the repository which makes it harder to find actual tags.
• Daily notification spam for followers whenever a tag / release is created.
• Long retention when only short retention is necessary (which pushes people towards latest release; especially with Specify shorter artifact retention time #49 implemented; also note the same motivation as ours).
• Drains actual releases in the releases tab.

For some projects we did want longer retention and we have set up a bot which synchronizes to a nightly build repository (to isolate temporary GitHub Releases and tags), which also has another README (so people don't try to send PRs). However, that feels like a hack and has a lot of maintenance overhead (maintaining the bot for example).

For most projects we just used AppVeyor CI or Travis CI and used the artifact URLs for providing builds between major releases (major releases were still made via GitHub Releases). The artifact URLs were either fetched by anonymous APIs (client typically written in js) or we linked the "latest-URL" directly.

For some projects we have migrated to GitHub Actions under the assumption that artifacts would work as on those other platforms. However, the situation has gone from bad (manually copy artifact URLs for each release) to worse (API works, but now URLs no longer work for end-users). We had hoped that issue #27 (or similar) would resolve all of those issues to finish migration.

We had also considered GitHub Actions and pushing to bintray or something, but it feels really hacky (and additional administrative overhead) because GitHub artifacts sound exactly like what we'd need. - it just needs to open links to the public again (and ideally also have a latest-url or provide an anonymous API for easier integration of a generic download proxy without leaking some oauth token).

Likewise GitHub Releases would work for us if it didn't depend on tags and allowed easier pushing to another repository. However, those are probably issues for another repository or the community forums.

[oprypin]

I have launched a service that exposes predictable URLs to either the latest or a particular artifact of a repository's branch+workflow.

https://nightly.link/

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

This is implemented as a GitHub App, and communication with GitHub is authenticated, but users that only download don't need to even log in to GitHub.

[perumatx]

if you havent got it still , we have to form the URL ending with the run ID . you can get the run ID using ${{ github.run_id }} and pass it to the URL

https://github.com///actions/runs/<run_id>

[alexbakker]

In case anyone's interested in something self-hostable as a solution in the mean time: I wrote a very simple caching proxy service for artifacts: https://github.com/alexbakker/github-artifact-proxy. After some configuration, it can serve the contents of artifact ZIP files, given a workflow run ID (or "latest").

This allows you to directly link to binaries, coverage reports, badges or anything else you generate and upload as an artifact. Works best for fairly small artifacts (couple of megabytes), because the proxy has to download and extract the ZIP file first, before it can serve the contents.

[Yarden-zamir]

This issue is still relavent for many usecases. Here is mine. I have a system test that when done, uploads log artifacts for each test in a matrix. The job after that, sends notifications to slack channels with relavent summery, I want to link each relavent log in the summery and see it akin to https://raw.githubusercontent.com/octocat/Hello-World/master/README. This is currently not possible and I have to upload the logs to a different place if I want to link them.

[iseki0]

The Actions API has just been released, and this can be used to retrieve an artifact download URL.

See https://developer.github.com/v3/actions/artifacts/

Is the API available during workflow running? I upload artifacts and call the API in another job, but it returns an empty artifact list.

I want to make a request let my own server download artifacts. I can't push the artifacts directly.

[sammcj]

I see this is available as a raw API call - why isn't it exposed to github workflow runs / a standard human reachable URL?

[DonaldFoss-VVV]

The Actions API has just been released, and this can be used to retrieve an artifact download URL.
See https://developer.github.com/v3/actions/artifacts/

Is the API available during workflow running? I upload artifacts and call the API in another job, but it returns an empty artifact list.

I want to make a request let my own server download artifacts. I can't push the artifacts directly.

I'm having this same issue. I read somewhere that the uploaded artifact doesn't get resolved and assigned an id until the job completes, but I can't find the link to that discussion.

[lhunath]

Rather than all of this relying on externals, and trying to look up the result of /this/ action, would it not make a lot more sense for /this/ action to provide a link to /its direct/ artifact, such as by adding it to the outputs/environment?

Any independent solutions, even actions/artifacts create a disconnect between this action and the artifact that will be obtained, creating room for issues such as the artifact not being available yet, having been replaced, the lookup resulting in duplicates, mistaking artifacts for other artfacts, etc. etc.

Just return the result of the operation in this action. This issue ought to be re-opened, because it was never solved. It was just delegated with side-effects.

What do you think @joshmgross?

[TWiStErRob]

Heads up: #50 (comment)