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

[bug] retrying a workflow causes uploaded artifacts from the previous attempt to become inaccessible #585

Open
zackelan opened this issue Jul 12, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@zackelan
Copy link

What happened?

we have a workflow that runs integration tests on PRs. at the end of the test run, we gather logfiles from the tests and upload them using upload-artifact.

these integration tests sometimes have intermittent failures, which our engineers try to work around by re-running the workflow.

when the workflow is retried, the artifacts from the first attempt are no longer accessible. this hinders efforts at debugging the root cause of the intermittent test failures.

this is from using the minimal repro workflow below, which simulates a failing test with some trivial log output, then uploads those logs.

after attempt 1 - the artifact download link is visible, as expected:

2024-07-12_10 29 26

I select "re-run jobs -> re-run all jobs", producing attempt 2. here, the artifact download link is also visible, as expected:

2024-07-12_10 32 35

however, if I pick attempt 1 from the drop-down, the artifact download link no longer appears:

2024-07-12_10 32 52

and this seems to not just be a UI issue - here are the logs from upload-artifact from attempt 1:

Run actions/upload-artifact@v4
With the provided path, there will be 1 file uploaded
Artifact name is valid!
Root directory input is valid!
Beginning upload of artifact content to blob storage
Uploaded bytes 198
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is ded999c92c4c36cca01ed60f4b959a90b9272e40192e1644005ee438c3a2f2ca
Finalizing artifact upload
Artifact logs-9911783285-1.zip successfully finalized. Artifact ID 1696153380
Artifact logs-9911783285-1 has been successfully uploaded! Final size is 198 bytes. Artifact ID is 1696153380
Artifact download URL: https://github.com/edgedb/nebula/actions/runs/9911783285/artifacts/1696153380

the artifact download URL works before I run attempt 2, but afterwards gives me a 404 error.

the same logs from attempt 2, this artifact download link works (at least, until/unless I run attempt 3):

With the provided path, there will be 1 file uploaded
Artifact name is valid!
Root directory input is valid!
Beginning upload of artifact content to blob storage
Uploaded bytes 198
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is d3892c77d66fadfa1cc6934cffa240ff52f14c3cb0fc7a018bb9639733655215
Finalizing artifact upload
Artifact logs-9911783285-2.zip successfully finalized. Artifact ID 1696165056
Artifact logs-9911783285-2 has been successfully uploaded! Final size is 198 bytes. Artifact ID is 1696165056
Artifact download URL: https://github.com/edgedb/nebula/actions/runs/9911783285/artifacts/1696165056

What did you expect to happen?

I'm giving a unique name to the upload-artifact step, which includes the run attempt in the name: logs-${{ github.run_id }}-${{ github.run_attempt }}

because of this, I expect subsequent run attempts to not overwrite artifacts from previous attempts.

How can we reproduce it?

name: Tests

jobs:
  test:
    runs-on: ['self-hosted', 'linux', 'X64']

    defaults:
      run:
        shell: bash

    steps:
      - name: Write some logs
        run: |
          logdir="logs/logs-${{ github.run_id }}-${{ github.run_attempt }}"
          mkdir -p $logdir
          date --utc -Is > $logdir/output.txt
          exit 1

      - name: Upload logs
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: logs-${{ github.run_id }}-${{ github.run_attempt }}
          path: logs/
          compression-level: 9

      - name: Clean logs
        if: always()
        run: |
          rm -rf logs/

Anything else we need to know?

No response

What version of the action are you using?

v4

What are your runner environments?

self-hosted, linux

Are you on GitHub Enterprise Server? If so, what version?

No response

@zackelan zackelan added the bug Something isn't working label Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant