Also a test here from @jrakibi shows that it's able to still generate a preview for PR from a fork Repo

I have concerns about the added step required for this preview. I believe GitHub Actions can be configured to run on PRs from new contributors across different repositories without this workaround.

Could you please investigate alternative implementation approaches, such as using a GitHub App? Let's confirm if this extra step is the only way to achieve the desired preview functionality.

I think I misinterpreted it in my comment "So this PR triggers the pull_request_target when an admin or collaborator has /build-preview in their comment". here is what happens with this new workflow

1. When a contributor creates a PR from a Fork repo it shows the image below in the PR,

2. Now when a maintainer or an admin approves the workflow, the workflow then has access to the secrets which is needed to make a build preview of what change in the PR

3. if changes are made, the maintainer doesn't need to go and rerun the workflow from the actions tab, they can easily trigger it with "/build-preview" command.

An example for you to see is in bitcointranscripts/demo-test-transcript#2 in this case i only approved the workflow to run and no build-preview comment

In this other example bitcointranscripts/demo-test-transcript#1 I had to comment /build-preview because the earlier workflow failed.

So in conclusion it is not really an extra step.

Thanks for clarifying @0tuedon! I have two follow-up questions:

1. If a contributor updates their PR (e.g. edits the submission content), does the workflow run automatically and generate an updated preview?
2. From the screenshot below, am I correct in understanding that this manual approval is only required for first-time contributors?

Thanks for clarifying @0tuedon! I have two follow-up questions:

1. If a contributor updates their PR (e.g. edits the submission content), does the workflow run automatically and generate an updated preview?
2. From the screenshot below, am I correct in understanding that this manual approval is only required for first-time contributors?

1. If a first time contributor updates their PR one would still need to approve a workflow or put a /build-preview. now if they are not a first-time contributor it would not require any of this approval.

2. yes it is only required for first time contributor, a non first time contributor doesn't need approval.

An Example again is this bitcointranscripts/demo-test-transcript#2, I merged this bitcointranscripts/demo-test-transcript#1 and @jrakibi is no longer a first time contributor and no approval was needed for the updates.

Got it, thanks for clarifying! One last question: is there a reason to keep the /build-preview comment logic? Since the button already covers the same use case, it feels like extra complexity we could remove.

Got it, thanks for clarifying! One last question: is there a reason to keep the /build-preview comment logic? Since the button already covers the same use case, it feels like extra complexity we could remove.

I agree with you, my reason for adding it was because i did think the comment was needed to trigger a rebuild and it was needed to grant access to the secrets. I will remove the if conditon and also test on the https://github.com/bitcointranscripts/demo-test-transcript repo

Hi @kouloumos, I have updated the requirements, please help review.