9463c8df90
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> |
||
|---|---|---|
| .. | ||
| .github/workflows | ||
| cypress | ||
| public | ||
| scripts | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| CHANGELOG.md | ||
| cypress.json | ||
| index.html | ||
| index.js | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
| renovate.json | ||
| tsconfig.json | ||
| tsconfig.node.json | ||
| typings.json | ||
| vercel.json | ||
| vite.config.ts | ||
| yarn.lock | ||
unleash-frontend
This repo contains the Unleash Admin UI frontend app.
Run with a local instance of the unleash-api
First, start the unleash-api backend on port 4242. Then, start the unleash-frontend dev server:
cd ~/unleash-frontend
yarn install
yarn run start
Run with a heroku-hosted instance of unleash-api
Alternatively, instead of running unleash-api on localhost, use a remote instance:
cd ~/unleash-frontend
yarn install
yarn run start:heroku
Running end-to-end tests
We have a set of Cypress tests that run on the build before a PR can be merged so it's important that you check these yourself before submitting a PR. On the server the tests will run against the deployed Heroku app so this is what you probably want to test against:
yarn run start:heroku
In a different shell, you can run the tests themselves:
yarn run e2e:heroku
If you need to test against patches against a local server instance, you'll need to run that, and then run the end to end tests using:
yarn run e2e
You may also need to test that a feature works against the enterprise version of unleash. Assuming the Heroku instance is still running, this can be done by:
yarn run start:enterprise
yarn run e2e
Generating the OpenAPI client
The frontend uses an OpenAPI client generated from the backend's OpenAPI spec. Whenever there are changes to the backend API, the client should be regenerated:
./scripts/generate-openapi.sh
This script assumes that you have a running instance of the enterprise backend at http://localhost:4242.
The new OpenAPI client will be generated from the runtime schema of this instance.
The target URL can be changed by setting the UNLEASH_OPENAPI_URL env var.