Do not use external QR Code generators

[displague]

External QR Code generators leak organizational information about orgs, repositories, and PRs. This feature has recently been changed to enabled by default.

A QR code can easily be generated as a data-uri within the action's response body.

[rossjrw]

Thanks for the feedback! You're right that you shouldn't trust external QR code services, which is why I built my own from scratch specifically for this Action, which you can fork to build your own provider: https://github.com/rossjrw/pr-preview-action#use-a-different-qr-code-provider

Data URIs cannot be embedded as images in GitHub markdown unfortunately, or it would be the perfect solution. (#98 (comment))

QR codes are enabled by default since earlier today. I'm still collecting feedback about it - you're the first to respond - so you are definitely heard. I will turn it back off if I feel that the majority do not want it. For now, you can set qr-code: false to turn it off on your end.

If you have any more thoughts, I'm all ears.

[displague]

I didn't realize data-uris were not GHM supported (I want to think this hasn't always been the case).

Sure enough, they don't work. (although... when I submitted this comment, and whenever I update the description, I briefly see the happy faces before they are replaced with the alt text)


[rossjrw]

It definitely used to not be the case, here's an example from 10 years ago that presumably worked at one point https://gist.github.com/jmakeig/9786a6654e6b5c1989005061135463d0

[displague]

If you have any more thoughts, I'm all ears.

The preview URL could host the QR code image... Although that could get tricky. (This action doesn't know how that content got there, or how to add content there). An action could return the preview URL, and SVG QR code content, and the user would have to place that file in their artifacts.

[rossjrw]

The preview URL could host the QR code image... Although that could get tricky. (This action doesn't know how that content got there, or how to add content there).

Not a bad idea. We already create a nested dir pr-preview/pr-N/ - the pr-preview/ dir is effectively under this action's control and can be written to without any risk of conflict with previewed files. pr-preview/pr-N-qr-code.svg or something. The risk then is the assumption that the preview is actually being hosted on a working webserver that permits image hotlinking from github.com. I believe that's the case for GitHub Pages. I think it could work for the action's primary use case. Probably needs some more thought.

Noting that I've added a link to this issue from the 1.8.1 release page and will redirect any future issues/discussions on this topic to here.