This change adds a stale bot configuration with a reference to the [org-wide Unleash configuration](https://github.com/Unleash/.github/blob/main/.github/stale.yml).
## About the change
We're adding stale bot as a way to help us manage issues that don't see any activity. When that happens, it's usually because we don't have further resources to work on something or because we're missing information. These issues often go forgotten and end up lying around open. This is an attempt to get around that.
The config file contains the details for how long the bot waits before touching an issue and then how much longer before it closes it if no further activity occurs. (Currently set to 30 and 10 days respectively.)
## Keeping issues open
If there are long-standing issues that should _not_ be closed or marked as stale, you can label it with one of the `exemptLabels` in the stale config file (for instance: `pinned`). That'll keep stale bot from touching the issue at all.
## For maintainers
We know there are differing views on whether stale bots are healthy or not, and we would not want to impose a bot on a repo that we do not control. So if you're not sure this is a good idea (or if you're sure that it _isn't_), let us know, and we'll have a discussion. If we come to the conclusion that it's not the right decision (for whatever reason), then we're happy to leave the bot out.
Further, if you're happy to accept the stale bot, but don't like the org-wide configuration, then we can also override parts or all of the config to make it fit better with this repo.
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
