Skip to content

Gitea rerurns 404 when trying to download artifact via Gitea actions #33353

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

Closed
this-username-has-been-taken opened this issue Jan 22, 2025 · 3 comments · Fixed by #33510
Closed
Labels
topic/gitea-actions related to the actions of Gitea type/bug

Comments

@this-username-has-been-taken
Copy link

this-username-has-been-taken commented Jan 22, 2025

Description

Hello!

I was trying to download an artifact that was published in a different workflow and faced with a 404 error returned by Gitea.

Let's assume that we have 2 workflows:

workflow1.yml - generates and publishes an artifact under build_details_{run_id} name

name: Generate and publish artifacts
on:
  workflow_dispatch:
jobs:
  generate_publish:
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: write
    steps:
      - name: Generate artifacts
        shell: bash
        run: |
          mkdir output
          echo "TEST_VAR=123" | tee -a output/build_details.txt
      - name: Publish artifacts
        uses: christopherhx/gitea-upload-artifact@v4
        with:
          name: build_details_${{ github.run_id }}
          path: ${{ github.workspace }}/output/*
          retention-days: 7

workflow2.yml - downloads artifact published by workflow2.yml

name: Download artifact
on:
  workflow_dispatch:
    inputs:
      build-id:
        type: string
        description: Run ID
        required: true
jobs:
  download_artifact:
    runs-on: linux_amd64
    permissions: read-all
    steps:
      - name: Download artifact
        uses: christopherhx/gitea-download-artifact@v4
        with:
          name: build_details_${{ inputs.build-id }}
          github-token: ${{ github.token }}
          run-id: ${{ inputs.build-id }}
          path: input

Now let's assume that workflow 1 has been successfully completed: it recieved run id = 22 and it published an artifact named build_details_22.
If I run workflow 2 and pass 22 as build-id parameter I will get the following error: ::error::Unable to download artifact(s): 404 page not found%0A

If I replace Download artifact step in workflow 2 with an alternative action:

      - name: Download artifact
        uses: dawidd6/action-download-artifact@v7
        with:
          github_token: ${{ github.token }}
          run_number: ${{ inputs.build-id }}
          name: build_details_${{ inputs.build-id }}
          workflow: workflow1.yml

I will get the same error: ::error::404 page not found%0A

Taking into account the same error messages (followed by %0A) I think that there is a bug exist in some of the Gitea endpoint(s).
I appreciate any advice how to fix the issue

Gitea Version

1.23.1

Can you reproduce the bug on the Gitea demo site?

No: there are no runners available on the demo site

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian 12

How are you running Gitea?

Gitea is running in the Docker container.
Gitea act runner is installed directly on the server.

Database

PostgreSQL

@kemzeb kemzeb added the topic/gitea-actions related to the actions of Gitea label Jan 22, 2025
@ChristopherHX
Copy link
Contributor

If I run workflow 2 and pass 22 as build-id parameter I will get the following error: ::error::Unable to download artifact(s): 404 page not found%0A

Yes I did skip implementing the public actions artifacts api endpoints used by this v4 action (private workflow run scoped api has been implemented by me and contributed to gitea).

So it's certainly possible this rest api endpoint are still missing, which is only used once github-token is set / used by your external action.

Requires new rest api endpoints for Gitea Actions.

I could look into this soon we have UI endpoints for them only, together with an rest api endpoint for workflow_dispatch which is missing as well

@this-username-has-been-taken
Copy link
Author

this-username-has-been-taken commented Jan 24, 2025

Thank you!

So far I came up with the following workaround.

Prerequisites

  1. You should create a technical user with access to artifacts, but without 2FA and put its username and password into Actions Secrets under ACTIONS_USERNAME and ACTIONS_PASSWORD variables accordingly.
  2. unzip package should be installed on the server.
  3. You must know name of the organization (env.ORG_NAME variable) and the repo (env.REPO_NAME variable).
  4. You must know exact name of the artifact (env.ARTIFACT_NAME variable) you want to download and the build ID (env.BUILD_ID variable).

How to
Create a step which will download and extract artifacts into input folder:

      - name: Artifact download
        shell: bash
        run: |
          mkdir input
          cd input
          curl --request POST \
            --url ${{ gitea.server_url }}/user/login \
            --header 'Content-Type: application/x-www-form-urlencoded' \
            --data 'user_name=${{ secrets.ACTIONS_USERNAME }}' \
            --data 'password=${{ secrets.ACTIONS_PASSWORD }}' \
            --cookie-jar gitea_cookies.txt
          curl --fail --output build_artifacts.zip \
            --url ${{ gitea.server_url }}/${{ env.ORG_NAME }}/${{ env.REPO_NAME }}/actions/runs/${{ env.ARTIFACT_NAME }}/artifacts/${{ env.ARTIFACT_NAME }} \
            --cookie gitea_cookies.txt
          unzip build_artifacts.zip
          rm build_artifacts.zip gitea_cookies.txt

This step basically mimics user actions: performs login in Gitea, downloads artifacts via generated link and unzips them.

@ChristopherHX
Copy link
Contributor

ChristopherHX commented Feb 5, 2025

Re 302 http status assertion:
https://github.com/actions/toolkit/blob/340a6b15b5879eefe1412ee6c8606978b091d3e8/packages/artifact/src/internal/download/download-artifact.ts#L129

I my opinion this action should have allowed http 200 as well

EDIT whoops I meant to add this to the pr that implements this...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/gitea-actions related to the actions of Gitea type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants