upload-artifact
upload-artifact copied to clipboard
actions
Display files in browser where appropriate.
It would be nice to open html files in the browser instead of having to download and up zip the file. CircleCi does this. This is useful for test results or lint results and other types of reports.
We'd love to be able to access images directly in the browser without having to download+extract the ZIP.
To add to the mimetypes, I have PDF artifacts, and it would also be nice if they simply opened in an appropriate viewer.
I'm also looking for this feature so that we can fully deprecate and replace our dependency on CircleCI. We generate Sphinx pages (html, css, js), and CircleCI gives us a link to view these directly from the CI results page. This is an important piece of functionality for some of our projects.
Is this on someone's roadmap with an ETA, or is this something that I can help with implementing on top of the v2-preview action?
It would be very nice if someone with typescript experience can implement that as v2 is out finally!
Chiming in now that v2 is released. The zip file that you see is a GitHub UI limitation. Files get uploaded individually one by one. The zip that you see only gets generated when you click to download the artifact from the UI (we don't have anything in the UI to let you browse artifact files and consequently download them) The zip currently gets created so you can get all the contents of your artifact with a single download. So we have some work to do on our end that is independent of how the artifact gets uploaded.
Please be aware that we have plans to significantly enhance the UI so you can browse and download files individually (and consequently open files in the browser such as PDFs and HTML documents). No ETA, but we'll share information for sure once things start coming up.
Even if the UI is not there yet, is it possible to obtain a separate artifact file by some tailored URL? If not, could it perhaps be implemented as a first step?
seems more like a bug if you upload an artifact of a .zip file for it to just then be rezipped as an artifact. Artifact uploads should be able to be referenced via URL and viewed within the UI without having to unzip for an individual file that was pushed ie .html, .jpg etc
Any progress on this? Would love an update since the last comment 6mos ago.
Even if the UI is not there yet, is it possible to obtain a separate artifact file by some tailored URL? If not, could it perhaps be implemented as a first step?
This would be useful alright, as at least I can, for example modify my Slack message on failure to go straight to the HTML page that contains test results.
Personally, I don't really need a way to browse to it from the UI (or at least it's much lower priority) if I have a way to link to them directly by knowing the pattern of URLs to files.
Another stopgap that might be useful is providing direct access to a file if it's the only one in the artifact.
+1. Would be cool if you could render an uploaded markdown file directly (test reports, etc.)
+1. Really looking forward to have something to achieve this. Looks like downloading the artifacts in zip is the only way for now.
We ended up just throwing everything on a new netlify site and having a shared password
From: Zahid @.> Sent: Wednesday, January 12, 2022 8:42:00 AM To: actions/upload-artifact @.> Cc: Joshua @.>; Manual @.> Subject: Re: [actions/upload-artifact] Display files in browser where appropriate. (#14)
+1. Really looking forward to have something to achieve this. Looks like downloading the artifacts in zip is the only way for now.
— Reply to this email directly, view it on GitHubhttps://github.com/actions/upload-artifact/issues/14#issuecomment-1010779609, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAWCQNKILPHJFOX7MPZXYGLUVU5FRANCNFSM4IWLX3CA. You are receiving this because you are subscribed to this thread.Message ID: @.***>
The zip that you see only gets generated when you click to download the artifact from the UI (we don't have anything in the UI to let you browse artifact files and consequently download them) — https://github.com/actions/upload-artifact/issues/14#issuecomment-620728238
For me, it is not that important that I can browse the content of an artifact. It might be useful from time to time, but I might still download the ZIP in such cases. As an alternative solution, the workflow could add a reference to the “main file” as meta information to the artifact. (This could just be a special file with a specific name in the artifact, which contains the name of the main file.) When this information is present, the UI could directly open the file referenced in the meta information instead of downloading the ZIP. Such implementation seems simpler to implement (no file browser) and might actually provide a more streamlined experience for the users.
Note: While this wouldn't require a UI to browse the content of the Artifact, we would obviously still need endpoints for each file in the Artifact.
Related: https://github.com/github/roadmap/issues/470 (was planned for Q1) should provide the “main file” functionality @JojOatXGME mentions. No mention yet of an ability to link directly from this main output file to specific artifact files, but at least it will be easier to write specific human-friendly instructions about how to find these.
Related: github/roadmap#470 (was planned for Q1) should provide the “main file” functionality @JojOatXGME mentions.
I meant a “main file” per artifact within the artifact. For example, when I create a HTML test report, I could declare the index.html of that report as the main file. The index.html would then have all the necessary navigation. So GitHub wouldn't need to implement its own navigation (i.e. browse functionality) for the Artifacts, since these HTML files usually already have a navigation specifically crafted for their use case. However, we would still need endpoints for the individual files within the artifacts. In my experience, many tools already support the generation of such HTML report.
https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/ ✅
https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/ ✅
It is a cool functionality but it is not a resolution for this issue. It is not possible to view arbitrary html artifacts which is still useful for things like previewing docs or per-line test coverage reports.
github.blog/2022-05-09-supercharging-github-actions-with-job-summaries :white_check_mark:
That's cool. But I doubt if it is still limited by the 65536-character length limit. If so, it can even not take the place of displaying HTML directly even if appropriate conversion is performed, not to mention displaying files.
I guess the only thing that is still missing are endpoints to directly access files within artifacts.
e.g. https://github.com/<user>/<repo>/suites/<id>/artifacts/<artifact_id>/files/<relative_path>
If there were such endpoints, we could manually add links to the job summary which point to such HTML reports.
EDIT: As mentioned by alexec in the next comment, using github.com as the domain would allow XSS attacks. So the feature should probably use githubusercontent.com as domain instead.
The markdown is a good start. I get why they did it. Allowing arbitrary HTML in a brower results a Github Action being able to XSS github.com. They would need to be displayed on another domain name. Markdown is easy to sanitize and display safely.
Markdown, is limited. No CSS means pages that can't look correct. Lack of images mean you can't show charts. What about more complex reports with many pages.
Markdown is meant to be single-page, and you can always show multiple reports in <details> and <summary> tags. Also you can link external images. I feel like this is a great compromise and will have 80% of use cases covered.
main.py ❌
Failed in line ... with status ...
Markdown is meant to be single-page, and you can always show multiple reports in
<details>and<summary>tags. Also you can link external images. I feel like this is a great compromise and will have 80% of use cases covered.
I agree with this. I bet markdown fits many use cases.
Markdown is meant to be single-page, and you can always show multiple reports in
<details>and<summary>tags. Also you can link external images. I feel like this is a great compromise and will have 80% of use cases covered.
In 80% within your 80% use cases, why not just make the workflow leave a comment elsewhere :) Only when leaving a comment elsewhere impracticable, then we need an arbitrary HTML. In such a case, are there really 80% use cases covered? Not to mention converting HTML to GitHub flavored Markdown is not easy work.
Your example is typically nothing. You see, in most cases, the test report is automatically generated and not compatible with GitHub flavored Markdown. This feature is mostly not for unit-test reports, but just for some additional conclusions after the test job. Not so practical, IMO. If you say a solution covers a use case, it should at least comes with necessary ease, otherwise, it is just a workaround.
I've come up with a workaround for this issue that abuses github pages to serve build artifacts. It's far from ideal, but it beats downloading zips.
The gist is that you configure a github pages branch, and then add a job to the workflow that downloads the artifact zip into that branch and runs a script that ingests the downloaded files, e.g.:
- Moves the new content to a timestamped directory for permalinking
- handles retention period - delete old content
- symlink to latest content
- generate index for all content
- emits markdown into $GITHUB_STEP_SUMMARY for the ingested content
The job then commits the changes to the branch, whereupon on the normal pages automation is provoked to serve the new content.
For example:
2 years later: this comment offers an approach with a different set of tradeoffs
@therealryan I thought of your solution as well.
Another approach would be to use codesandbox to do all that dynamically and serve the content over HTML.
I presume it would need a public access token.
Though, if it would be possible to access files directly, one could upload a index.html file that serves the content of the artifact. That seems simplest.
We currently add an index file so at least it is simple to view the artifact after downloading and unzipping.
+1 for being able to directly access my index.html for my code coverage report in the artifact withour having to download zip file.
I could then add PR comment directly to the index to show the report for code reviewers.
