Making links to artifacts available from pull requests

We’ve been migrating builds to GitHub actions and it’s been pretty smooth.

What’s not obvious to many people is how to get the artifacts from a pull request. That is, if you open a pull request page, you can see the build status… but there’s no direct link to the artifacts.

Ideally, I’d love to see a section with a link to all successful artifacts. Is it possible to do this as part of the workflow? (That is, gather all the links to artifacts and post as a comment to the pull request?)

For example:

It’s not obvious from the GH action runs that you need to click “Details” and then find the artifact links in the top right corner. (I’ve had several developers and users confused about this.) People seem to want a section of the pull request that indicates links to all artifacts - either as an official part or through an auto-generated comment.

Can you programatically get the URL(s) of all the artifacts from a pull request?

Hi @ghutchis ,

The artifacts url has below format:${{ github.repository }}/suites/${{ check_suite_id }}/artifacts/${{ artifacts_id }}

a. ‘check_suite_id’ can be got from rest api, code as below:

- name: get check_suite_id
        run: |
          URL="${{ github.repository }}/actions/runs/${{ github.run_id }}"
          check_suite_id=$(curl -s -u admin:${{ secrets.GITHUB_TOKEN }} $URL | jq -r '.check_suite_url' | awk -F "/" '{print $NF}')
          echo $check_suite_id

b. ‘artifacts_id’ can be got from rest api, code sample as below:

- name: get artifacts_id
        run: |
          URL="${{ github.repository }}/actions/runs/88857090/artifacts"
          curl -s -u admin:${{ secrets.GITHUB_TOKEN }} $URL | jq '.artifacts[].id'

However, cannot get artifacts id before current workflow complete , hence you need to use a 2nd workflow to get the artifacts_id.

Overall, 2 workflows are needed.  

In 1st workflow, transfer pull_request.number, checkrun_id to 2nd workflow:

- name: Repository Dispatch
        uses: peter-evans/repository-dispatch@v1
          token: ${{ secrets.PAT1 }}
          repository: weide-zhou/ticket13
          event-type: my-event
          client-payload: '{"prnumber": "${{ github.event.number }}", "checkrunid": "${{ github.run_id }}"}'

In 2nd workflow, use event ‘repository_dispatch’ to trigger the workflow, get the payload value for rest api commands of checksuite_id, artifacts_id.

name: create comment with artifacts
    runs-on: [ubuntu-latest]
      - name: echo value
        run: |
          echo ${{ github.event.client_payload.prnumber }}
          echo ${{ github.event.client_payload.checkrunid }}
      - name: get check_suite_id
        id: getsuiteid
        run: |
          URL="${{ github.repository }}/actions/runs/${{ github.event.client_payload.checkrunid }}"
          check_suite_id=$(curl -s -u admin:${{ secrets.GITHUB_TOKEN }} $URL | jq -r '.check_suite_url' | awk -F "/" '{print $NF}')
          echo $check_suite_id
          echo "::set-output name=suiteid::$check_suite_id"
      - name: get artifacts_id
        id: getartid
        run: |
          URL="${{ github.repository }}/actions/runs/${{ github.event.client_payload.checkrunid }}/artifacts"
          artifacts_id=$(curl -s -u admin:${{ secrets.GITHUB_TOKEN }} $URL | jq '.artifacts[].id')
          echo $artifacts_id
          echo "::set-output name=artid::$artifacts_id"
      - name: check url
        run: |
          echo${{ github.repository }}/suites/${{ steps.getsuiteid.outputs.suiteid }}/artifacts/${{ steps.getartid.outputs.artid }}
      - name: comment pr
        uses: peter-evans/create-or-update-comment@v1
          issue-number: ${{ github.event.client_payload.prnumber }}
          body: |
            The artifacts url is${{ github.repository }}/suites/${{ steps.getsuiteid.outputs.suiteid }}/artifacts/${{ steps.getartid.outputs.artid }}

My workflow for your reference:

1st workflow(create PR):

2nd workflow(create Comment):

The artifacts url is added:

Hope it helps!

–Edited: fixed typo.

Thanks. It looks good and I finally had time to try it over the weekend.

Unfortunately, it doesn’t work for my scenario, because a pull-request that starts in an forked repository doesn’t get the secret. So the first workflow fails because my fork doesn’t have the official repo’s secret.

IMHO, this is something that GitHub needs to enable themselves, and any workaround like yours, will fail.

In the meantime, I’m going to add nightly pre-release builds.