The CI system makes a report of the change to memory usage of the example sketches that results from the changes made in a pull request. It does this via a comment on the PR thread. In order to do that, it needs write permissions in the repository. As a security precaution, workflow runs triggered by a pull request from a fork are not given the necessary write permissions.
The workflow was added in the early development phase when the repository was still private. In that situation, the approach of triggering the deltas report from the pull_request event was the best (due to the limited allowance of GitHub Actions minutes for private repos) but now the repository is public (thus having unlimited free minutes) and it's important to get reports on pull requests that come from forks. So the approach of using a dedicated workflow triggered by the schedule event
(which does have write permissions) is better.
The CI system makes a report of the change to memory usage of the example sketches that results from the changes made in a pull request. It does this via a comment on the PR thread. In order to do that, it needs write permissions in the repository. As a security precaution, workflow runs triggered by a pull request from a fork are not given the necessary write permissions.
The workflow was added in the early development phase when the repository was still private. In that situation, the approach of triggering the deltas report from the
pull_requestevent was the best (due to the limited allowance of GitHub Actions minutes for private repos) but now the repository is public (thus having unlimited free minutes) and it's important to get reports on pull requests that come from forks. So the approach of using a dedicated workflow triggered by thescheduleevent (which does have write permissions) is better.