Configure previews with access tokens and check out to fork

[brauliorivas]

BEGINRELEASENOTES

• Previews are configured to use access tokens to push PRs changes from a fork to the main repo and deploy to GitHub pages.

ENDRELEASENOTES

• So in PR filtering/reconnecting #18 there is a problem with previews. When deploying, instead of showing the changes from the PR, it showed the same original repo as a preview. I suspected this, because in the preview.yml, the action never checked out to the PR, instead, it was to the same repo. However, I got confused when replicating, and thought It worked. After taking a closer look at my examples, I noticed that they never worked. This preview was supposed to show the changes, but instead showed the same repo again.
• I did some research and found a repository that uses pr-preview-action for their previews. With this, I got an idea on how to fix previews.
• To deploy previews, we need to:
  1. Checkout to the user's PR to show their changes.
  2. Push this to the original repo.

To do that we need: a fine-grained access token, that allows us to have write access to key4hep/dmx (more info at docs and generate like this) and save this as a secret in the repo.
@tmadlener or @kjvbrt should generate the token and add it as a secret inside an environment called github-pages (This one I think was already automatically generated). The token should be called PR_TOKEN. This setting is available at Settings > Environments > github-pages > Add environment secret.

My working example has the main website and a preview using this same action file.

[github-actions]

PR Preview Action v1.4.7
🚀 Deployed preview to https://key4hep.github.io/dmx/pr-preview/pr-24/
on branch gh-pages at 2024-05-29 19:51 UTC

[brauliorivas]

A GitHub action was triggered, using this updated version. However, it didn't fail (there is no secret called PR_TOKEN). I don't know why. Anyway, I would like to give it a try. Also, if this works, then I should also later update test.yml file to run the test in the PR, not in dmx. However, this PR should be first merged first to check if works or not.

[tmadlener]

I think the PR_TOKEN is automatically injected into the secrets for each PR.

Can you make a small but visible change to see if things are working now? Or does this have to be on main first?

[brauliorivas]

Can you make a small but visible change to see if things are working now? Or does this have to be on main first?

Sure! I will make a small change to test this.

[brauliorivas]

Yeah, it didn't work.

I think the PR_TOKEN is automatically injected into the secrets for each PR.

I mean, that's the name I assume exists. However, as explained, it has to be added to the environment.

[tmadlener]

As an alternative, can you check whether preview works if the PR comes from a branch within this repo? I.e. not from your fork. Do you have the necessary rights to do create branches here?

[brauliorivas]

As an alternative, can you check whether preview works if the PR comes from a branch within this repo? I.e. not from your fork.

Alright! I will try this.

Do you have the necessary rights to do create branches here?

Yes, I can create a branch here.

[brauliorivas]

The preview didn't work. It shows the current main version of dmx. In my example that uses the same workflow file as the current version of dmx, it never checkouts to the fork, shows main instead. So it was expected to happen. However, a few important things:

• I opened a PR within the repo, not a fork. It worked, if we use the suggested new workflow file.
• I also opened a PR within the repo, but using a more restrictive workflow, that will only work for those that have write access directly on key4hep/dmx (like me).

I would still like to try the solution I did here because it will allow anybody to create previews when opening a PR, and help contribute. However, if it fails, we could discuss if it is worth it doing this now, and instead, try the easier strategy that will only work for those with access, and later come back to this task and fix this. The "bad" part then, is that many branches will be created in the main repo, but we could delete them. Nevertheless, we lose a bit of git history.