@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.
https://github.com/actions/upload-artifact/issues/27#issuecomment-578993712
Hey there! I am opening a new issue as requested by @joshmgross. It would be incredibly helpful to have some way to fetch the latest version of an artifact.
For example, in my use case, I am using LaTeX for my resume and GitHub Actions to compile and create the PDF. It would be incredibly helpful to have a URL that fetches the most recent version. As mentioned in that thread, there is a workaround by pushing it to a release, which I will be using in the meantime but this would be a much more elegant solution.
Thanks!
An artifact is not a release and should not be used as such, as it is strongly bound to the context of the workflow in which it was produced.
For releases GitHub offers "Releases" and/or "Packages", depending on your needs. Both have their own actions and I think you will have a much easier time publish your pdf file that way.
An artifact is not a release and should not be used as such, as it is strongly bound to the context of the workflow in which it was produced.
For releases GitHub offers "Releases" and/or "Packages", depending on your needs. Both have their own actions and I think you will have a much easier time publish your pdf file that way.
Releases require tags, which can become messy. If AppVeyor can provide this basic feature I don't see why GitHub Actions can't.
We (ispc project) need a link to the latest build on our README page. It seems to be pretty common usage pattern. This feature is the main reason we keep using Appveyor.
Would be good if upload-artifact, would support aliases like this:
- name: Upload package
uses: actions/upload-artifact@v2
with:
name: my_build
job_alias: latest <-- note this
path: my_build.tar.xz
So the result would be available as https://github.com/user/repo/suites/latest/artifacts/my_build.tar.xz. It would also require changing file name in this link from a numeric (like it's now something like 12877777) to my_build.tar.xz or my_build.zip, but I hope it's not that hard to implement.
Even if job_alias worked, you'd be blocked by https://github.com/actions/upload-artifact/issues/51 - the README link would only work for logged in GitHub users (which is not suitable for most public projects).
Also if each job created an alias like that, it would likely need some UI to manage existing aliases (that you amass over time). So I feel like it should be implemented differently.
@JayFoxRox Thanks for point out to #51.
I agree, implementation will be more complex than it appears.
But the use case for downloading the latest (or latest successful) build artifact is very widespread use case. I hope Github Actions team will consider it important enough to support it one or other way.
Most helpful comment
@JayFoxRox Thanks for point out to #51.
I agree, implementation will be more complex than it appears.
But the use case for downloading the latest (or latest successful) build artifact is very widespread use case. I hope Github Actions team will consider it important enough to support it one or other way.