Artifacts download api for artifact actions v4

[ChristopherHX]

• download endpoint has to use 302 redirect
• fake blob download used if direct download not possible
• downloading v3 artifacts not possible

New repo apis based on GitHub Rest V3

• GET /runs/{run}/artifacts (Cannot use run index of url due to not being unique)
• GET /artifacts
• GET + DELETE /artifacts/{artifact_id}
• GET /artifacts/{artifact_id}/zip
• (GET /artifacts/{artifact_id}/zip/raw this is a workaround for a http 302 assertion in actions/toolkit)
  • api docs removed this is protected by a signed url like the internal artifacts api and no longer usable with any token or swagger
  • returns http 401 if the signature is invalid
    • or change the artifact id
    • or expired after 1 hour

Closes #33353
Closes #32124

[ChristopherHX]

usage in

on: push
jobs:
  test:
    runs-on: mac-docker
    steps:
    - uses: christopherhx/gitea-download-artifact@v4
      with:
        name: mygithub-context
        github-token: ${{ secrets.GITHUB_TOKEN }} # token with actions:read permissions on target repo
        #repository: actions/toolkit
        run-id: 4 # To get this id could be a challenge, in github.com it's part of the web ui url, we only have a run_number / index
    - run: ls -l
    - run: cat file.txt

[silverwind]

templates/swagger/v1_json.tmpl:
Wrong line endings or no final newline

IIRC, this is a outstanding bug that the swagger command sometimes introduces platform-specific line-endings. I think we need to normalize the file.

[wxiaoguang]

Could there be some tests to cover the newly added APIs?

[Zettat123]

I think this err should be returned if it's not nil

[ChristopherHX]

You are right, currently the error return value seems to be accidentally not returned.

But I want to make sure we get the expected behavior here, therefore I want some discussion about this before making changes

If we just return the error here (without changing the callers), this error may get returned by the api instead of triggering the fallback ( tunneling blob via gitea ).

What do we want to do with this error?

• Return it from the api and abort the request? (needs changes)
• Try the fallback and fail if the fallback doesn't work? (current behavior)
  • Log the error from the caller and continue with the fallback? if the boolean returns false (...and return the error from api if it returns true) (needs changes)
  • Otherwise Remove the error return value from the function? (needs changes)
  • Most ServeDirect() paths I saw in gitea dropped the error and only used it to detect if the url has been returned without error e.g. search for text ServeDirect in this repo

[wxiaoguang]

I think it's fine to keep as other behaviors, no need to introduce too many changes at the moment.

[Zettat123]

Yes. I think it's OK to keep the current behavior. Maybe we can add some logs for this error later to help us debug cases where SERVE_DIRECT doesn't work.