* fix: use the frontend dir from the backend
* Build is now working
* Fix workflows
* Fix workflows
* Fix build PRs
* Test coverage workflow
* Test coverage
* Test coverage run
* Fix jest report
* refactor: add missing frontend build
* refactor: ignore frontend dir for coverage
* refactor: run frontend build in PRs
* refactor: run backend tests in PRs
* Revert "refactor: run backend tests in PRs"
This reverts commit 22cabddfd1.
* refactor: remove unused frontend build file
* refactor: test workflows in PR
* refactor: use a prepare script for the frontend
* refactor: simplify yarn build scripts
* refactor: fix check-release script
* Revert "refactor: test workflows in PR"
This reverts commit 496ae19404.
* refactor: remove unused gitignore lines
* refactor: remove renovate config from the frontend repo
* refactor: remove frontend repo license
* refactor: remove frontend repo changelog
* refactor: update frontend repo readme
* refactor: add frontend node_modules to dockerignore
* refactor: update the docker yarn.lock snapshot
Co-authored-by: olav <mail@olav.io>
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>
* fix: reject duplicate segment names
* fix: useSegmentValidation now takes into account initial value
* refactor: add segments e2e test
* refactor: add github action from segments e2e test
* refactor: use enterprise edition for all e2e tests
* refactor: use enterprise edition for all e2e tests
* refactor: normalize spec names
* refactor: make ESLint ignore dir
* refactor: port specs to TS
* refactor: wait for login redirects to finish
* refactor: remove static wait timers
* refactor: match any env name in interceptors
* refactor: move config vars to the top
* refactor: use longer IDs to avoid collisions
* refactor: misc cleanup
* refactor: disable screenshots and videos
* refactor: disable prod guard in tests
* refactor: wait for inputs before typing
