Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check exits before artifacts from job are available #23

Open
rkleinman-hpe opened this issue Jan 26, 2022 · 2 comments
Open

Check exits before artifacts from job are available #23

rkleinman-hpe opened this issue Jan 26, 2022 · 2 comments

Comments

@rkleinman-hpe
Copy link

I am using this action to determine when another workflow finishes so I can download artifacts from it. When the workflow finishes and this action exits cleanly, it appears as though the artifacts are not ready and the workflow fails saying that the artifact doesn't exist.

Is there a way around this? I realize this might not be this action's responsibility. Perhaps the API is showing the run as complete before the artifacts are available? Is there a way for this action to check for that?

@lihop
Copy link

lihop commented May 6, 2022

I came across this when I had two runs with the same commit but on different branches. For example, after merging a feature branch to the main branch.

2022-05-07-003451_952x163_scrot
2022-05-07-003438_925x270_scrot

Notice how it says 'Retrieved 2 check runs named Build Docker (release, 64)'. I think it is detecting the success of this check for run #80, even though this check has not finished in run #81, so the artifacts are not yet available for download in that run.

My workaround is to add the run number to the job name to make it unique:

name: 'Build Docker (${{ matrix.target }}, ${{ matrix.bits }}) #${{ github.run_number }}'
checkName: 'Build Docker (release, ${{ matrix.bits }}) #${{ github.run_number }}'

@bakoontz2
Copy link

I think the problem is that listForRef() in poll.tx is called without a delay, and the check status from the previous event is being returned. I proposed a solution in #32 and have been testing it, and it appears to behave more consistently now by not immediately returning a "completed" status when it's first called. I submitted a pull request as well, so you can look at the proposed fix. (I'm horrible at JS/TS, so there might be a more graceful way to do this.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants