* Add e2e tests
* Remove cypress key
* Add project tag
* Add cypress to root
* Add cypress working directory and package.json in subfolder
* Remove record flag
* Add contains to url check
* Test segment e2e test
* Remove one of contains
* Test e2e tests
* Fix e2e
* Test new yml
* New yaml
* Test different echo
* Update workflows
* Fix deployment url
* Fix formatting
* 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>
* feat: build docker containers when pushing to main
The intent here is to publish a docker container for every build of
main. This will make it easier to run the tip of main.
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.
This change adds a workflow file that references the reusable workflow
in the unleash/.github repo. It should (if all goes well),
automatically add new issues and prs to the project board.
Add a new .../:feature/variants API
This adds
- `GET /api/admin/projects/:projectId/features/:featureName/variants` which returns
```json
{ version: '1', variants: IVariant[] }
```
- `PATCH /api/admin/projects/:projectId/features/:featureName/variants` which accepts a json patch set and updates the feature's variants field and then returns
```json
{ version: '1', variants: IVariant[] }
```
- `PUT /api/admin/projects/:projectId/features/:featureName/variants`
which accepts a IVariant[] and overwrites the current variants list for the feature defined in :featureName and returns
```json
{ version: '1', variants: IVariant[] }
- This also makes sure the total weight of all variants is == 1000
- Validates that there is at least 1 'variable' variant if there are variants
- Validates that 'fix' variants total weight can't exceed 1000
- Adds tests for all these invariants.
Co-authored-by: Simon Hornby <simon@getunleash.ai>
