Add comment to PR with preview link

[holly-cummins]

I noticed we're not adding comments to PRs, even though we do the hard work of making a preview.

[holly-cummins]

Sadly, the version of the workflow run in the PR is the one in main, not in this PR, so I'm not sure we can test it without merging.

[gastaldi]

This is weird. Can you check if the comment is created for a PR coming from a branch from this repository (not from a fork?).

AFAIR the surge-action already does all the work, so if we're using it I don't think it needs extra steps

[holly-cummins]

I agree that the docs show pictures of comments, which makes it look like the action does everything. In https://github.com/quarkusio/quarkusio.github.io/blob/develop/.github/workflows/preview.yml we have to add the comments manually, but we're not using the action, just a npx command, so that makes sense.

Unfortunately, I don't think I have permissions to do a PR from a branch of this repo. I agree it's a good experiment to try.

Oh wait, I think I see the issue. The docs have this:

    permissions:
     pull-requests: write # allow surge-preview to create/update PR comments

I'll try adding that instead.

[gastaldi]

Let's see how that goes

[holly-cummins]

Argh, thanks for the merge - but I think we're not there yet. :(

 PR created from a forked repository, so skip PR comment

I checked back through the other builds of the earlier version of this PR, and it's the same message. So I don't even know what the permissions flag does. More work needed, since most PRs will be from forks.

[gastaldi]

since most PRs will be from forks

I don't think so, as members of the quarkiverse-members team are allowed to push and create branches here

[holly-cummins]

since most PRs will be from forks

I don't think so, as members of the quarkiverse-members team are allowed to push and create branches here

Oh, that would help!

I just did a quick survey of the recent PRs to check.

• Publish docs of quarkus-cxf 1.5 #85 - fork, no comment
• Add quarkus-openfga-client docs #84, main repo, comment
• add quarkus-zeebe #83, main repo, comment
• add quarkus-mockserver #82, main repo, comment
• add quarkus-unleash 0.x #81, main repo, comment
• Add quarkus-bucket4j #80, main repo, comment
• Include version 1.x of JPAStreamer docs #78, main repo, comment

So the first one I checked was from a fork, but all the others were from the main repo. I guess it's just Peter and I who hadn't got the memo. And my change didn't really do anything. :)

Scrolling down further I can find a few others from forks, like #63 and #64, but not so many. So I guess that's ok.

[holly-cummins]

(Another of way of checking, I guess, is to see that we have 31 forks of this repo, and 89 PRs. So if every fork did exactly one PR, that would be a third of the PRs originating from a fork ... but some of those forks probably didn't originate any PRs.)

[gastaldi]

I wonder if splitting the CI preview as proposed in #44 would help

[holly-cummins]

I think so. The main quarkus docs site, and extensions.quarkus.io, have previews from forks, using a similar technique, I think.

While I was reading the surge docs I also noticed that we should be able to have just one surge workflow. If we trigger on both open and close, and set teardown: true, it seems like surge will figure out whether to standup or teardown.