-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test deployments without mocks #483
base: main
Are you sure you want to change the base?
Conversation
Can you amend the Readme.md with the new ENV options? |
There will be more documentation when it's ready for review. I will refactor it after #472 is merged, |
Can the mock data be re-used for Unit and integration tests? So, should we throw it away with this PR or keep it for later use? |
The data is not gone. It's still in the commit history. |
This pull request has conflicts ☹ |
That's like, "The money isn't gone; it's just somewhere else now". Nobody will remember that the data is still in the commit history. The question is: Can the mock data be re-used for unit and integration tests? If yes, should we keep it for later use? |
To have data that is not used and, therefore, not maintained makes no sense. And with the argumentation that we may need it in the future, we should not remove unused stuff at all. |
862847c
to
642018e
Compare
Use Run test server using develop.opencast.org as backend:
Specify a different backend like stable.opencast.org:
It may take a few seconds for the interface to spin up. |
642018e
to
43f343d
Compare
This pull request is deployed at test.admin-interface.opencast.org/483/2024-05-31_11-26-37/ . |
This pull request is deployed at test.admin-interface.opencast.org/483/2024-05-31_11-32-22/ . |
This pull request has conflicts ☹ |
aa26a20
to
71d4edf
Compare
Should we document the environment variables? They should only be used in the workflows, and the other workflow-specific variables are not documented either. |
71d4edf
to
5acc1f8
Compare
If you aim to test against a remote server without using a proxy, you have the option to configure the target server with the `VITE_TEST_SERVER_URL`, and the `VITE_TEST_SERVER_AUTH` environment variables while using the node development mode: | ||
|
||
```sh | ||
NODE_ENV=development VITE_TEST_SERVER_URL="https://develop.opencast.org" VITE_TEST_SERVER_AUTH="admin:opencast" npm start |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how common this will be, in testing against localhost I could not get this to work until I put a proxy with a wide open CORS config in between. So VITE_TEST_SERVER_URL="http://localhost:8080"
did not work, but VITE_TEST_SERVER_URL="http://localhost" <- now with proxy!
did. Would it be worth explaining that here, or am I sufficiently out of touch with frontend dev that this is something that's obvious?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think CORS is Daily Business nowadays, and the Vite proxy would be a better fit for local scenarios.
This pull request has conflicts ☹ |
5acc1f8
to
c7a4414
Compare
This pull request has conflicts ☹ |
This change allows to configure the Axios client to use a different base URL and set the authentication header. NODE_ENV=development VITE_TEST_SERVER_URL=https://develop.opencast.org VITE_TEST_SERVER_AUTH="admin:opencast"
c7a4414
to
647f0f0
Compare
This change allows to configure the Axios client to use a different base
URL and set the authentication header.
NODE_ENV=development
VITE_TEST_SERVER_URL=https://develop.opencast.org/
VITE_TEST_SERVER_AUTH="admin:opencast"
Fixes #395