[POC] Add deploy preview to PR body

[siriwatknp]

Changes

• grab the first 5 docs/data/*.md files that are created or updated and add to the comment.

What I learned

At first, I tried to move this deploy preview comment to github actions but failed due to the permission scopes.

In this article, the pull request from fork does not receive the repo's secrets and will always have read scope when the workflow runs. Danger cannot comment on the PR, so I revert the change and just updated the existing script to grab markdown files to the comment.

---

• I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

No updates.

Bundle size report

No bundle size changes

Generated by 🚫 dangerJS against e7e9d0d

[alexfauquette]

In this article, the pull request from fork does not receive the repo's secrets and will always have read scope when the workflow runs.

I was a bit surprised by this because vale is a github action and it adds comments to the PR.

To be more precise, PR from a forked repository does not receive the write permission by default (github docs). But on the same page, you have an example where the action has writing permissions.

---

The danger file sounds to be a good starting point. My only concern would be about how we extend it to X and toolpad. for now it sounds more likely that it will be copy/pasted

[siriwatknp]

In this article, the pull request from fork does not receive the repo's secrets and will always have read scope when the workflow runs.

I was a bit surprised by this because vale is a github action and it adds comments to the PR.

To be more precise, PR from a forked repository does not receive the write permission by default (github docs). But on the same page, you have an example where the action has writing permissions.

The example you provide uses pull_request_target which mentioned in the security article that it should not be used if we have yarn install script.

We could write a custom script instead of using danger if we want to use pull_request_target in github actions but I don't want to go that far.

[oliviertassinari]

@siriwatknp Nice 👌

We could write a custom script instead of using danger if we want to use pull_request_target in github actions but I don't want to go that far.

Two thoughts on this:

1. One of the design objectives with mui-bot was to group PR comment notifications to reduce notifications noise. I feel that we are achieving this now. Instead of having two comments added to the PR that triggers a notification.
2. I wonder how helpful https://github.com/errata-ai/vale-action is. It sounds great to have the comments right where the issue happens. But in practice, it's in the code editor that it needs to be fixed, so getting the output from the script that runs in the CI is usually more effective. Also, the comments might create noise in the review vs. maintainers' comments. I guess that because Vale is only comments on markdown, and the people who review the markdown mostly use the GitHub's UI, it's mostly helpful.

[siriwatknp]

@alexfauquette Are we good to merge? do you see any blockers?

[alexfauquette]

Sounds good, I will add it to the X repo :)

[alexfauquette]

In practice, it's in the code editor that it needs to be fixed

For those who want, there exists a VSCode extension to run vale. So you can get the warnings in code editors.

But adding comments in the file diff has two advantages:

• It's readable. If you just get a comment in your PR saying Avoid using 'we' in file xxx.md, line xx it would be a pain
• It's a heads-up for the reviewer. Form what I see, reviewers tend to make suggestions about how to rephrase, which is easier when you have a fresh pair of eyes