List artifacts doesn't work during workflow run

[wchen342]

I tried to retrieve the list of artifacts in a second job using GET /repos/:owner/:repo/actions/runs/:run_id/artifacts after uploading some artifacts by actions/upload-artifact@v1 in the first job, but the artifacts won't show up. The API call will always return { "total_count": 0, "artifacts": [ ] }.
I have the second job depends on the first job.

Is there a solution to this?

[KurtGokhan]

Same for me. I tried to create an action that would delete an artifact created during the run. But artifacts aren't listed until after the run is complete.

[konradpabjan]

Both listing an deleting an artifact with the artifacts API only works after a run is complete so the APIs defined in https://developer.github.com/v3/actions/artifacts/ won't work for your scenario. This is largely due to the fact that we don't mark an artifact as complete until the end of the run.

To accomplish this, we need some lower level support to list/delete artifacts before the run is complete, see:
actions/toolkit#380
actions/toolkit#379

[nealkruis]

This may not be relevant, but is this the same reason artifacts aren't posted on the UI until the entire workflow is complete?

What I don't understand is why artifacts can be downloaded by subsequent jobs, but not through other means. Is there a reason not to mark them complete after each job?

[beikov]

I have the same issue. I'm publishing test failure reports for matrix entries. It's pretty annoying that I can't view the test reports until the workflow is completed. What is the reason for not marking artifacts as complete?

[CreMindES]

It's also an issue when you want to launch another workflow (2) that would use an artifact created in the original workflow (1) run, but since (1) is still executing other steps or jobs, the artifact is not available in the API, although it's uploaded already.

[reuben]

One /can/ technically just call the same internal APIs used by download-artifact but it's hacky and fragile, and the returned URLs only work with the authorization headers that only exist in the Actions context. It also doesn't give you an artifact ID that will be valid later when the artifacts show up in the REST API. You can see some code that does that here: https://github.com/mozilla/DeepSpeech/blob/a6bdf0ae3c190cbaf39dc4598cc87a55047e38fa/.github/actions/update-cache-index/main.js#L8-L37

I ended up giving up going down that path because I needed stable URLs for the artifacts. It also means that there's a more fundamental change that needs to happen in the way GitHub Actions implements artifacts internally to allow for this issue to be fixed. The internal API being queried is not the GitHub REST API, but rather an Azure Pipelines API, so I'm guessing there's some syncing of state between the two systems that only happens at predetermined times, such as workflow run completion.

[JacksonKearl]

It'd be great if this could work better for using Environments to gate the publishing of a built artifact. We'd like for one stage to build the artifact, upload it, then a person manually tests the artifact, submits an approving review once they've tested, then the second job comes to publish the same artifact. If we can't access artifacts mid-job, this won't work at all.

[pauleustice]

I'm also running into this issue in a release context. We trigger a repository_dispatch which creates artifacts (reports etc) for a release and should then upload them in the final job to the release.

Short of uploading the artifacts somewhere for re-use, I don't currently see how we can do this as they must be accessed in a separate workflow as it stands.

[panayot-cankov]

@JacksonKearl I was trying to achieve the exact same setup. We are building VS Code extensions that run on MacOS, Windows and Linux. The release workflow is supposed to build a .vsix file in one job, pass it down to few other jobs running e2e tests, and a QA is supposed to manually verify the artefact, if all is ok the team would authorise a publishing environment that would upload the artefact to the store.

I think Actions have some room for improvement for Jobs that include manual labour, as well as the artefacts in those cases should be available somehow before the workflow fully completes.

[relsqui]

This is impacting me while writing and testing a new workflow -- I want to verify that a new artifact uploading step is doing the right thing but I'm not ready to run the whole long workflow yet (and have not yet written the step that downloads and uses the artifacts).

[tomjohnburton]

We would love to see this feature too.

We build binaries, store them as artifacts, and then want to download them directly through the API.

[invalidred]

+1 it makes a tonne of sense to view artifacts immediately in the workflow and not wait for it to complete. For example we have a rollback step post deploy pending approval and our workflow never really ends, however we could have an e2e test fail and would like to view the artifacts even when the workflow is not completed.

[mm-at-hydro]

+1. Also have the same requirement to do some manual work before approving to deploy an artifact to an environment. Coming from Azure DevOps, I believe that this functionality was on that platform.

[robinxb]

+1 for deploying some artifacts when using other deployment. Now I have to sleep for few seconds to make this work.