Is it possible to attach a ZIP file or an image to comment?

[rvalitov]

If yes or no, how to do it or any advice?

[mshick]

It is not. This would ultimately just be markdown in the message itself, but we'd need some place to store the file. I've looked at the relevant APIs and it doesn't appear that GitHub makes the storage they use for their interface available — I'm referring to what happens you you drag-and-drop a file into an editor.

I suspect we could do something using the artifacts storage for the run, though this might have an expiration date.

Regardless, great idea for an enhancement. I welcome PRs, and will look into it more myself.

[mshick]

Ah, and as for advice — you might be able to cobble something together by uploading a file to a cloud provider, e.g., S3 File Upload and working out the URL in a step.

Below is an example — I've never used the S3 File Upload action before, just something I found on the marketplace. You could probably find one for whatever provider you use.

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - name: Upload file to bucket
        uses: zdurham/s3-upload-github-action@master
        with:
          args: --acl public-read
        env:
          FILE: ./lambda.zip
          AWS_REGION: 'us-east-1'
          S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          S3_KEY: ${{ secrets.S3_KEY }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - id: get-file-url
        run: |
           echo "file_url=https://my-bucket-url.com/file/path.png" >> $GITHUB_OUTPUT

      - uses: mshick/add-pr-comment@v2
        with:
          message: |
            ![test image](${{ steps.get-file-url.outputs.file_url }})
            

[rvalitov]

OK thank you! Much appreciated for the comments and advice. But hope to see such feature natively implemented one day in your project.

[mshick]

I was looking into it, and it seems like I can use the artifact API to create and build valid artifact URLs. This would allow for a file to be uploaded and then embedded as a link. The only caveat being the file would only persist for your configured retention period, by default that is 90 days.

Do you think this would work for your case? If so I can probably implement this. Definitely sounds useful.

[rvalitov]

Yes, artifact API is the best approach. Actually I have been using such actions that already use it. Please have a look at https://github.com/gavv/pull-request-artifacts That repo's code does not work properly without proper instructions and is not maintained. I like your project which is far more superior and only missing feature is the uploads via artifacts.

[mshick]

@rvalitov Ah, good to see that and know it's somewhat useful.

I did some extensive testing of the artifacts API, and unfortunately it doesn't allow for generating a link during an action run. It seems like a sort of arbitrary system limitation on the GitHub side, as many people have requested the feature on the upload-artifact action for years. The links can only get gotten after the run, on the workflow_run event.

This means the best approach to this is like the action you're using, which has an extensive setup, or allowing the user to provide a cloud bucket like S3. None of this is as user-friendly as I'd like, but it would be great functionality, so I'll work on it.

[rvalitov]

Excuse me I didn't get it. I've been using the action specified for build test before PR merge. And it posts attachments to the PR as comments successfully. What limitations do you mean exactly?

[rvalitov]

[rvalitov]

And as far as I tested, it can be triggered automatically on build or on manual run, too. No matter actually...

[mshick]

Yeah, the one you linked to, https://github.com/gavv/pull-request-artifacts, works by writing back to the repo, as opposed to using GitHub's artifacts API. The difference is files being added to your repo (some might consider that clutter) and related concerns people might have about managing those files which can now be modified and viewed out of context.

That said, it's not a bad approach given the limitations of the artifact API and it's the direction that makes most sense to me, so I hope to add the functionality soon.