* feat: persistent table query
* project overview sort query
* refactor: api methods as hook callbacks
* persitent columns in project overview
* enable new project overview
* fix: refactor feature state change in overview
* add type to sort
* update e2e tests
now takes 10% less time with use of cypress session
* prevent sort reset on features list
* fix feature toggle list loading
* fix: features table items virtualization
* project overview screen limits
* table row height in theme
* rename row index variable
* refactor: fix table header sort button focus styles
* refactor: extract FeatureNameCell component
* refactor: port health reports to react-table
* refactor: hide columns on small screens
* refactor: sort features by name
* feat: persistent table query
* project overview sort query
* refactor: api methods as hook callbacks
* persitent columns in project overview
* enable new project overview
* fix: refactor feature state change in overview
* add type to sort
* update e2e tests
now takes 10% less time with use of cypress session
* prevent sort reset on features list
* fix feature toggle list loading
* fix: update column state saving
* update local storage hook test
The `pull_request` hook runs in the context of the proposed changes. That means that for forks, this action won't have access to the required secrets for it to complete. As such, PRs from outside contributors won't work correctly.
The `pull_request_target` hook, however, runs in the context of the target branch, and thus has all the permissions it needs. The [github docs for this hook](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) also indicate that this is the way to go:
> This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.
## Interesting note for PRs
It seems that when this change is proposed as a PR, the expected action (_add new item to project board_) does not run. However, this does not affect other new PRs. After merging, the pipeline works and triggers as expected, for both external and internal contributors.
## Isn't this potentially dangerous?
Good question! As far as I understand: no, it's not. The long answer is in [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/), but I'll try and summarize it here.
Some choice cuts from the article:
> TL;DR: Combining pull_request_target workflow trigger with an **explicit checkout of an untrusted PR** is a dangerous practice that may lead to repository compromise.
However, we do not check the PR out!
> Due to the dangers inherent to automatic processing of PRs, GitHub’s standard pull_request workflow trigger by default prevents write permissions and secrets access to the target repository. However, in some scenarios such access is needed to properly process the PR. To this end the pull_request_target workflow trigger was introduced.
> pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user supplied code.
> These safeguards enable granting the pull_request_target additional permissions. The reason to introduce the pull_request_target trigger was to enable workflows to label PRs (e.g. needs review) or to comment on the PR. The intent is to use the trigger for PRs that do not require dangerous processing, say building or running the content of the PR.
That is: when using `pull_request_target`, the action will not check out the PR branch and thus, the PR cannot inject any code changes into the action. On the other hand `pull_request` uses the code that's in the PR to run actions, which is why it requires explicit authorization before being run.
`pull_request_target` runs in the context of the target branch (most commonly `main`) and only runs code that already exists in the target branch. No code from the PR gets used.
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
The `pull_request` hook runs in the context of the proposed changes. That means that for forks, this action won't have access to the required secrets for it to complete. As such, PRs from outside contributors won't work correctly.
The `pull_request_target` hook, however, runs in the context of the target branch, and thus has all the permissions it needs. The [github docs for this hook](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) also indicate that this is the way to go:
> This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.
## Interesting note for PRs
It seems that when this change is proposed as a PR, the expected action (_add new item to project board_) does not run. However, this does not affect other new PRs. Also, after merging it works as expected, for both external and internal contributors.
